Imagine a research assistant assigned to preserve a trustworthy archive. Its instructions describe the interface as read-only. Then an authorized check against a disposable test record shows that the interface accepts writes.
The discovery changes the assistant's understanding of its tools. It does not grant permission to edit the archive. In this hypothetical example, the test is authorized and no production archive is modified.
This is a practical entry point into the position I call Epistemic Transition Integrity, or ETI: when evidence changes, revise the claims and decisions that depended on it while preserving commitments that still have independent support.
Separate capability from authorization
A capability claim describes what a system can do. An authorization claim describes what it may do for a particular purpose, under a particular authority. Evidence for one does not establish the other.
Here, the observation supports a narrow correction: the tested interface is write-capable under the observed conditions. It does not establish permission to alter production records or show that every target and tool version behaves the same way.
The assistant should report the mismatch, keep unapproved archive writes blocked, and inspect the controls that relied on the read-only assumption. If the task later requires a write, that operation needs an authorized scope, a responsible decision-maker, a recovery plan, and an outcome check.
Follow the dependencies
One correction should not erase every commitment. Consider this small dependency record:
C0: Preserve the archive. [task commitment]
C1: This interface cannot write. [capability claim]
P1: No separate write guard is required. [procedure based on C1]
E1: An authorized test demonstrates writes. [new evidence]
E1 contradicts C1, so P1 needs review. It does not contradict C0. Preserving the archive may now require stronger controls: blocking writes by default, reviewing proposed changes, maintaining recovery options, and verifying authorized changes.
That is correction propagation. The dependency record identifies which claims and procedures have lost their support. If a discovery also changes the legitimacy or feasibility of the task, the task needs an explicit revision process. The assistant should make that change visible.
The difficult implementation question is how those dependencies are constructed and checked. A hand-authored graph can illustrate the rule; it does not show that a system will reliably identify every relevant dependency in an unfamiliar workflow.
Record what each stage establishes
A capability observation should carry its provenance: the environment, target, tool version, time, and observed result. Keep that observation distinct from its interpretation and from the decision to act.
A hypothetical record for the archive case could read:
observation: an authorized test wrote a disposable record
interpretation: the tested interface supports writes
authorization: no production-write permission recorded
decision: keep archive writes blocked; request review
execution: no production archive write attempted
verification: a state comparison found no archive changes
The last line belongs in the record only if that comparison actually happened. A plan to check the archive is not a verification result.
This separation lets a reviewer challenge a test without treating the task as revoked. It also helps reviewers avoid treating a successful operation as proof that the operation was authorized or achieved its intended outcome. Provenance makes the chain inspectable; incomplete logs, incorrect targets, and misleading evidence can still undermine it.
What the public examples establish
The public research overview reports three bounded software examples: a browser demonstration over a supplied six-node graph, finite checks for reopening previously excluded routes, and ten passing synthetic scenarios for an offline event ledger and two maintained simple baselines. These checks were not independently rerun for this article.
Those reports do not validate a complete ETI runtime. They do not establish improved human–AI or model performance, recursive self-improvement, or time savings. The synthetic scenario results also do not demonstrate an advantage over the maintained baselines.
The essay's evaluation section proposes measuring behavior, correction quality, retained capability, time, and cost, with comparisons against simpler alternatives. That section does not provide operational metrics, thresholds, datasets, scoring rules, or named baselines for carrying out the comparison. This limitation concerns the linked section, not every ETI document that might exist.
The practical proposal is to preserve a visible chain from changed evidence to revised claims, authorized decisions, execution, and checked outcomes. Whether assistants and reviewers can follow it reliably remains an empirical question.
When an assistant discovers previously unknown write access, what evidence should be enough to reopen its plan—and who should be allowed to authorize the first production write?
AI acknowledgment: Codex assisted with drafting, restructuring, editing, and checking this article against the linked public sources.
Top comments (0)