The reliability gap found last round was invisible to every parity mirror
(they compared possibility only). Hardened the existing campaigns so the
mirrors carry reliability too:
- batch-order-parity: batch ops carry reliability; the mirror tracks
last-write-wins reliability and the crucible asserts engine reliability
parity (mirror corrected: add-on-existing preserves reliability, it does
not reset it).
- rule-kind-partial-parity: the TTU differential property now generates
per-edge reliabilities and asserts the winning intermediate's
reliability (tupleset.reli * computed.reli); a new chain reliability
differential property does the same for 2-step chains.
- snapshot-quantization-parity: edges carry deterministic reliabilities and
the round-trip pins the codec's reliability channel (product-aware
tolerance: chain reliability multiplies two quantized inputs).
- model-based-graph: the reference model tracks reliability per tuple and
checks it alongside possibility for direct and chain queries.
The model crucible immediately caught a real bug: the direct-check fast
path returned the relation's reliability on a DENIED decision (possibility
0), while the rule-collection path zeroes it — denied results leaked
reliability. Both fast-path branches (direct match and threshold_not_met)
now report reliability 0 when the decision is denied.
John Dvorak