Reading prompt from stdin...
OpenAI Codex v0.129.0 (research preview)
--------
workdir: /home/jdobb/dev/mimidAI
model: gpt-5.5
provider: openai
approval: never
sandbox: danger-full-access
reasoning effort: medium
reasoning summaries: none
session id: 019e73b6-6337-7821-8f24-73313788707f
--------
user
You are performing an INDEPENDENT adversarial contract review of a Proposed ADR. Gaps exist in ADRs of this kind; locate them. ALL content you need is inlined below -- do NOT attempt to read files, search the web, or use any tool. Produce your entire review in a SINGLE response.

CONTRACT SURFACE (verify each):
1. The ADR must NOT contradict the Accepted prose of ADR-014 "What this does not commit to" or ADR-015 "Repo 3" (both inlined below). It must reconcile by cross-reference.
2. Status must be Proposed; it must cite the Phase 12 SYNTHESIS.
3. It must: commit substrate-core to a shared posture-neutral op-log interchange surface; route the merge/CRDT machinery to the open+blind deployment siblings; name Automerge/Hypercore/Yjs as NON-BINDING current-best-fit; defer the concrete format-spec/Sync ABC to a named follow-on (candidate RFC-003).
4. Internal consistency: per-layer ownership coherent; decisions not misstated; cross-references sane.

For EACH finding: quote the offending text, state the problem + a concrete fix, and tag CONTRACT / CORRECTNESS / STYLE. If zero CONTRACT and zero CORRECTNESS issues, say so explicitly at the end.

======== INLINED: ADR-026 (under review) ========
# ADR-026: Offline-Tolerant Sync Ownership Routing

**Status**: Proposed
**Date**: 2026-05-28 (Phase 12 draft)
**Decision Makers**: @jdobb (Phase 12 planner + executor). Consumer-review gate (deferred per the Decision below): evilleAI maintainer (plaintext collector-sync need; deployment posture Pending its Phase 46 privacy-posture dispatch), LaiR maintainer (operator-blind offline-first need per RFC-001 Lane-2), corvidAI maintainer (lone-active library consumer).
**Supersedes**: None. This ADR routes the offline-tolerant-sync concern across the layers established by [ADR-015 Three-Way Substrate Repo Split](ADR-015-three-way-substrate-repo-split.md). It reconciles by cross-reference with [ADR-014 Substrate Ownership and Data Governance Mobility](ADR-014-substrate-ownership-and-data-governance-mobility.md) §"What this does not commit to" and ADR-015 §Repo 3, and does not amend their Accepted prose.
**Related**:
- [ADR-014 Substrate Ownership and Data Governance Mobility](ADR-014-substrate-ownership-and-data-governance-mobility.md) (Accepted) -- §"What this does not commit to" already names the "op-log segment format" as a substrate-owned load-bearing format spec, and disclaims any specific CRDT vendor stack as load-bearing. This ADR operationalizes that commitment as a routing decision; it does not extend or contradict it.
- [ADR-015 Three-Way Substrate Repo Split](ADR-015-three-way-substrate-repo-split.md) (Accepted) -- §Repo 3 specifies the operator-blind blind-sync server (encrypted op-log segments + CAS + capability verifier + fixed-shape sync event format). This ADR routes the blind-side sync implementation to that repo (Phase C, DIR `05efc833`) by reference.
- [ADR-019 EnvelopeSpec ABC](ADR-019-envelope-spec-abc.md) (Accepted) -- the substrate-side floor-enforcement contract (AEAD + key non-custody + bounded cleartext-metadata allowlist) that the operator-blind sync layer composes above the op-log format.
- [ADR-023 Backend Registration Mechanism](ADR-023-backend-registration-mechanism.md) (Accepted) -- the `GraphBackend` ABC + `BackendConformance` pytest11 plugin + `InMemoryBackend` reference precedent this ADR points to as the shape a future op-log interface + conformance suite + reference implementation should mirror.
- [RFC-002 Substrate-side AGE Index Recommendations](../../rfcs/RFC-002-substrate-age-index-recommendations.md) (Draft) -- precedent for a substrate spec that is Draft-until-downstream-validates; the candidate RFC-003 named below follows the same posture.
- [Phase 12 SYNTHESIS.md](../../phases/phase-12/SYNTHESIS.md) -- the multi-vendor research synthesis this ADR is grounded in and cites throughout.
- Inbound demand `f08da510` (evilleAI -> mimidAI) -- the demand this ADR's routing answer closes; DIR `5d67abf4` is the scope-marker this ADR resolves.

