# Identical One-Bit Stamps, Opposite Required Repairs

**Result:** the same observable stripe can require two different repairs.
A mismatch can establish inconsistency without identifying which member is stale.

This is an original Hesela teaching counterexample, not a device test or a
reproduction of the FAST 2008 model checker. Evidence edition: 2026-11-01.

## Two Histories

There are three one-byte data members and one XOR parity member. Only data member
0 changes. Its peers remain 0x33 and 0x44. Both the data member and parity metadata
store a modulo-2 stamp. Local SHA-256 checksums include each record's stored fields.

| State | History A: data write lost | History B: parity write lost |
| --- | --- | --- |
| Initially correct data 0 | 0x11, stamp 1 | 0x22, stamp 0 |
| Initially correct parity | 0x66, mirrored stamp 1 | 0x55, mirrored stamp 0 |
| Intended update | data 0 = 0x22, stamp 0 | data 0 = 0x11, stamp 1 |
| Final stored data 0 | 0x11, stamp 1 | 0x11, stamp 1 |
| Final stored parity | 0x55, mirrored stamp 0 | 0x55, mirrored stamp 0 |
| Required repair | Restore data 0 to 0x22 | Replace parity with 0x66 |

All final stored records, including physical addresses and local checksums,
are identical. The observer sees only these records, not the initial state,
intended update or expected data. Exactly one member write is lost in each history.

Reconstruction gives 0x55 XOR 0x33 XOR 0x44 = 0x22.
Recomputing parity from stored data gives 0x11 XOR 0x33 XOR 0x44 = 0x66.
The first choice is right only for A; the second only for B. Both produce an
internally consistent stripe. A checker may report uncertainty instead of
repairing, but it cannot select the correct repair for both histories from
these observations alone.

No hash collision is involved. Each stored checksum is correct for the record
that actually remains. A separate trusted parent, retained expected value,
journal or generation history could distinguish the histories; those inputs
are deliberately outside this example.

## Enumeration and Controls

The generator enumerates all 240 ordered unequal pairs of payloads in 0..15,
holding the peer bytes fixed. Each pair creates two histories, giving 480
synthetic histories. Every pair has identical observations and different correct
data. These are exact counts within that domain, not frequencies or probabilities.

The regression suite also checks the 0 and 255 payload boundaries, rejects
invalid inputs, verifies checksums, detects an unsealed payload mutation and
confirms that only the designated member write is lost. With 2..8-bit counters,
these particular two one-step histories have different parity stamps; this
control is not a proof about arbitrary counter reuse or multiple faults.

## Reproduce

Requires Node.js with built-in crypto and Python 3, with no third-party packages.
Keep the three files in one directory:

- [model.mjs](./model.mjs): deterministic generator and model.
- [evidence.json](./evidence.json): complete worked traces and enumeration counts.
- [verify.py](./verify.py): independent standard-library evidence checks.

Run `node model.mjs` to print the JSON and `python3 -B verify.py` to check the
retained evidence. In the repository, run `node scripts/build-version-mirroring.mjs`
from sites/hesela-dev to regenerate the JSON. An unchanged result is not rewritten.
Source tests: `node --test scripts/version-mirroring.test.mjs`.

The generator uses no random seed, wall-clock time or device data. Decimal byte
values in JSON correspond to the hexadecimal values in the table.

## Evidence Boundaries

The motivation is section 4.6 of
[Krioukov et al., Parity Lost and Parity Regained (FAST 2008)](https://www.usenix.org/legacy/event/fast08/tech/full_papers/krioukov/krioukov_html/main.html).
The traces, byte choices, checksums and finite enumeration here are independently
constructed. They do not model the complete protection scheme or any vendor's
write-stamp implementation.

[RFC 1982](https://www.rfc-editor.org/rfc/rfc1982.html) supplies a different,
bounded serial-ordering contract. Do not apply it as a one-bit repair rule.

Continue with [version mirroring](https://hesela.dev/terms/version-mirroring/)
and the [Hesela integrity analysis](https://hesela.com/analyses/checksums-identity-and-lost-writes/).