**CONTRACT**

1. ADR-026 reassigns ADR-015’s Repo 3 ownership of the op-log segment format spec.

   Exact ADR-026 sentence: “Substrate-core retains and owns a **versioned, posture-neutral op-log LOGICAL/INTERCHANGE format** (an envelope), plus a thin interface and a conformance suite.”

   Exact conflicting table sentence: “blind-deployment … **Does not own**: The interchange format spec and the EnvelopeSpec contract (it consumes them).”

   ADR-015’s Accepted prose says Repo 3 contents include: “Op-log segment format spec.” ADR-026’s later reconciliation tries to narrow ADR-015’s “op-log format” to “the blind encrypted-segment profile, the fixed-shape event wrapper, the `storage_index`/CAS conventions, and the ORAM / leakage-shaping integration,” but that narrowing is not in the quoted Accepted ADR-015 prose. That is a contractual reinterpretation unless ADR-026 explicitly amends/supersedes ADR-015.

2. ADR-026 overclaims that ADR-015 assigned specific blind-sync subcomponents not present in the quoted Accepted prose.

   Exact ADR-026 sentence: “ADR-015 §Repo 3 already assigns the blind-sync server (**encrypted op-log + CAS + capability verifier + fixed-shape sync event format**) to the operator-blind deployment sibling.”

   ADR-015’s quoted prose assigns the blind-sync server and lists op-log segment format spec, wrapper-swap rotation primitive, ORAM constructions, reservation-pool layout, canonical KG export schema implementation, and fixed-shape sync event format. It does mention “opaque CAS” inside the ORAM bullet, and “capability verifier semantics” as first-ADR coverage, but it does not assign “encrypted op-log + CAS + capability verifier” as the server ownership bundle in the way ADR-026 states. This is partly a correctness overstatement and partly a contract-risk because ADR-026 uses the overstatement to justify its routing.

**CORRECTNESS**

1. ADR-026 says the “answer is largely pre-figured by Accepted prose,” but its own routing depends on a distinction not present in ADR-015.

   Exact sentence: “The answer is largely pre-figured by Accepted prose.”

   The load-bearing distinction between “posture-neutral op-log segment envelope” owned by core and “blind encrypted-segment profile / wrapper” owned by Repo 3 is ADR-026’s invention. It may be a reasonable reconciliation, but ADR-015’s quoted Accepted prose does not make that distinction.

2. ADR-026 misstates ADR-014 by saying it “forbids” owning the physical layer in core.

   Exact sentence: “Owning the physical layer in the zero-dependency core would mean re-implementing a CRDT engine in core, which the stdlib-only constraint and ADR-014's ownership stance forbid.”

   The quoted ADR-014 prose disclaims commitment to a specific vendor stack and says load-bearing commitments are format/interface specs. It does not explicitly forbid core from owning physical storage layout or a CRDT engine. The conclusion may follow from broader repo policy, but it is not supported by the quoted ADR-014 contract.

3. ADR-026 cites ADR-014 §Long-term as binding context, but that prose was not part of the provided Accepted binding excerpt.

   Exact sentence: “Owning the logical interchange format is the shareable, zero-dependency-safe piece, and it is what makes canonical export and the ADR-014 §Long-term cross-subgraph-query goal tractable across differently-deployed instances.”

   The provided ADR-014 binding excerpt is only “What this does not commit to.” Cross-subgraph query may exist elsewhere, but for this review it is not quoted Accepted prose. ADR-026’s reliance on it is outside the supplied contract.

**STYLE**

1. “This ADR's Decision 1 … operationalize that commitment” is rhetorically too strong because ADR-026 is also adding a core-vs-blind ownership split not explicitly present in ADR-015. Prefer “proposes a reconciliation” unless ADR-015 is amended.

2. “irreversible-if-skipped” is vague and overloaded. The document should say which exact fields or compatibility rules become impossible or expensive to add later.

3. “The substrate already operates as a four-layer family” conflicts stylistically with ADR-014’s warning against committing to a specific deployment topology. It would be clearer as “For the current repo split, the relevant layers are…”
tokens used
14,325
**CONTRACT**

