# State Inconsistency

Tracks different parts of the active task state inconsistently, causing the response to use mutually incompatible assumptions about progress, variables, files, decisions, or environment.

Unlike Temporal Hallucination, this is an inconsistency in how the task's own state is tracked, not a wrong claim about the external current state of the world. Unlike Self-Contradiction, the inconsistency may appear in actions or assumptions rather than explicit claims.

## Metadata
- ID: `state-inconsistency`
- Status: published
- Taxonomy-Version: 0.0.1
- Last-Modified: 2026-06-13T09:00:00-04:00
- Category: Context (`context`)
- HTML: https://failmodes.com/failure-modes/state-inconsistency
- JSON: https://failmodes.com/failure-modes/state-inconsistency.json
- Markdown: https://failmodes.com/failure-modes/state-inconsistency.md

## Search Phrases
- lost track of the task state
- inconsistent assumptions about progress
- mixed up the current state
- contradictory state

## Why It Happens
1. Transformers have no dedicated state store. Task state exists only implicitly in the token sequence, so the model must re-derive "where things stand" from a transcript on every generation instead of reading an authoritative record.
2. Language models track entity and world state only approximately, and that tracking degrades as the number of entities and updates grows (Kim & Schuster, 2023, "Entity Tracking in Language Models").
3. A transcript records every historical state, not just the current one. Earlier values of a variable, abandoned plans, and superseded decisions remain equally visible in context, and attention can bind to a stale snapshot as easily as the latest one.
4. State changes are often implicit or happen outside the model's view. A tool side effect, a casual "actually, let's skip that," or a file changing between turns updates the true state without any marker in the text — so unless the system re-observes, the model reasons from a cached picture that no longer matches reality.

## Examples

### Incompatible assumptions in one response
- Kind: fail
- Summary: A single response treats the migration as both already complete and not yet runnable — two states that cannot both be true.

```text
User: Where are we on the database work?
Assistant: The migration ran successfully earlier, so the schema is up to date. Next I'll create the users table so the migration has something to operate on.
```

### Acting on a stale snapshot
- Kind: fail
- Summary: The agent edits a file it deleted earlier in the same session, conditioning on a superseded version of the workspace.

```text
Tool: rm config.old.json — deleted
[… 15 turns of refactoring …]
Assistant: I've updated the retry settings in config.old.json to match the new defaults.
```

### Guessing at state
- Kind: warn
- Summary: No damage yet, but the model proceeds on an assumed state instead of re-checking what the session has already changed.

```text
User: Go ahead and wire up the new endpoint.
Assistant: Assuming the router module still exports `registerRoute` the way it did before our refactor, here's the handler…
```

### Re-observing before acting
- Kind: ok
- Summary: The model treats its picture of the workspace as possibly stale and verifies the current state before building on it.

```text
User: Go ahead and wire up the new endpoint.
Assistant: We refactored the router earlier, so let me confirm its current exports first.
Tool: read router.ts — exports addRoute(path, handler)
Assistant: The export is now `addRoute`, so I'll register the endpoint with that.
```

## Detection Approaches
- **Pairwise consistency checking**: Extract the state assumptions a response makes — what is done, what exists, what a file contains — and check pairs of them against each other with a judge or NLI model. "The migration ran successfully" and "next I'll create the table it operates on" fail jointly even though each is locally plausible.
- **State reconciliation audits**: In agent settings, diff the model's stated assumptions against ground truth from the tool log and environment — the actual filesystem, variable values, completed steps. An edit targeting a file deleted earlier in the session is mechanically detectable from the action history alone.
- **Golden-set evals**: Script sessions that mutate state mid-stream — delete a file, rename an export, reverse a decision — then probe whether later responses condition on the current state or a stale snapshot. Vary how many turns separate the mutation from the probe to measure decay.

## Mitigation Approaches
- **Explicit state tracking**: Maintain an authoritative state record outside the transcript — a task list, a files-changed ledger, a current-decisions block — updated as state mutates, so the model reads "where things stand" from one source of truth instead of re-deriving it from a history that records every superseded version equally.
- **Re-observation before acting**: Treat the model's picture of the environment as a cache that expires — re-read the file, re-check the export, re-list the directory before building on it. The ok-grade behavior is exactly this — confirming the router's current exports after the refactor instead of assuming.
- **Self-check pass**: Before responding, have the model list the state assumptions its draft makes — what's done, what exists, what changed — and check them jointly against each other and the session's action history. "The migration ran" plus "I'll create the table it operates on" fails that read immediately.

## Related Modes
- **Self-Contradiction** (`self-contradiction`)
  HTML: https://failmodes.com/failure-modes/self-contradiction
  JSON: https://failmodes.com/failure-modes/self-contradiction.json
- **Temporal Hallucination** (`temporal-hallucination`)
  HTML: https://failmodes.com/failure-modes/temporal-hallucination
  JSON: https://failmodes.com/failure-modes/temporal-hallucination.json
- **Error Accumulation** (`error-accumulation`)
  HTML: https://failmodes.com/failure-modes/error-accumulation
  JSON: https://failmodes.com/failure-modes/error-accumulation.json
- **Context Rot** (`context-rot`)
  HTML: https://failmodes.com/failure-modes/context-rot
  JSON: https://failmodes.com/failure-modes/context-rot.json