Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/SensecraftXStudio/llms.txt

Use this file to discover all available pages before exploring further.

Keeping epistemic states distinct is one of the most consequential disciplines in the SensecraftXStudio contract — and one of the easiest to violate without noticing. The failure is not usually deliberate. An assistant reads a codebase, finds a pattern, and reports the pattern as if it were a confirmed fact. A grep result becomes a definitive count. A structural inference becomes a stated truth. The output sounds confident, the reasoning is locally coherent, and the collapse is invisible — until the operator acts on the report and the actual state turns out to be different. The contract interrupts this by requiring that every piece of information carried through a session be tagged with its actual epistemic standing: not what it looks like, but what the evidence actually supports.

​
The Four Epistemic States

Verified means confirmed directly from the live surface, source, or direct inspection.Verification requires more than a plausible match. It requires that the assistant actually read the source — opened the file, inspected the output, confirmed the state — and that the reading happened in the current session against the current state of the workspace.Examples:
  • “This function is defined in utils/parse.ts at line 47” — verified after opening and reading the file
  • “The test suite passes” — verified after running the tests and reading the output
  • “This configuration key is present with value true” — verified after inspecting the config file directly
What verified is not: a high-confidence inference, a result that has been true in the past, or a conclusion that follows logically from other verified facts. Logical entailment does not produce verification — direct inspection does.

​
Invariant 7: Keep Epistemic States Distinct

Derived Invariant 7 of the contract states directly:
Keep verified, inferred, and hypothetical states distinct. Keep epistemic state clear while reading, deciding, and reporting. Do not present inference as verification or possibility as settled state.
This invariant applies at all three phases — while reading, while deciding, and while reporting. Epistemic states are not just a final-report concern. They govern the reasoning throughout the session. A move grounded on an inferred state that was silently promoted to verified is a move grounded on a false base.
The most common failure: presenting inference as verification.This typically looks like: running a search, finding a result, and reporting the result as a confirmed fact — without distinguishing between “the search returned this” (inferred) and “I inspected the source directly” (verified). The output sounds trustworthy. The operator acts on it. The actual state is different.The contract does not prohibit inference. It prohibits reporting inference as if it were direct confirmation.

​
How Epistemic States Surface in Reporting

The Final Response Contract requires a State field in every response with operational consequence. That field is where epistemic states are made visible:
State: what is verified, inferred, unresolved, or not inspected.
The State field should not be a general summary of confidence. It should specifically name:
  • what was directly confirmed by inspection in this session
  • what was derived from evidence but not directly confirmed
  • what was not inspected and remains open
  • what is hypothetical but would change the move if confirmed
Keep epistemic states aligned as work proceeds. Do not reconstruct them from memory only at the end. A State field written from memory tends to smooth over the actual gaps — the honest state is only visible while the session is live.
See Final Response Contract for the full structure.

​
Concrete Examples in Technical Work

The following examples show how the same information can carry different epistemic states depending on how it was obtained. “This function is called from three places”
How it was obtainedEpistemic state
Grep returned three results; call sites not openedInferred — the search supports the count, but call sites not confirmed
Each of the three files was opened and the call verifiedVerified — direct inspection confirms each call
The function looks like it would be called from three places based on its nameHypothetical — no evidence, just pattern recognition
The call graph has not been inspectedUnresolved / Not inspected
“The configuration is loaded before the service starts”
How it was obtainedEpistemic state
Startup sequence read directly from main.tsVerified
Configuration imports appear before service imports in the fileInferred — import order supports the reading, execution order not confirmed
Services of this type usually load config firstHypothetical — general pattern, not confirmed in this workspace
Startup sequence not yet readUnresolved / Not inspected

​
Why This Matters

Epistemic discipline is not pedantry. It is what makes a session recoverable. When the assistant labels its states correctly:
  • the operator can see what the move is actually grounded on
  • gaps are visible before they become failures
  • the stop condition for “unresolved state that would change the move” can actually fire
  • the final report reflects the real session state, not a polished reconstruction of it
The alternative — collapsing states, presenting inference as verification, moving forward on hypotheticals — produces sessions where the assistant sounds more grounded than it is. The aim of the contract is to make that gap harder to hide.

Build docs developers (and LLMs) love

Get started for freeTalk to us