## Decision Record

| Date | Author | Action |
|------|--------|--------|
| 2026-05-28 | @jdobb | Proposed. Phase 12 Wave 6 draft, drafted after and grounded in [SYNTHESIS.md](../../phases/phase-12/SYNTHESIS.md) (the informed/blind multi-vendor research spike across the reused corvidAI roster). Encodes the locked routing decisions D1-D5 from [phase-12 CONTEXT.md](../../phases/phase-12/CONTEXT.md). The concrete op-log interchange-format spec / Sync ABC is deferred to a named follow-on (candidate RFC-003 + a focused phase) per D3/OQ-4; the blind-side sync implementation is handed to Phase C by reference. The cross-repo concurrence round and the flip to Accepted are a deferred follow-on per D4 (evilleAI's deployment posture is Pending its Phase 46; the op-log format is posture-neutral, so this routing is robust to either resolution). |

## Context

Two consumers have surfaced offline-tolerant ("CRDT-shaped") sync as a substrate gap:

- evilleAI's collectors ship observed events to a central hub through a fixed-size on-disk retry queue (`collectors/common/retry_queue.py`), which is fragile under sustained offline periods: it overflows and silently drops data, or replays produce duplicates and ordering anomalies (inbound demand `f08da510`; evilleAI DIR `8784616b`).
- LaiR needs operator-blind, offline-first, log-structured opaque sync as its Lane-2 default posture (LaiR spec-skeleton §Promise 12).

Phase 9 (D3) deferred the CRDT routing decision precisely because a rushed answer risked substantively-wrong framing, and reserved a focused phase (DIR `5d67abf4`). This is that phase. Its deliverable is the routing decision, grounded in a multi-vendor research spike rather than a single-perspective guess.

The substrate already operates as a four-layer family: substrate-core (the stdlib-only, zero-runtime-dependency library), the open (plaintext-server) deployment sibling, the blind (operator-blind) deployment sibling, and the three consumers. The routing question is: across those four layers, who owns what part of offline-tolerant sync?

The answer is largely pre-figured by Accepted prose. ADR-014 §"What this does not commit to" already states that the substrate owns format/interface specs (canonical export schema, op-log segment format, capability token shape, the `GraphBackend` ABC) and that no specific CRDT vendor stack (Automerge 3, Hypercore, Yjs, etc.) is a load-bearing substrate commitment. 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. This ADR makes the cross-layer routing explicit and grounds it in evidence.

The spike ran informed/blind paired prompts across the reused corvidAI roster (Codex informed + blind-from-`/tmp`, a diversified second codex-blind pass, opencode-qwen blind, Claude subagent informed) over a three-seed cluster: (01) the ownership boundary + battle-tested op-log/CRDT format patterns, (02) the operator-blind encrypted-sync wing, (03) the plaintext-server wing + consumer-facing API. The findings, the convergence/divergence, and the EC-9 vendor-degradation note (opencode was largely unavailable in the dispatch window; Seed 01's second blind was recovered via a diversified codex pass) are recorded in [SYNTHESIS.md](../../phases/phase-12/SYNTHESIS.md) and the per-seed triages.

## Decision

Route offline-tolerant sync across the four layers as follows.

### 1. Substrate-core owns a shared, posture-neutral op-log interchange surface (D2)

Substrate-core retains and owns a **versioned, posture-neutral op-log LOGICAL/INTERCHANGE format** (an envelope), plus a thin interface and a conformance suite. It does not own the physical storage layout, the merge/CRDT engine, the reconciliation engine, encryption, transport, compaction, or oblivious-access machinery.

The decisive distinction the spike surfaced (attested by PostgreSQL logical-vs-physical replication, git's negotiation-vs-packfile split, and Debezium-style change-data-capture) is **logical interchange format vs physical storage format**. A logical interchange format is portable across deployment postures and engine versions precisely because it is decoupled from physical storage; the physical layer is binary-coupled to one engine. 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. 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 spike was unanimous that "format-only, engine-swappable" is only partly achievable: the byte container/envelope can be engine-neutral, but the merge semantics of the payload are inseparable from a CRDT model. The routing consequence: **the substrate owns the envelope and treats the merge payload as an opaque, model-tagged region it does not interpret.** Named merge profiles (or just the model tag) are carried, not executed, in core.

### 2. The machinery routes to the open + blind deployment siblings and the consumers (D2)

| Layer | Owns | Does not own |
|---|---|---|
| substrate-core (zero-dep) | The op-log interchange envelope (segment framing, actor id + monotonic counter, causal/version metadata, content-addressed identity, a model tag, a reserved snapshot-segment type, a forward-compat "preserve unknown fields" rule); a thin op-log interface; the conformance suite; an event-sourced reference implementation. | Any CRDT/merge engine; physical storage; transport; reconciliation engine; encryption; compaction policy; oblivious-access machinery. |
| open-deployment (plaintext) | The physical SQLite/Postgres layout; the plaintext server with server-assigned total order; the durable change-feed + cursor; idempotent apply; snapshot + tail hydration. | The interchange format spec (it consumes it). |
| blind-deployment (operator-blind) | Per-segment AEAD; the capability verifier; the content-addressed opaque store; the RBSR/Negentropy reconciliation engine; client-side compaction; any gated oblivious-access layer. | The interchange format spec and the EnvelopeSpec contract (it consumes them). |
| consumers | The client durable outbox/WAL; the sync-API binding; conflict-handling policy. | The format, the engine, and the server. |

For the plaintext wing, the spike converged on the engineering pattern that fixes the `retry_queue.py` failure modes: a durable append-only client outbox (disk-bounded with explicit backpressure, never silent eviction), at-least-once transport with idempotent server apply keyed on a stable op id, server-assigned total order, catch-up by monotonic change-feed + durable opaque cursor, and hydration by snapshot-at-cursor + incremental tail. A full CRDT is overkill for a single-authority server, and range-based reconciliation is a blind-wing / peer concern, not a plaintext-wing one.

For the blind wing, per-segment AEAD + key non-custody + a small positive cleartext allowlist instantiates the ADR-019 EnvelopeSpec contract; RBSR/Negentropy over ciphertext hashes is the reconciliation engine, which consumes a substrate-owned ordered key and a cryptographically secure fingerprint function. The blind-side implementation is handed to Phase C (DIR `05efc833`) by reference; Willow Confidential Sync is named as the closest published reference architecture for that work.

### 3. Vendor-neutral naming (D5)

Consistent with ADR-014 §"What this does not commit to", no vendor stack is a load-bearing substrate commitment. This ADR names current-best-fit references non-bindingly only: **Automerge 3** (columnar op-log; chunk framing + change-hash), **Yjs / Y-CRDT** (lib0 update encoding; state-vector diff), and **Hypercore** (append-only signed opaque-blob log) for the format/op-log axis; **Negentropy / range-based set reconciliation** and Merkle Search Trees for the reconciliation axis; and **Willow Confidential Sync** for the blind-wing reference architecture. These are portable only inside their own families at the payload layer; the substrate owns the envelope and the interface, not any of these stacks.

### 4. The concrete spec / ABC is deferred to a named follow-on (D3, OQ-4)

The concrete op-log interchange-format spec and/or Sync ABC is deferred to a focused follow-on: **candidate RFC-003 (op-log interchange-format spec)** plus a focused phase. This ADR alone is a valid phase close (D3): the routing decision is the load-bearing deliverable, and the format's coupling to a CRDT model deserves the careful pass Phase 9 D3's caution reserved.

The spike's evidence on granularity, recorded here as input to that follow-on:

- The shared artifact should be a **format spec + a thin interface + a conformance suite**, not format-only. Format-only lets two implementations silently diverge on edge cases; the conformance suite is the load-bearing part, and the repo already proves the pattern with the `GraphBackend` ABC + `BackendConformance` plugin + `InMemoryBackend` reference (ADR-023). The follow-on should mirror that shape.
- A thin floor is cheap and **irreversible-if-skipped**: the envelope framing, the content-addressing/hashing convention, and the forward-compat "preserve unknown fields" discipline cannot be retrofit cheaply (the surveys cite Automerge's preserve-unknown-columns rule as the proof). These are the follow-on's highest-priority, earliest deliverables. Pulling that thin floor forward into the present phase is a scope decision reserved to the operator; the locked plan defers it.

### 5. Land Proposed + consumer notices; defer the concurrence round and the Accepted flip (D4)

This ADR lands Proposed. Phase 12 closes demand `f08da510` with this routing answer + a link to this ADR, and files consumer notices to evilleAI, LaiR, and corvidAI. The cross-repo concurrence round and the flip to Accepted are a deferred follow-on: evilleAI's deployment posture is Pending its Phase 46 privacy-posture dispatch, so it cannot fully concur on its consumer-direct shape yet. The op-log interchange format is posture-neutral by design, so this routing is robust to whichever way Phase 46 resolves.

### Reconciliation with Accepted ADR prose (no contradiction)

This ADR reconciles by cross-reference and does not contradict Accepted prose:

- **ADR-014 §"What this does not commit to"**: that section names the op-log segment format as a substrate-owned load-bearing format spec and disclaims a load-bearing CRDT vendor stack. This ADR's Decision 1 (substrate owns the interchange format) and Decision 3 (vendor-neutral naming) operationalize that commitment; they do not extend the substrate's commitments or name any vendor as load-bearing.
- **ADR-015 §Repo 3**: that section assigns the blind-sync server (encrypted op-log + CAS + capability verifier + fixed-shape sync event format) to the operator-blind deployment sibling. This ADR's Decision 2 routes the blind-side engine, server, and encryption to that sibling and clarifies that the "fixed-shape sync event format" the blind server uses is an instance of the substrate-owned interchange envelope plus the ADR-019 EnvelopeSpec cleartext allowlist. No structural commitment in ADR-015 §Repo 1 / §Repo 2 / §Repo 3 changes.

If a future revision of this ADR were found to contradict that Accepted prose rather than reconcile with it, that is a scope-expansion decision (an amendment to Accepted prose or a "supersedes" header), not an in-flight edit, and is out of scope for this Proposed draft.

## Alternatives Considered

- **Push everything down to the deployment siblings (no shared substrate format).** Rejected (D2). It risks the two siblings diverging on op-log shape, which breaks canonical export and the ADR-014 §Long-term cross-subgraph-query goal. The spike's one developed counterargument regime (push-down is correct only if cross-deployment exchange is purely aspirational) is recorded as an open question below, not adopted as the decision.
- **Commit to a specific CRDT primitive / vendor stack in the substrate.** Rejected (D5). It contradicts ADR-014 §"What this does not commit to", which is Accepted and binding.
- **Land the concrete op-log format spec and/or Sync ABC in this phase.** Deferred (D3). The routing decision is the load-bearing deliverable; the format's CRDT-model coupling, the ORAM proportionality question, and the ordering-key leakage choice are consequential enough to warrant the named follow-on. The thin irreversible-if-skipped floor is flagged for that follow-on's earliest work.
- **Run the cross-repo concurrence round and flip to Accepted in this phase.** Rejected (D4). evilleAI can only concur conditionally before its Phase 46 resolves; an in-phase concurrence round would be heavy and multi-day for a routing answer that is posture-neutral and robust to that resolution. Proposed + notices now, concurrence + Accepted later.

## Consequences

**Positive.**

- One op-log interchange shape across the open and blind siblings keeps canonical export and future cross-subgraph queries tractable, instead of requiring pairwise translators between divergent change-log formats.
- Consumers get a stable, posture-neutral sync-API contract direction, so the plaintext and blind wings do not fork the sync surface (the same risk the `GraphBackend` ABC was created to prevent).
- Substrate-core stays stdlib-only and zero-runtime-dependency: it owns a format + a thin interface + tests, never a CRDT engine.
- The demand `f08da510` is answered with a routing direction the consumers can plan against now, even though the concrete spec is deferred.

**Negative / risks.**

- The concrete interchange-format spec and Sync ABC are deferred, so consumers cannot yet implement against a finished contract. The thin floor (preserve-unknown-fields, content-addressing, envelope framing) is irreversible-if-skipped and must be the follow-on's earliest work; this ADR flags it but does not land it.
- Whether cross-subgraph query / canonical export across the plaintext<->blind boundary is a near-term goal or a long-term aspiration is unresolved (see Open Questions). That single fact bounds how much of the shared envelope is justified now.
- The spike's blind-arm vendor diversity was degraded for Seed 01 (both blinds were codex-family due to an opencode outage; EC-9). The Seed-01 convergence should be read with that correlation discount, recorded in the triage and SYNTHESIS.

**Neutral.**

- The blind-side sync implementation moves to Phase C (DIR `05efc833`) and the Postgres+AGE work to Phase D (DIR `7ca37620`); this ADR changes no code and ships no implementation.

## Open Questions

- **OQ-1 (cross-subgraph scope).** Is cross-subgraph query / canonical export across the plaintext<->blind boundary a near-term goal or a long-term aspiration? ADR-014 §Long-term names it as a long-term governance-plane goal, which justifies the shared interchange format; this ADR states that the driver is long-term, and the follow-on should confirm the scope before finalizing the format. Resolved by: the RFC-003 follow-on.
- **OQ-2 (ORAM proportionality).** For the operator-blind posture, is read-access-pattern obliviousness in scope, and if so does it displace difference-proportional reconciliation? The spike found Write-Only ORAM's threat model (a multi-snapshot disk adversary that cannot see reads) is a mismatch for an online relay, and Path ORAM on the index would fight RBSR. Resolved by: Phase C posture design.
- **OQ-3 (ordering-key leakage).** Pseudorandom/epoch ordering keys (hide chronology) vs quantized timestamp buckets (simpler range semantics) materially change the blind format's leakage profile. Resolved by: the RFC-003 follow-on / Phase C.
- **OQ-4 (RFC-003 scope and number).** This ADR softly reserves RFC-003 for the op-log interchange-format spec. Whether the follow-on is a single RFC + phase or splits the plaintext and blind format concerns is left to the follow-on's discuss step.

## References

- [Phase 12 SYNTHESIS.md](../../phases/phase-12/SYNTHESIS.md) -- the cross-seed routing synthesis this ADR is grounded in.
- [Phase 12 dispatch triages](../../phases/phase-12/dispatch/synthesis/) -- per-seed convergence/divergence, EC-8 oath checks, EC-9 degradation, EC-10 citation-hygiene checks.
- [ADR-014 Substrate Ownership and Data Governance Mobility](ADR-014-substrate-ownership-and-data-governance-mobility.md) -- §"What this does not commit to" + §Long-term.
- [ADR-015 Three-Way Substrate Repo Split](ADR-015-three-way-substrate-repo-split.md) -- §Repo 3 + §Migration Plan §Phase C.
- [ADR-019 EnvelopeSpec ABC](ADR-019-envelope-spec-abc.md) -- the floor-enforcement contract the operator-blind sync composes above the op-log.
- [ADR-023 Backend Registration Mechanism](ADR-023-backend-registration-mechanism.md) -- the ABC + conformance-suite + reference-implementation pattern the op-log interface should mirror.
- [RFC-002 Substrate-side AGE Index Recommendations](../../rfcs/RFC-002-substrate-age-index-recommendations.md) -- Draft-until-downstream-validates precedent for the candidate RFC-003.
- External (non-binding current-best-fit, named not vendored): Automerge (automerge.org), Yjs / Y-CRDT (docs.yjs.dev), Hypercore (hypercore-protocol), Negentropy / range-based set reconciliation (NIP-77; arXiv:2212.13567), Merkle Search Trees (Auvolat and Taiani, SRDS 2019), Willow Confidential Sync, CouchDB/PouchDB replication protocol, Replicache, PowerSync, RxDB, ElectricSQL. Production encrypted-log baselines: Standard Notes, Notesnook, secsync.
- Inbound demand `f08da510` (evilleAI) and DIR `5d67abf4` (CRDT-shaped offline-tolerant sync routing scope-marker) -- closed/disposed by this ADR in Phase 12 Wave 7.

======== INLINED: ADR-014 section "What this does not commit to" (ACCEPTED -- must not be contradicted) ========
- A specific vendor stack at the storage, CRDT, capability-token, or sync-transport layers. Automerge 3, Hypercore, Standard-Notes key hierarchy, macaroons / UCAN, Postgres + Apache AGE, SQLite -- these are the current best-fit implementations across the family. They are not load-bearing substrate commitments; the load-bearing commitments are the format / interface specs the substrate owns (canonical export schema, op-log segment format, capability token shape, the GraphBackend ABC).
- (Long-term) Cross-subgraph queries across deployment topologies become a tractable substrate problem.

======== INLINED: ADR-015 section "Repo 3 -- Operator-blind substrate" (ACCEPTED -- must not be contradicted) ========
- Blind-sync server: receives encrypted op-log segments + capability-attenuated reads, stores opaque blobs in CAS keyed on storage_index, runs no graph compute.
- Write-Only ORAM on chunk sync; Path ORAM on capability/slot index.
- Fixed-shape sync event format is the blind substrate's responsibility (K-flush quantization; weekly free-space rotation); DP-noising of sync telemetry lives client-side, above the substrate.
- Implement the blind-sync server (CAS + capability verifier + op-log append) as a reference implementation; its first ADRs cover op-log format, capability-verifier semantics, and CRDT integration.

======== SYNTHESIS conclusions (for the citation/consistency check; the ADR must not assert beyond these) ========
- Cross-seed convergent verdict: substrate-core owns a versioned posture-neutral op-log LOGICAL/INTERCHANGE format + thin interface + conformance suite (payload opaque/model-tagged); engines/servers/encryption/reconciliation route to the open+blind siblings; consumers own the durable outbox + sync-API binding.
- "Format-only engine-swappable" is partly a fiction (merge payload is model-coupled).
- Recommend format+thin-ABC+conformance over format-only; ADR-026-alone is a valid close (defer concrete spec to candidate RFC-003); the envelope-framing + content-addressing + preserve-unknown-fields floor is irreversible-if-skipped and flagged as the follow-on's earliest items.
- Blind wing: per-segment AEAD + key non-custody + bounded cleartext allowlist (EnvelopeSpec); RBSR/Negentropy reconciliation; ORAM NOT the default (WoORAM threat model = multi-snapshot disk, not online relay); Willow Confidential Sync = closest reference architecture; blind impl handed to Phase C.
- Plaintext wing: durable outbox + at-least-once + idempotent apply + server-assigned order + change-feed/cursor + snapshot/tail hydration; CRDT overkill for single authority.
- EC-9: opencode largely unavailable in the dispatch window; Seed 01 second blind via diversified codex pass (both codex-family). Citation hygiene honored (no copyleft code, no paywalled paste).

QUESTION (answer at the end): Where does the ADR contradict the inlined ADR-014/015 Accepted prose, misstate a routing decision, or assert something the synthesis conclusions do not support?

codex
**Findings**

1. **CONTRACT**  
Offending text: “**any gated oblivious-access layer**” and “**OQ-2 (ORAM proportionality). For the operator-blind posture, is read-access-pattern obliviousness in scope...**”

Problem: ADR-015 Accepted prose already commits Repo 3 to “Write-Only ORAM on chunk sync; Path ORAM on capability/slot index.” ADR-026 demotes ORAM to optional/gated and reopens whether it is in scope. That contradicts ADR-015 unless ADR-026 explicitly proposes an amendment, which it says it does not.

Concrete fix: Replace the blind-deployment row and OQ-2 with language that preserves ADR-015 as binding, e.g. “blind-deployment owns the ADR-015-committed Write-Only ORAM on chunk sync and Path ORAM on capability/slot index; Phase C determines integration details and proportionality limits without removing the Accepted commitment.” If the intent is to remove ORAM, add a Supersedes/Amends header and make this an explicit ADR-015 amendment.

2. **CONTRACT / CORRECTNESS**  
Offending text: “**The blind-side implementation is handed to Phase C... Willow Confidential Sync is named as the closest published reference architecture for that work.**” plus OQ-2’s statement that “**Write-Only ORAM's threat model... is a mismatch for an online relay, and Path ORAM on the index would fight RBSR.**”

Problem: The synthesis supports “ORAM NOT the default,” but ADR-015 Accepted prose still commits ORAM. ADR-026 currently lets the synthesis drive a changed blind architecture without reconciling the binding ADR-015 commitment. The issue is not that Willow/RBSR are unsupported; it is that they are presented as the operative blind-side route while the accepted ORAM route is treated as questionable.

Concrete fix: State that RBSR/Negentropy and Willow are non-binding Phase C inputs that must be reconciled with ADR-015’s committed WoORAM/Path ORAM unless ADR-015 is amended. Add an explicit sentence in Decision 2 or Reconciliation: “This ADR does not remove ADR-015’s ORAM commitments.”

3. **CONTRACT**  
Offending text: “**clarifies that the ‘fixed-shape sync event format’ the blind server uses is an instance of the substrate-owned interchange envelope plus the ADR-019 EnvelopeSpec cleartext allowlist.**”

Problem: ADR-015 says the “Fixed-shape sync event format is the blind substrate’s responsibility (K-flush quantization; weekly free-space rotation).” ADR-026 risks reassigning that blind-owned responsibility to substrate-core by calling it an instance of the substrate-owned envelope. That may be intended as layering, but the text is too strong and can be read as changing ownership.

Concrete fix: Split the responsibilities explicitly: substrate-core owns only the posture-neutral op-log segment envelope; blind-deployment owns the fixed-shape sync event format, K-flush quantization, weekly free-space rotation, and any leakage-shaping rules that wrap or schedule those envelope segments.

4. **CORRECTNESS**  
Offending text: “**the substrate-owned ordered key and a cryptographically secure fingerprint function**”

Problem: The inlined synthesis says RBSR/Negentropy consumes “a substrate-owned ordered key and a cryptographically secure fingerprint function,” but ADR-026 also defers ordering-key leakage to OQ-3. As written, Decision 2 sounds like the ordered key is already settled enough for blind implementation routing, while OQ-3 says pseudorandom/epoch keys vs timestamp buckets remains open.

Concrete fix: Qualify this as a follow-on input: “consumes a substrate-owned ordered-key abstraction whose concrete leakage profile is deferred to RFC-003 / Phase C.”

5. **STYLE / CORRECTNESS**  
Offending text: “**the concrete op-log interchange-format spec and/or Sync ABC is deferred**” and “**candidate RFC-003 (op-log interchange-format spec)**”

Problem: The contract asks to defer “the concrete format-spec/Sync ABC to a named follow-on (candidate RFC-003).” ADR-026 mostly does this, but “and/or” weakens the commitment by leaving ambiguous whether the Sync ABC is definitely in the follow-on.

Concrete fix: Say directly: “The concrete op-log interchange-format spec, thin Sync ABC, conformance suite, and reference implementation shape are deferred to candidate RFC-003 plus a focused phase.”

**Answer**

The material contradictions are with ADR-015 Repo 3: ADR-026 reopens or demotes the accepted ORAM commitments, and it blurs ownership of the blind fixed-shape sync event format. It otherwise satisfies the main ADR-014 vendor-neutrality and Phase 12 citation requirements.
tokens used
29,658
**Findings**

1. **CONTRACT**  
Offending text: “**any gated oblivious-access layer**” and “**OQ-2 (ORAM proportionality). For the operator-blind posture, is read-access-pattern obliviousness in scope...**”

Problem: ADR-015 Accepted prose already commits Repo 3 to “Write-Only ORAM on chunk sync; Path ORAM on capability/slot index.” ADR-026 demotes ORAM to optional/gated and reopens whether it is in scope. That contradicts ADR-015 unless ADR-026 explicitly proposes an amendment, which it says it does not.

Concrete fix: Replace the blind-deployment row and OQ-2 with language that preserves ADR-015 as binding, e.g. “blind-deployment owns the ADR-015-committed Write-Only ORAM on chunk sync and Path ORAM on capability/slot index; Phase C determines integration details and proportionality limits without removing the Accepted commitment.” If the intent is to remove ORAM, add a Supersedes/Amends header and make this an explicit ADR-015 amendment.

2. **CONTRACT / CORRECTNESS**  
Offending text: “**The blind-side implementation is handed to Phase C... Willow Confidential Sync is named as the closest published reference architecture for that work.**” plus OQ-2’s statement that “**Write-Only ORAM's threat model... is a mismatch for an online relay, and Path ORAM on the index would fight RBSR.**”

Problem: The synthesis supports “ORAM NOT the default,” but ADR-015 Accepted prose still commits ORAM. ADR-026 currently lets the synthesis drive a changed blind architecture without reconciling the binding ADR-015 commitment. The issue is not that Willow/RBSR are unsupported; it is that they are presented as the operative blind-side route while the accepted ORAM route is treated as questionable.

Concrete fix: State that RBSR/Negentropy and Willow are non-binding Phase C inputs that must be reconciled with ADR-015’s committed WoORAM/Path ORAM unless ADR-015 is amended. Add an explicit sentence in Decision 2 or Reconciliation: “This ADR does not remove ADR-015’s ORAM commitments.”

3. **CONTRACT**  
Offending text: “**clarifies that the ‘fixed-shape sync event format’ the blind server uses is an instance of the substrate-owned interchange envelope plus the ADR-019 EnvelopeSpec cleartext allowlist.**”

Problem: ADR-015 says the “Fixed-shape sync event format is the blind substrate’s responsibility (K-flush quantization; weekly free-space rotation).” ADR-026 risks reassigning that blind-owned responsibility to substrate-core by calling it an instance of the substrate-owned envelope. That may be intended as layering, but the text is too strong and can be read as changing ownership.

Concrete fix: Split the responsibilities explicitly: substrate-core owns only the posture-neutral op-log segment envelope; blind-deployment owns the fixed-shape sync event format, K-flush quantization, weekly free-space rotation, and any leakage-shaping rules that wrap or schedule those envelope segments.

4. **CORRECTNESS**  
Offending text: “**the substrate-owned ordered key and a cryptographically secure fingerprint function**”

Problem: The inlined synthesis says RBSR/Negentropy consumes “a substrate-owned ordered key and a cryptographically secure fingerprint function,” but ADR-026 also defers ordering-key leakage to OQ-3. As written, Decision 2 sounds like the ordered key is already settled enough for blind implementation routing, while OQ-3 says pseudorandom/epoch keys vs timestamp buckets remains open.

Concrete fix: Qualify this as a follow-on input: “consumes a substrate-owned ordered-key abstraction whose concrete leakage profile is deferred to RFC-003 / Phase C.”

5. **STYLE / CORRECTNESS**  
Offending text: “**the concrete op-log interchange-format spec and/or Sync ABC is deferred**” and “**candidate RFC-003 (op-log interchange-format spec)**”

Problem: The contract asks to defer “the concrete format-spec/Sync ABC to a named follow-on (candidate RFC-003).” ADR-026 mostly does this, but “and/or” weakens the commitment by leaving ambiguous whether the Sync ABC is definitely in the follow-on.

Concrete fix: Say directly: “The concrete op-log interchange-format spec, thin Sync ABC, conformance suite, and reference implementation shape are deferred to candidate RFC-003 plus a focused phase.”

**Answer**

The material contradictions are with ADR-015 Repo 3: ADR-026 reopens or demotes the accepted ORAM commitments, and it blurs ownership of the blind fixed-shape sync event format. It otherwise satisfies the main ADR-014 vendor-neutrality and Phase 12 citation requirements.