1. ADR-026 reassigns ADR-015’s Repo 3 ownership of the op-log segment format spec.

   Exact ADR-026 sentence: “Substrate-core retains and owns a **versioned, posture-neutral op-log LOGICAL/INTERCHANGE format** (an envelope), plus a thin interface and a conformance suite.”

   Exact conflicting table sentence: “blind-deployment … **Does not own**: The interchange format spec and the EnvelopeSpec contract (it consumes them).”

   ADR-015’s Accepted prose says Repo 3 contents include: “Op-log segment format spec.” ADR-026’s later reconciliation tries to narrow ADR-015’s “op-log format” to “the blind encrypted-segment profile, the fixed-shape event wrapper, the `storage_index`/CAS conventions, and the ORAM / leakage-shaping integration,” but that narrowing is not in the quoted Accepted ADR-015 prose. That is a contractual reinterpretation unless ADR-026 explicitly amends/supersedes ADR-015.

2. ADR-026 overclaims that ADR-015 assigned specific blind-sync subcomponents not present in the quoted Accepted prose.

   Exact ADR-026 sentence: “ADR-015 §Repo 3 already assigns the blind-sync server (**encrypted op-log + CAS + capability verifier + fixed-shape sync event format**) to the operator-blind deployment sibling.”

   ADR-015’s quoted prose assigns the blind-sync server and lists op-log segment format spec, wrapper-swap rotation primitive, ORAM constructions, reservation-pool layout, canonical KG export schema implementation, and fixed-shape sync event format. It does mention “opaque CAS” inside the ORAM bullet, and “capability verifier semantics” as first-ADR coverage, but it does not assign “encrypted op-log + CAS + capability verifier” as the server ownership bundle in the way ADR-026 states. This is partly a correctness overstatement and partly a contract-risk because ADR-026 uses the overstatement to justify its routing.

**CORRECTNESS**

1. ADR-026 says the “answer is largely pre-figured by Accepted prose,” but its own routing depends on a distinction not present in ADR-015.

   Exact sentence: “The answer is largely pre-figured by Accepted prose.”

   The load-bearing distinction between “posture-neutral op-log segment envelope” owned by core and “blind encrypted-segment profile / wrapper” owned by Repo 3 is ADR-026’s invention. It may be a reasonable reconciliation, but ADR-015’s quoted Accepted prose does not make that distinction.

2. ADR-026 misstates ADR-014 by saying it “forbids” owning the physical layer in core.

   Exact sentence: “Owning the physical layer in the zero-dependency core would mean re-implementing a CRDT engine in core, which the stdlib-only constraint and ADR-014's ownership stance forbid.”

   The quoted ADR-014 prose disclaims commitment to a specific vendor stack and says load-bearing commitments are format/interface specs. It does not explicitly forbid core from owning physical storage layout or a CRDT engine. The conclusion may follow from broader repo policy, but it is not supported by the quoted ADR-014 contract.

3. ADR-026 cites ADR-014 §Long-term as binding context, but that prose was not part of the provided Accepted binding excerpt.

   Exact sentence: “Owning the logical interchange format is the shareable, zero-dependency-safe piece, and it is what makes canonical export and the ADR-014 §Long-term cross-subgraph-query goal tractable across differently-deployed instances.”

   The provided ADR-014 binding excerpt is only “What this does not commit to.” Cross-subgraph query may exist elsewhere, but for this review it is not quoted Accepted prose. ADR-026’s reliance on it is outside the supplied contract.

**STYLE**

1. “This ADR's Decision 1 … operationalize that commitment” is rhetorically too strong because ADR-026 is also adding a core-vs-blind ownership split not explicitly present in ADR-015. Prefer “proposes a reconciliation” unless ADR-015 is amended.

2. “irreversible-if-skipped” is vague and overloaded. The document should say which exact fields or compatibility rules become impossible or expensive to add later.

3. “The substrate already operates as a four-layer family” conflicts stylistically with ADR-014’s warning against committing to a specific deployment topology. It would be clearer as “For the current repo split, the relevant layers are…”
