How do you test that a system is correct when no oracle exists? A unit test needs expected outputs, and for a whole runtime (a parser, an evaluator, a replay engine) the expected output is the system itself. The cheap answer is to write it twice: two implementations of the same contract, each serving as the other's oracle.
the oracle problem
An oracle is the thing that tells a test what "correct" means. For most code the oracle is the programmer's intent encoded in examples. For a deterministic system (a manifest interpreter, a state machine, a projection), there is a stronger option: any second faithful implementation. Run the same input through both and require bit-for-bit agreement; a divergence is, by construction, a bug in exactly one of them.
The asymmetry is the power. A bug in implementation A is a bug in A; the same bug in both is nearly impossible, because independent implementations of a shared contract share mistakes only where the contract itself is ambiguous, and the contract is the thing you then fix.
what parity is
Parity in the portfolio means the same artifacts driven through both runtimes with identical receipts. ALGAL is the fullest case: the TypeScript reference runtime and the Rust kernel each execute the bundled example organisms, and the parity harness compares run receipts byte for byte. The verify direction runs too: a receipt produced by the TypeScript CLI must replay and verify under the Rust CLI, and vice versa, so "the run was deterministic" is itself tested across the language boundary.
Oh's parity suite applies the same law to the memory kernel: operation sequences run against the model and the implementation and must agree, which is the same contract expressed in one language against a model instead of two against each other.
how the suites work
The mechanics are boring by design. A parity suite enumerates the example set (every bundled organism, every CLI surface that emits receipts, every replayable lifecycle), runs each through both implementations, and diffs canonical output. The suites are split by surface so a divergence arrives with an address: store parity, CLI parity, inference parity, application lifecycle parity.
The yield is the class of bugs no single-runtime test can find: a subtle difference in float formatting, a JSON serialization order that differs, a hash computed over slightly different bytes, a boundary condition read differently by two implementations of the same spec. Each divergence forces the contract to be more precise, which is the real deliverable: the parity suite is a spec-precision machine.