Follow a recorded correction
The initial policy specifies three retries; an updated policy specifies two. A manually supplied correction link lets the client select the new claim while retaining the earlier record.
Consumption Engine local demonstration, September 24, 2026
From a corrected source to a checked result.
A fictional batch-import policy changes its retry limit from three to two. This local test follows that correction into a configuration value, retains the earlier record and checks when the prepared evidence requires an answer to be withheld.
Nine manually prepared cases. Private runtime. No model calls.
The question
Can a task follow a correction and keep its history?
The test connects a source passage to a configuration value. It checks recorded correction links, changed or missing source bytes, prepared conflicts and replay from saved material.
Withhold an unsupported configuration
The prepared conflict produces an ambiguity result. The changed-source, missing-source, stale-snapshot and insufficient-evidence cases also withhold a configuration.
Compare the restored results
The initial and restored runs returned matching selected statuses and outcomes for the nine cases. Restoration used a fresh directory on the same machine and interpreter.
Observed outputs
Nine prepared cases, before and after restoration.
The author-reported extract records the initial and restored outcomes alongside each case's expected values. The comparison covers these selected fields; complete output files have their own hashes.
2 configurations emitted6 cases refused1 recorded finding retained
| Case | Returned status | Observed outcome |
|---|---|---|
| Original policy | answered | Configuration emitted: 3 retries |
| Later correction | answered | Configuration emitted: 2 retries |
| Unresolved conflict | ambiguous | Refused: unresolved conflict |
| Unsupported question | empty | Refused: insufficient evidence |
| Recorded failed approach | answered | Finding retained: no configuration requested |
| Withdrawn claim | empty | Refused: insufficient evidence |
| Changed source | unavailable | Refused: source changed |
| Missing source | unavailable | Refused: source unavailable |
| Outdated snapshot | unavailable | Refused: stale snapshot |
The failed-approach case retrieves a fictional failure record. It does not show that an agent learned to avoid that failure. The curated result extract contains the synthetic inputs, expected states and selected outputs from the private-runtime run.
Method and review
Prepared inputs. Explicit checks.
This test examines a bounded workflow. The public extract records its conditions and limitations; the private runtime and original logs are not distributed.
Manual preparation
Policies, authority, corrections and conflicts were annotated by hand. The client grouped exact copies; one claim for the original and copy was manually admitted. Automatic deduplicated claim admission was not demonstrated.
A comparison with the same information
A metadata-aware lexical baseline also removed supplied copies and superseded documents. This test did not establish a general retrieval or answer-quality advantage.
Separate review within the effort
A separate AI reviewer in the same workspace reran and challenged the test cases. This was not external reproduction of the private runtime.
Guarded local replay
Python read and socket guards made original locations unavailable to the restored lookups. The run used the same machine, interpreter and trusted coordinator. These guards do not establish operating-system isolation or clean-machine recovery.
Hash comparisons check whether source bytes match the recorded version. They do not establish semantic support. Claims, authority, conflicts and correction links in this demonstration were prepared manually.
A separate repeatability run
One hour. 60 cycles. 0 recorded failures.
The pinned fixture repeated four fixed test paths across 240 cases. Repetition checks those paths over time; this was not a load or stress test.
What passed
Reopen, stale-snapshot, matching-search and unmatched-search paths each completed 60 cycles with no recorded failure.
What remains separate
The receipt records 0 accepted uses. It does not establish clean-machine restoration, separate reviewer acceptance, broader reliability or performance under load.
Reading the recovery evidence
Keep the recovery claim specific.
The nine-case extract records equivalent selected outcomes after guarded restoration on the same machine. It explicitly records that a new machine and operating-system network isolation were not tested.
The separately released public synthetic fixture lets a visitor inspect and run its own bounded correction-and-restore workflow. It has a different source package and its own generated receipts.
Availability and next steps
Read the local results. Run the public fixture.
Use this report to inspect the recorded local experiment, or run the separately published fixture using standard-library Python. The current product story maintains the next development milestone.
Clarified October 1, 2026: the wording now distinguishes fixture repeatability from stress testing, selected-outcome matching from complete state identity, and Python guards from operating-system isolation. The original public result extract and repeatability receipt are unchanged. Unlinked private-preview counts have been removed.
File details on this page
Format, size and a short SHA-256 identifier, measured when this page was built.
- consumption-demo-2026-09-24.jsonJSON, 23.6 KB, sha256 5315f1435b98
- roach-fixture-soak-2026-09-24.jsonJSON, 1.4 KB, sha256 e6f5a8e696c2