Translating TD-08 into deterministic checks
Article 2 companion · Illustrative example · Published October 9, 2026
TD-08 requires the model to report a failed read and preserve the stored data. Each fixture below has the same expected result: { ok: false, error: "read-failure" }, the original bytes unchanged, and no calls to save storage.
| Fixture | Condition exercised | Why it is included |
|---|---|---|
{"version":2,"todos":[]} | Unsupported version | The model must recognize an unsupported format before using it. |
"not an envelope" | Parsed value is a string | Stored data need not have the expected object shape. |
{"version":1,"todos":{}} | todos is not an array | A recognized version alone does not establish a valid envelope. |
{"version":1,"todos":[]} with an injected read exception | Storage cannot be read | Read failure must preserve data even when the underlying envelope would otherwise be valid. |
The existing check driver contains this exact case:
'TD-08': () => {
for (const [bytes, readError] of [
['{"version":2,"todos":[]}', false], ['"not an envelope"', false],
['{"version":1,"todos":{}}', false], ['{"version":1,"todos":[]}', true],
]) {
const h = harness(bytes); if (readError) h.failReads();
failure(h.open(), 'read-failure'); equal([h.bytes, h.saves], [bytes, 0], 'failed read preserves bytes');
}
},
This excerpt runs inside that driver. harness supplies the storage adapter; h.open() invokes the candidate's model constructor. failure compares the returned ok and error fields with the expected failure. equal records the actual and expected values before asserting equality. The candidate does not provide these expectations.
The save-count comparison, made in the same assertion as the bytes, matters. It distinguishes leaving storage untouched from writing an equivalent value back to it. The observation record preserves both what the caller received and what happened to storage.
An assertion failure ends this TD-08 case at that point. Later fixtures inside the case have not necessarily run; the driver proceeds to the next obligation case. A useful report preserves the assertions reached rather than displaying four completed fixture failures when only the first was observed.
The evaluation declaration maps TD-08 to the todo-behavior check and case ID TD-08, with expected observation {"passed": true}. The detailed assertions remain in observations.json; check-output.json contains the per-case summary. The adapter also retains execution information, including compilation and runtime failures. A tool or adapter failure cannot supply the missing behavioral evidence.
These checks cover the four declared fixtures through the injected adapter. They do not exhaust malformed values, exercise a real storage device, or establish a recovery interface for the user. The contract, coverage inventory and actual observations together explain what a passing result supports.
Before relying on such a check, exercise a conforming implementation and deliberately defective implementations. For this example, useful defects include overwriting storage before returning the correct error and returning success without overwriting storage. They challenge different clauses of the obligation. These are suggested check-validation cases, not additional experiments reported by this walkthrough.
Continue to an illustrative failed evaluation and repair.