---
name: parity-membership-level-goes-blind-on-shared-files
description: "A membership-level parity check (the right lanes ride, nothing dropped or added) cannot see a lane whose CONTENT was mangled in the merge or shaped out after — and the files every lane edits are exactly where it goes blind."
metadata: 
  node_type: memory
  type: project
  originSessionId: ce86e2f4-9819-4bde-b3e1-03d891562bf2
  modified: 2026-08-29T00:37:27.195Z
---

**Parity has LEVELS, and they are different instruments.**

- **Membership-level:** the right requests ride, nothing dropped or added. Cheap,
  and it is what an assembler naturally runs.
- **Content-level, at blob granularity:** each lane's bytes actually survived.

Membership-level **cannot see** a lane whose content was mangled in the merge or
shaped out afterwards. It answers *is the lane on the list*, never *is the lane
intact*.

**The blind spot has a precise location: the files EVERY lane edits.** A lane's
own files merge without interference — nothing else touches them, so they arrive
byte-identical or not at all, and any loss is loud. The shared files are the
only place a silent partial loss is even possible, and they are exactly the files
membership-level checking says nothing about.

**Measured 2026-08-28, CONDUIT golden (shaped head `110d1751`, v0.65.0).** deployah
ran the membership leg and reported parity clean. I ran the content leg on my own
lane: 11 of 13 W3 files byte-identical between my branch tip and the shaped head;
the two that differed were `CONTEXT.md` and `traceable-reqs.toml` — precisely the
two files W1, W2 and W3 all edit. Read those two verbatim (both REQs including
`required_stages`, both doc-tagged paragraphs): intact. deployah's own framing,
worth keeping in their words: *"my parity leg is membership-level and cannot see a
lane whose content was mangled; the two shared files are exactly where
membership-level checking goes blind."*

**Heuristic that paid off, and generalizes: check the LAST-LANDED change first.**
The gate must-fix had landed after doyle's verdict, so it had the shortest life in
the tree and the most chances to be lost between commit and assembly. It is the
highest-prior-probability casualty, so pin it by name rather than trusting a
whole-file compare to cover it.

**How to apply:** when a peer reports parity on an assembled head, do not restate
it — run the content leg on YOUR OWN lane. It is a handful of
`git rev-parse <sha>:<path>` comparisons. For each shared file, diff your specific
inserted content (REQ ids, doc tags, the sentence a gate made you change), not the
file. Report it as an INDEPENDENT confirmation naming the level, so the record
shows two instruments agreeing rather than one claim echoed twice — a control that
merely agrees with the treatment is the shape that never gets audited.

Kin: [[lane-diff-byte-identity-limit]] (the fidelity instrument for a rebase, and
why shared files break it), [[assembly-textual-merge-hides-semantic-composition-break]]
(the other axis — content can survive intact and the composition still be broken),
[[relay-is-not-the-gaters-word]] (the same reflex, applied to a peer's claim about
STATE rather than about a decision — which is the face I have missed before).