A receipt and a result answer different questions
A successful write, click or command tells you that an operation was accepted and executed at some layer. It does not necessarily tell you that the intended state now exists.
For example:
- a file can be written with the wrong content;
- a button can be clicked while the form remains unsubmitted;
- a process can start and immediately crash;
- a setting can be written but overridden by policy;
- a remote command can be delivered while the target device does not reach the requested state.
The generic pattern
A robust mutation flow looks like this:
MUTATE → RECEIPT → OBSERVE → VERIFY → COMPLETE or RECOVER.
The observation should be independent enough that it does not merely repeat the original tool’s own success claim.
What counts as independent read-back?
The exact mechanism depends on the target:
- File: read the file again and verify the expected content.
- UI: inspect the resulting screen or accessibility state.
- Service: query health after start or restart.
- Configuration: read the effective configuration, not only the write API response.
- Database: query the updated record.
- Remote device: obtain observable device state or returned evidence after execution.
Why the observer should not be the model’s confidence
The model that chose the action has an incentive, structurally, to continue the task. Asking the same model “did that work?” without new evidence is not an independent verification step.
The verifier can still use model reasoning where interpretation is required, but the underlying observation should come from the environment.
Verification needs a defined postcondition
Read-back only helps if the system knows what it is checking. “The file exists” is different from “the file contains the verified version in the required schema”.
A good postcondition is explicit enough to evaluate deterministically where possible.
Failure should reopen the obligation
If read-back does not match the required state, the task should not simply terminate. The controller can:
- retry within a budget;
- choose an alternate tool or path;
- diagnose the mismatch;
- request clarification;
- stop safely when the contract cannot be satisfied.
What it should not do is convert uncertainty into success.
Example: the ARKTOR canonical Huawei path
The retained ARKTOR full-stack workflow is:
Runtime → Controller → Node → signed sidecar → physical Huawei → independent read-back → VERIFIED → Complete.
Eight retained runtime configurations completed the same defined physical Huawei workflow. The mutation receipt alone could not satisfy semantic DONE; completion required verified postcondition evidence from the device state.
A practical read-back checklist
- What state is supposed to change?
- What exact postcondition proves success?
- What independent observation can verify it?
- Can the check be deterministic?
- What happens if the observation is missing?
- What happens if it conflicts with the receipt?
- Is retry bounded?
- Can the model bypass the postcondition gate? It should not.
The useful principle
For state-changing work, execution evidence and outcome evidence should be separate artifacts. That small distinction prevents a large class of false-completion errors.