Joint Findings Register — Round 3 Draft

Date: 2026-07-16 Authors: Claude and Codex working record; this Round-3 draft is Codex-authored for Claude's attack in Round 4 Scope: union of tmp/codex-notes/2026-07-16d-codex-adversarial-review.md and tmp/review/2026-07-16c-adversarial-architecture-review.md, as resolved or held in rounds 0–2 Review mode: documentation only; no source changes, generation, render, editorial, eval, acceptance, migration, or live-source runs were performed in this session

1. Reading rules

This is a register of failure modes, not reviewer votes. One row is one falsifiable invariant even where many code sites participate. Test findings map to the invariant they fail to enforce unless the test mechanism is itself the independent failure. Parent objectives do not inflate severity by counting their children.

Severity and releaseability are separate. The charter contains the controlling rule. This draft contains no P0 finding. That does not make the repository releasable: a high-confidence P1 can block a capability or release.

Abbreviations:

• X-P1-01 means Codex review finding P1-01. CA–CG mean Claude appendices A–G.
• H/M are high/medium evidence confidence. Current-practice includes recorded operating practice in STATE.md and acceptance records, not merely an automated CLI.
• RB is the separate release-blocker field: Y, N, or a named capability.
• Resolution: A = agreed or unchallenged; CH = held severity/calibration (the row or §7 names the holder); EA = escalate to Adam. A CH row still records agreement that the failure exists.
• Protocol references: EP-WP = engineering protocol lines 7–15; EP-CS = lines 17–25; EP-TEST = 49–70; EP-OPS = 81–95; EP-DG = 98–105; EP-AUTH = 107–112; EP-LLM = 114–121; EP-SF = 132–150; EP-SUP = 28–47.

2. Severity amendment and the accepted-week precision record

Claude's reachability amendment is ACCEPTED. Recorded operating practice evidenced by living docs and acceptance records is a current reachability path. STATE.md:71-85 calls 16a accepted and records gate/eval claims; the lane-B record identifies the exact delivered JSON, view and HTML hashes and regenerates the system snapshot from that JSON (tmp/codex-notes/2026-07-16a-laneB-dual-gate-16a.md:9-25,198-220).

The amendment does not mechanically produce P0. For 16a, the manual precision review, delivered-artifact gate and SHA chain are effective artifact-specific containment. They do not repair the systemic command path or the reader-view projection gap. The register therefore splits them:

• F-001: eval projection can contain terms that the delivered view does not show — P1, release-blocking.
• F-002: automated acceptance can gate/score sibling or pre-editorial artifacts — P1, release-blocking; 16a itself is manually provenance-chained, while the accept-command metric receipt and sibling render remain outside that chain.

Claude explicitly allowed the outcome “P1 + release-blocking with the recorded-practice fact”; no Adam escalation is needed on those two rows unless Round 4 rejects the split.

3. Ranked register

3.1 P1 — release-blocking or capability-blocking

3.2 P1 — material but not a universal release blocker

3.3 P2 — structural, local, test-quality, or conditionally reachable

4. Remediation packets

Every F-ID inherits all five fields from its packet below. A row-specific change condition in §3 overrides the packet where more precise. “Historical” means inspect and repair/quarantine existing state; it never means fabricate authority that no longer exists.

5. Diagram slug mapping

All slugs currently used in the current/future architecture drafts resolve here. Multiple slugs may intentionally map to one invariant; artifact-lineage maps to two because identity and filename convention are distinct failures.

flowchart LR
    A[Acceptance and report] --> F001[F-001 eval-projection]
    A --> F002[F-002 eval-lineage / gate-pre-editorial]
    A --> F003[F-003 render-fork]
    A --> F005[F-005 editorial-silent-delete / allowlist-from-untrusted]
    A --> F007[F-007 artifact-naming]
    A --> F008[F-008 telemetry-slot]
    A --> F009[F-009 render-mutates-input]
    A --> F010[F-010 gate-expectations]
    A --> F011[F-011 allow-drift-splice]

    D[Durable state and sync] --> F017[F-017 tombstones-dropped]
    D --> F018[F-018 no-410-recovery]
    D --> F024[F-024 ledger-nonatomic]
    D --> F059[F-059 email-collision-split]

    T[Typed authorities] --> F047[F-047 status-two-semantics]
    T --> F048[F-048 prose-protocol]
    T --> F054[F-054 week-dual-semantics]
    T --> F055[F-055 money-prose]
    T --> F056[F-056 unit-regexes]
    T --> F057[F-057 source-id-grammars]
    T --> F058[F-058 gate-name-matching]

    L[LLM boundary] --> F066[F-066 msg-call-atoms-unverified]
    L --> F067[F-067 subject-unbound]
    L --> F069[F-069 delimiter-injectable / injection-tests-tautological]
    L --> F070[F-070 LLM silent disappearance]
    L --> F072[F-072 no-cost-ceiling]
    L --> F073[F-073 agentic-scope]
    L --> F041[F-041 agentic-pii]

    S[Structure] --> F075[F-075 layer-inversion / model-in-presentation]
    S --> F076[F-076 god-module]

6. Source-review coverage map

This appendix proves union coverage without duplicating findings as votes.

Codex review

The eight items Claude underweighted in synthesis are explicitly present: F-020, F-066, F-067, F-023, F-059, F-041, F-027 and F-035.

Claude appendices

7. Register-level decisions still open

1. Held calibration: F-047 remains Claude-held at P0 versus Codex P1 because Claude rejects manual buyer checks as effective containment. F-063, F-073, F-075 and F-076 retain their previously recorded held labels; release blocks and phases remain as stated, so no safety action depends on winning those label arguments.
2. Positional evidence precision — AGREED(R4): F-057 records normal-path ledger remapping, current positional cache payloads and fallback reachability separately at P2 with explicit promote conditions.
3. Adam decisions about the canonical artifact and 16a status live in the charter; this register does not silently resolve product authority.

Remediation Charter — Round 3 Draft

Date: 2026-07-16 Status: joint architecture draft; Codex-authored in Round 3 for Claude's Round-4 attack and Adam's decisions Authority: the joint findings register, rounds 0–2, the engineering protocol, and the active person-node plan Execution state: nothing in this charter has been implemented or run

1. Mandate, outcome and non-goals

The program outcome is not “fewer regexes” or “smaller files.” It is a weekly-report system in which:

1. the exact delivered report is content-bound to the inputs, code/config/schema, coverage, editorial state, eval projection, gates and acceptance record that certify it;
2. core concepts have one typed authority and can no longer be redefined through prose, filename, prefix, env, display-name or call-order conventions;
3. external and LLM inputs fail closed into visible bounded states rather than valid-looking emptiness;
4. durable facts, identity, evidence and metrics have D1-compatible atomic lifecycle invariants;
5. forward prevention is paired with a receipt-producing audit and repair/quarantine of state already made stale, split, ambiguous or unverifiable; and
6. structural decomposition is performed only after trustworthy behavioral rulers and typed seams exist.

This is a strangler program, not a rewrite. It does not authorize any code change, generation, migration, render, editorial, eval, acceptance, live OnePage/Graph access, person-node P6 run, or branch creation. Those require a later approved execution plan and the existing Adam gates.

2. Severity, releaseability and disagreement discipline

2.1 Controlling rule — AGREED(R2), Claude amendment ACCEPTED(R3)

Severity is not the release verdict. For every finding record impact, evidence confidence, reachability

through a currently supported path, and effective containment. P0 requires all four: (1) catastrophic integrity,

security, privacy, or external-acceptance impact; (2) high-confidence evidence of the complete failure path;

(3) reachability now through ordinary supported operation, the documented release command, **or the recorded

operating practice of the project as evidenced in its living docs and acceptance records**, without a speculative

future deployment or an explicit emergency bypass; and (4) no effective containment before harm. If confidence or

reachability is conditional, or containment materially limits the blast radius, cap at P1. P1 is a material

correctness, governance, security, or reliability failure and may be release-blocking for the affected capability

even when it is repairable, operator-gated, partially contained, or awaiting one reachability fact. P2 is a local,

structural, test-quality, or maintainability defect with no proven current material failure. Vote count, reviewer

count, LOC, and rhetorical force never affect severity. Every disputed P0/P1 records both its containment and the

concrete fact that would promote or demote it.

Response to Claude's amendment: ACCEPTED. Living documentation and acceptance records are operational evidence, not hearsay. Excluding them would allow a routinely used manual release path to evade reachability.

Application to 16a and the lineage dispute: recorded practice satisfies the reachability conjunct. It does not satisfy the “no effective containment” conjunct. Lane B recorded delivered-artifact hashes, regenerated its snapshot from 16a JSON, reviewed the final rows, and ran the manual gate on the editorial set. That is real, artifact-specific containment. The systemic command remains unable to reproduce the guarantee unattended, and its broader eval projection remains unsafe. F-001 and F-002 are therefore P1 and release-blocking. This is not a compromise average; it is the result of applying all four conjuncts.

2.2 Release policy

A finding blocks a release/capability when it violates a hard artifact-identity, reader-view acceptance, source-completeness, trust-boundary, durable-state, migration, tenant-isolation, or governance invariant in that capability. A P0 label is not required. Conversely, a pile of P2s does not create a release block by vote count.

No forced consensus is permitted. Register rows marked Codex-held survive unchanged into the next round. If round 6 ends without convergence, the exact alternatives and operational consequence go to Adam; neither agent rewrites the other's position as agreement.

3. Canonical artifact and release manifest — AGREED(R2), Adam ratification required

The canonical artifact is deliberately two-level:

• Canonical semantic source: a versioned, application-level WeeklyReportDocument serialized as canonical JSON. It contains deterministic business/publication meaning, typed coverage and explicit unavailable/abstained states.
• Accepted and delivered report: the exact final HTML bytes selected for the reader, identified by content hash in one immutable ReportReleaseManifest. Filenames are labels, not identity.

Editorial is a declared transformation. If it is not requested, the manifest records not_requested and base view may become final. If requested, pre-editorial HTML is an intermediate and cannot be the accepted report. Editorial failure is failed or quarantined, never an implicit pass-through green.

sequenceDiagram
    autonumber
    participant S as Source coverage receipt
    participant P as Profile input
    participant D as Canonical WeeklyReportDocument
    participant B as Base publication view
    participant E as Editorial stage
    participant F as Final publication view
    participant H as Delivered HTML bytes
    participant X as Reader-view eval projection
    participant M as ReportReleaseManifest
    participant A as Immutable acceptance record

    S->>M: project/scope/cursor/status hash
    P->>M: profile hash + run identity
    P->>D: pure assemble + enrich
    D->>M: schema/version/content hash
    D->>B: deterministic view projection
    B->>M: base-view hash
    B->>E: declared requested/not_requested stage
    E->>M: input/output/model/validator hashes + disposition
    E->>F: accepted editorial output or explicit no-editorial path
    F->>H: deterministic render
    F->>X: exact reader-visible semantic projection
    F->>M: final-view hash
    H->>M: HTML byte hash
    X->>M: eval-projection hash
    M->>A: verify entire chain, then gate exact F and H
    Note over M,A: Any missing/mismatched hash, coverage failure,<br/>unknown editorial state or broader eval projection fails closed.

3.1 ReportReleaseManifest minimum contract

3.2 Acceptance invariants

Acceptance must mechanically prove all of these:

1. every manifest node exists, schema-validates and matches its hash/signature;
2. the final view is the only source of the hard eval projection and that projection contains no non-visible terms;
3. the readiness gate consumes the same final view/HTML whose hash is recorded;
4. the editorial state is explicit and every rejected item has a visible quarantine disposition;
5. source coverage is complete for the declared scope; unknown/failed scopes cannot claim green;
6. the expectation set is persisted, versioned and hashed—not reconstructed from shell history;
7. the authoritative metric receipt is created from the same manifest chain inside the protected write scope; and
8. --skip-render is legal only as “verify an existing complete chain,” never “trust a week-keyed sibling.”

Raw HTML byte identity is used to establish artifact identity, not as the behavioral golden master. A harmless renderer change may change bytes while preserving canonical JSON and reader semantics; it must create a new manifest, not falsify behavioral equivalence.

4. Target ownership and dependency law — AGREED(R2)

WeeklySalesReport does not move wholesale into domain. It is split three ways:

• src/domain/: pure concepts/policies—branded IDs, CRM status, week windows, Money, Unit, EvidenceReceipt, coverage/lifecycle and person-node contracts. No I/O, environment, DB, LLM, report or application imports.
• src/application/: use cases and port interfaces—selection, evidence assembly, canonical WeeklyReportDocument, release manifest, acceptance and reconciliation. Imports domain; never concrete adapters or presentation internals.
• existing clients/db/storage/llm/ingest packages migrate incrementally as adapters. They may import domain and application-owned port types to implement them; application never imports adapters.
• src/presentation/: view DTOs and renderers. It consumes the canonical application document and domain value objects; it does not own identity, selection, persistence or acceptance policy.
• scripts/Worker entrypoints are composition roots only.

flowchart TB
    D[domain<br/>pure IDs, values, policies]
    A[application<br/>use cases + ports + canonical report document]
    AD[adapters<br/>clients / ingest / db / storage / llm]
    PR[presentation<br/>view DTOs + renderers]
    CR[composition roots<br/>scripts / Workers]

    D --> A
    D --> AD
    D --> PR
    AD -->|implements application ports| A
    A --> PR
    CR --> AD
    CR --> A
    CR --> PR

Mechanical dependency rules enter with the first vertical and use an explicit shrinking allowlist:

1. domain imports no internal package;
2. application imports domain/shared schemas only—never concrete clients/db/storage/LLM/presentation;
3. adapters never import presentation/scripts and implement application-owned ports;
4. presentation never imports concrete adapters or pipeline policy;
5. only composition roots may import both adapters and application/presentation;
6. no new pipeline/engine/db -> report/presentation edge; and
7. every temporary exception names owner, F-ID, replacement slice and expiry phase.

5. Verification constitution — AGREED(R2)

The harness has four non-substitutable tiers:

An LLM judge can never override schema, identity, source, quote, ownership, coverage, lifecycle, artifact-lineage or hard James gates. Known-wrong current behavior enters the baseline only as a named expected delta with owner and removal gate. It is not immortalized because it was current.

6. Phase plan 0–5

Gates below are exit criteria, not a final cleanup phase. A phase does not exit on “code merged”; it exits when its mechanical gates and historical state disposition are green. Focused Phase-1 safety tests do not wait for a perfect universal harness.

flowchart LR
    P0[Phase 0<br/>artifact truth + rulers]
    P1[Phase 1<br/>stop durable damage]
    P2[Phase 2<br/>typed authorities]
    P3[Phase 3<br/>one report core]
    P4[Phase 4<br/>LLM trust boundary]
    P5[Phase 5<br/>decompose + enforce]
    P0 --> P1 --> P2 --> P3 --> P4 --> P5
    P0 -. manifest seam starts artifact/run authority .-> P2
    P2 -. typed report document enables .-> P3
    P2 -. identity/source contracts enable .-> P4

Phase 0 — Containment, artifact truth and trustworthy rulers

Scope: F-001–F-016, F-032's check gate, and the harness/manifest seam needed by every later phase.

Work objective: make “the report,” “the evaluated content,” “the gate,” “the run” and “the expectation set” refer to immutable typed identities; characterize all current entrypoints before switching any.

Mechanical exit criteria:

1. versioned schemas reject malformed profile, weekly, view, editorial, eval, expectation and manifest artifacts;
2. a ReportReleaseManifest binds the complete chain in §3 and acceptance refuses every missing/mismatched node;
3. hard eval derives only from the final reader view and a negative fixture proves an internal-only term cannot pass;
4. gate and eval receipts name the exact final-view and HTML hashes;
5. fresh/offline/editorial/accept callers, on frozen inputs, either produce the same canonical document or represent typed unavailable(reason); parity fixtures cover all seven formerly dropped sections and james_mentions;
6. --skip-render, drift resume, sibling week slots, stale defaults and wrong-project env all fail their negative tests; exact checkpoint/config signatures are persisted;
7. expectation sets, telemetry and metrics are run-ID-addressed and immutable; no latest.json authority;
8. pnpm check includes schema/migration drift, architecture baseline, source-review/register coverage and the Phase-0 harness; and
9. a historical lineage inventory gives every accepted 14d/15a/15b/16a artifact one of verified, projection-weak, sibling-receipt, unknown, or superseded; no gap is guessed green.

Phase-0 non-goal: move all types or split god modules. Characterization precedes restructuring.

Phase 1 — Stop durable damage and false emptiness

Scope: F-017–F-046.

Work objective: source deletion/completeness, D1-compatible atomic state, client schemas, bounded sync/security, retention and repair. Highest-risk boundaries may land as independent verticals after the Phase-0 IDs/harness seam.

Mechanical exit criteria:

1. @removed and 410 fixtures traverse the full state machine: checkpoint, tombstone/recovery, raw-evidence suppression, dossier reevaluation, coverage receipt and safe cursor advance;
2. malformed status-200 Graph/OnePage payloads and per-contact/store failures produce typed red/partial state—never {}, [] or empty-body success;
3. every sync unit has run ID, idempotency key, retry count and checkpoint; page/retry/time/host budgets are tested;
4. fact, person-claim, identity and metric lifecycles are batch/CAS atomic under D1 constraints and database indexes enforce the one-current/non-empty successor invariants;
5. production repository integration proves D1 parameter bounds; helper-only tests do not count;
6. every write path obtains the fenced lease inside the adapter; crash/signal tests cannot bypass it by script import;
7. source evidence is content-versioned, citations are immutable, and citation-drift audit is deterministic;
8. retention/correction/deletion propagates across DB, object store, caches, reports and logs with an auditable receipt;
9. Graph read capability is host-pinned and mutation capability is mechanically absent from report/sync composition;
10. actual smoke/diag formatters pass value/policy redaction; shared output contains no names, emails, subjects or raw quotes; and
11. protected-copy census/repair reports exact duplicate-current, missing-successor, orphan, collision, stale-source, partial-metric and lifecycle counts; every row is repaired, quarantined or explicitly abstained.

Phase 2 — Introduce typed authorities one vertical at a time

Scope: F-047–F-065 plus artifact/run/receipt types begun in Phase 0 and person-node integration gates below.

Vertical order:

1. artifact/run and immutable EvidenceReceipt;
2. CRM status/activity outcome/tag/error authorities;
3. UTC vs business-week authority;
4. person-node publication/gate integration, including same-email collision policy;
5. Money/stage and Unit/product authority; and
6. typed movement/loss/fact-candidate transport replacing prose protocols.

Every vertical follows the same exit gate:

1. introduce the constructor/schema/value object and negative fixtures;
2. dual-run only its pure/deterministic calculation on frozen inputs—never duplicate live Graph/OnePage/LLM effects;
3. compare canonical JSON, fact multiset and reader-view projection; review every expected delta;
4. switch exactly one composition-root caller;
5. delete the old string authority, parser and its tests in the same increment;
6. extend dependency/forbidden-import lint before the next vertical; and
7. audit/recompute historical rows affected by the retired authority, with receipt-backed repair or abstention.

Phase exit: no current supported caller derives status, week, source, identity, money, unit, loss/movement, tag or error authority from display prose/prefix/regex when a typed field exists. Temporary compatibility reads have owner, F-ID and expiration; they are not write authority.

Phase 3 — Strangle report assembly/render forks

Scope: F-003, F-009, F-016, F-065, F-077 and the report-facing parts of F-001/F-002.

Work objective: one canonical assemble/enrich application service and one final-view pipeline. Fresh, offline, accept and editorial become thin composition roots; offline renders the same document or explicit unavailable state.

Mechanical exit criteria:

1. all entrypoints call the same application service and cannot reimplement enrichment/wiring;
2. one frozen fixture produces canonical JSON identity across entrypoints; intentional option deltas are typed fields;
3. deterministic render is pure: it never mutates inputs and artifact-set publication cannot tear;
4. final-view semantic projection equals DOM/readable content, including section presence and James terms;
5. editorial state is in the manifest and pre-editorial output cannot be accepted when editorial is requested;
6. old assemble/render paths, empty placeholders, stale defaults and compatibility fields are deleted in the caller switch or carry a named, expiring STATE.md exception; and
7. exact HTML hash proves delivered artifact identity; semantic tiers—not permanent HTML snapshots—prove behavior.

Phase 4 — Harden the LLM boundary

Scope: F-005/F-006 and F-066–F-074.

Work objective: one hostile-evidence framing contract; exact request envelope; typed atom/source/ownership/ durability verification; visible bounded retry/quarantine; cost accounting; subject-scoped agent tools.

Mechanical exit criteria:

1. every LLM response exactly matches requested typed ProjectId, PartyId, profile unit and allowed node catalogue;
2. every atom resolves an in-scope immutable receipt and verifies quote span, direction/outcome, author/ownership and allowed durability before scoring or persistence;
3. negation, reply-author, banner/entity, minimum-length and non-contiguous-splice fixtures have explicit policies;
4. fake models that obey hostile instructions at every prompt site are rejected/quarantined by app validators; prompt sentence containment is not accepted as evidence;
5. every invalid item is accepted, retried, quarantined or dead-lettered with visible counts; none silently vanishes;
6. per-run call/token/cost/concurrency budgets reserve and account usage; exhaustion is a typed terminal status;
7. agent tools receive a subject-scoped evidence capability, cannot search arbitrary addresses/mailboxes, and write a schema-valid minimum/redacted evidence receipt; and
8. recorded real-shape outputs replay deterministically; an LLM judge is advisory and cannot waive a hard control.

Phase 5 — Decompose god modules and lock the structure

Scope: F-075–F-078 and residual structural work from prior phases.

Work objective: split only along already-proven domain/application/adapter/presentation seams. This is last so a large file move cannot hide behavioral change behind an untrustworthy baseline.

Mechanical exit criteria:

1. dependency law in §4 is enforced in pnpm check; migration allowlist reaches zero or every remainder has Adam, owner, F-ID and expiry;
2. source files comply with the 500-LOC rule except declarative/generated/static-fixture exceptions listed in a reviewed allowlist with a shrink target;
3. live.ts, weekly-report.ts, repositories, view/renderer and giant tests are split by use case/invariant, not by arbitrary line ranges;
4. embedded untyped renderer JS/CSS and duplicated escapers/formatters become separately linted/tested presentation assets or deliberately bounded templates;
5. all superseded flags, scripts, fields, parsers and paths are deleted or have the sole documented fallback allowed by the supersession protocol; and
6. the four-tier harness, production repository/client boundary tests and historical repair receipts remain green after each deletion.

7. Person-node P6 integration gates — AGREED(R2), execution still on HARD HOLD

The active plan is tmp/codex-notes/2026-07-16e-person-node-plan.md. This charter does not redirect P0–P5 or lift its P6 generation hold (:39-50,151-179). It adds two already-agreed acceptance blockers while the compatibility authority is still removable:

1. Narrative envelope binding: before person refs, facts or prose can attach, generated project_id, subject party_id and profile-unit contract must exactly equal the request. Negative fixtures: cross-project response, cross-subject response and stale response for another party.
2. Same-project email collision: exact email is a strong candidate signal, not unconditional cardinality proof. A same-project uniqueness conflict must create a visible collision decision. Auto-merge is permitted only when the approved policy proves cardinality and no contradictory stable external binding. Negative fixtures: duplicate CRM records for one human/address and two genuine household contacts sharing one address.

P6 may not exit until all existing plan gates and these additional gates are true:

• idempotent protected-copy migration with quick_check=ok, exact before/after counts and complete-scope abstention;
• zero current accepted human-bearing writes without typed party node/subject ownership;
• no node-aware consumer treats compatibility names, resolved_party_id strings or RelatedIDs as authority;
• collision/unresolved review queues are visible and existing same-email/orphan state has a disposition;
• stable replay makes zero LLM calls and preserves typed endpoints/precision/coverage under label/merge changes;
• row-level 16a reconciliation explains every relationship/activity/watch/bullet/CRM-health delta with receipts and accepts zero unexplained regressions; and
• after Adam separately approves generation, fresh post-migration report, automated precision audit, strict James final-view eval, Lane B rerun and Adam read-through all pass under either the Phase-0 manifest or its explicitly approved interim equivalent.

The last clause prevents P6 from laundering the known acceptance defect while also avoiding an unapproved rewrite of the active lane.

8. Delivery strategy and branch discipline — AGREED(R2)

Use one integrated vertical slice at a time. Broad parallel branches over live.ts, weekly-report.ts, identity and acceptance are forbidden. Short-lived branches are merge hygiene, not safety.

For each slice:

1. freeze redacted inputs, fixed clock/IDs and recorded model outputs;
2. add the typed authority/new pure path behind one compatibility seam;
3. dual-run only pure deterministic work;
4. compare all applicable harness tiers and review named expected deltas;
5. switch exactly one composition-root caller;
6. delete the old path/authority/tests in the same increment;
7. add dependency/size/negative gates before the next slice; and
8. run the associated historical census/repair or record authoritative abstention.

Rollback is the prior commit plus additive-compatible data semantics—not an indefinitely live second production path. No phase waits for a months-long branch to merge before learning whether its core invariant is enforceable.

9. Containment and historical repair objective — AGREED(R2)

Forward-only fixes are incomplete. Existing facts, identity, evidence, metrics, caches, artifacts and logs may already embody the failure. Every repair must be idempotent, reversible where possible, run first on a protected copy, emit a receipt, preserve superseded provenance and abstain when authority is missing.

No “repair” may invent a deleted Graph event, person merge, citation referent, buyer fact or metric value from probability. Unknown becomes an explicit quarantine/abstention record.

10. Interim operating policy before Phase 0 — requires Adam ratification

Until Phase 0 exits:

Every release-blocking register row with phase ≥ 1 must name its interim containment in the register; an RB=Y row whose containment column is empty or none is a charter defect and blocks ratification.

1. do not use --skip-render for acceptance;
2. never call offline output a production preview;
3. run the readiness gate on the exact delivered editorial artifact set;
4. regenerate eval snapshots from the delivered JSON and record JSON/view/HTML/snapshot/code/fixture hashes;
5. manually compare hard James terms against the delivered view, not lineSummary alone;
6. treat post-editorial HTML as manually approved by Adam, not as inheriting automated green;
7. persist the full expectation flags/values and command beside the verdict;
8. ensure the authoritative metric receipt is explicitly identified as delivered-chain or sibling-render; do not blur them; and
9. do not run person-node P6 generation or any long content run without its existing explicit approval.

This policy contains risk; it does not make F-001/F-002 resolved.

11. Decisions required from Adam

1. Ratify the two-level canonical artifact. Approve canonical application JSON plus exact final delivered HTML under ReportReleaseManifest, including editorial as a declared stage. Both architects agree; product authority remains Adam's.
2. Choose 16a disposition. Either:
3. keep 16a accepted now with the exact caveat “manually provenance-chained and precision-reviewed; automated eval projection is broader than the delivered view; accept-command metric/sibling artifacts are outside the delivered chain,” then require automatic reacceptance at Phase-0 exit; or
4. suspend accepted status until manifest-based reacceptance.

Codex agrees with Claude's recommendation: keep with caveat now, mandatory reacceptance at Phase-0 exit.

1. Ratify the interim operating policy in §10. Without it, weekly cadence has no agreed containment before Phase 0.
2. Severity labels only if operationally necessary. F-047 remains Claude-held at P0 versus Codex P1 because Claude rejects the manual buyer checks as effective containment. F-063, F-073, F-075 and F-076 retain their previously recorded held labels. Their remediation/release gates do not depend on the label; Adam need decide only if governance reporting requires one canonical label.
3. P6 approval remains separate. This charter adds gates but does not approve the generation plan, migration, render, eval or supersession of 16a.

12. Definition of program completion

The remediation program is complete only when:

• every register row is closed, explicitly accepted as residual risk by Adam, or made unreachable with a mechanical proof;
• every release-blocking row has both forward and historical gates green;
• ReportReleaseManifest makes an acceptance/delivery identity mismatch unrepresentable;
• typed authorities own the listed concepts and the old string authorities have been deleted;
• D1-compatible lifecycle invariants and source completeness are proven at real adapter/repository boundaries;
• hostile LLM/external input cannot silently alter identity, scope, truth, durability or completeness;
• the architecture and LOC rules are enforced with no anonymous permanent exception; and
• living docs, runbooks and acceptance records describe the system that actually exists.

Current-State Architecture (AS-IS) — DRAFT (Round 2, Claude)

Status: DRAFT pending Round-1 rebuttals and the joint findings register. Defect annotations use stable slugs (#slug); the register (Round 3) maps slugs → F-IDs, after which this document is re-annotated. Evidence for every annotated defect lives in the two reviews and the joint register; this document locates them on the architecture, it does not re-argue them.

1. Container view (C4 level 2, AS-IS)

flowchart TB
    subgraph Sources["External sources (read-only)"]
        OP[OnePage CRM API]
        GR[Microsoft Graph API<br/>3 Pitau mailboxes]
    end

    subgraph Local["Local runtime (D1/R2 stand-ins)"]
        DB[(SQLite via libSQL<br/>.data/pitau-ingest.db)]
        OBJ[(Object store<br/>.data/objects)]
    end

    subgraph Ingest["Ingest (scripts/ingest.ts)"]
        DELTA[Graph delta sync<br/>#tombstones-dropped #no-410-recovery]
        COV[Coverage gate]
    end

    subgraph Pipeline["Pipeline (src/pipeline — live.ts 2,237 LOC #god-module)"]
        SEL[Buyer selection<br/>4-pass, order-coupled #prose-protocol]
        EVID[Evidence assembly<br/>positional graph-NNN prompt IDs]
        NARR[Narration per buyer<br/>LLM + stable-dossier cache]
        WATCH[Watch / movement / loss<br/>#status-two-semantics]
    end

    subgraph Engine["Engine (src/engine)"]
        EXTRACT[Extraction<br/>#msg-call-atoms-unverified]
        NARRV[Narrative validation<br/>#subject-unbound #dead-validators]
        DISP[Disposition v7<br/>rules 10-16 unenforced]
    end

    subgraph Persist["Persistence (src/db)"]
        LEDGER[(fact_ledger<br/>#ledger-nonatomic)]
        NODES[(person nodes/claims<br/>#email-collision-split)]
        METRICS[(weekly metric store)]
        EDGES[(relationship_edges)]
    end

    subgraph Report["Report (src/report — weekly-report.ts 3,169 LOC #god-module #model-in-presentation)"]
        ASSEMBLE[assembleWeeklySalesReport]
        VIEW[weekly-html-view]
        RENDER[render-weekly-html]
        EDIT[Editorial LLM + validator<br/>#editorial-silent-delete #allowlist-from-untrusted]
    end

    subgraph Eval["Backtest / acceptance (src/backtest, scripts)"]
        SNAP[system-week.json<br/>week-keyed, overwritten #eval-lineage]
        GATE[Readiness gate<br/>name-string identity #gate-name-matching]
        JEVAL[James hard eval<br/>scores lineSummary projection #eval-projection]
    end

    OP --> Pipeline
    GR --> DELTA --> DB
    DELTA --> OBJ
    COV --> Pipeline
    DB --> EVID
    OBJ --> EVID
    Pipeline --> Engine
    Engine --> Persist
    Pipeline --> Report
    Report --> Eval
    Report -. "runtime import cycle #layer-inversion" .-> Pipeline

Load-bearing observation: the canonical data model (BuyerProfileReport, WeeklySalesReport) lives inside Report, so every other container imports from the presentation package (#model-in-presentation, #layer-inversion). There is no domain layer; the two god modules are where every concept without an owner ends up.

2. Package dependency view (runtime vs type-only edges distinguished)

flowchart LR
    config --> pipeline
    schemas --> pipeline
    pipeline <-->|"runtime cycle:<br/>live.ts imports report schema,<br/>profile-model imports 9 pipeline schemas"| report
    engine -->|runtime| pipeline
    engine -.->|type-only| report
    db -->|runtime| pipeline
    report -->|runtime| runtime_pkg[runtime]
    backtest -->|runtime| report
    metrics --> report
    knowledge --> pipeline
    agentic --> pipeline

Per Codex's Round-earlier correction: type-only edges (dashed) are ownership problems, not runtime cycles; the solid pipeline ↔ report cycle is real at runtime (live.ts:20-28 ↔ profile-model.ts:1-27).

3. Sequence: weekly pipeline end-to-end (AS-IS)

sequenceDiagram
    autonumber
    participant A as Operator (Adam)
    participant I as ingest
    participant R as report.ts (selection+narration)
    participant W as weekly-report.ts (fresh render)
    participant O as rebuild-from-cache (offline render)
    participant E as weekly-editorial.ts
    participant G as weekly:gate
    participant AC as weekly:accept
    participant S as system-week.json (shared slot)

    A->>I: pnpm ingest (writer lock ✔)
    I->>I: delta sync — tombstones counted+dropped #tombstones-dropped
    A->>R: pnpm report (4-pass selection, LLM narration, cache)
    R-->>R: checkpoints carry no code signature #allow-drift-splice
    A->>W: fresh render
    W->>S: OVERWRITE system-week.json (every render) #eval-lineage
    W->>W: attaches 7 enrichments, mutates input profile #render-mutates-input
    A->>O: (iteration) offline render
    O->>O: bare assembler — census/channel-mix absent,<br/>discovery/coming-due/lead-history EMPTY #render-fork
    A->>E: editorial (reads weekly JSON, bare cast)
    E->>E: invalid items silently filtered #editorial-silent-delete
    E-->>A: NEW artifact set (post-editorial HTML)
    A->>G: manual gate practice: runs on the editorial set ✔<br/>(operator discipline, not enforced)
    A->>AC: accept (optionally --skip-render)
    AC->>AC: accept's INTERNAL gate+eval run on its own<br/>fresh PRE-editorial render #gate-pre-editorial
    AC->>S: reads BY WEEK KEY — may be a different revision #eval-lineage
    AC->>AC: James eval scores lineSummary concatenation,<br/>not the rendered view #eval-projection

4. Sequence: the false-acceptance path (AS-IS, the release blocker)

sequenceDiagram
    autonumber
    participant Op as Operator
    participant RevA as Revision A (HTML under acceptance)
    participant RevB as Revision B (latest render)
    participant Slot as system-week.json
    participant Gate as Readiness gate
    participant Eval as James hard eval

    Note over RevB,Slot: Any later render of the same week<br/>overwrites the shared slot
    RevB->>Slot: write (week-keyed, no fingerprint)
    Op->>Gate: accept --skip-render (HTML = Revision A)
    Gate->>RevA: assertions on A's pre-editorial HTML ✔
    Op->>Eval: hard eval
    Eval->>Slot: load by week key → gets B's projection
    Eval-->>Op: GREEN — recall proven on content A's reader never sees
    Note over Op: Acceptance certifies a document nobody delivered.<br/>#eval-lineage #eval-projection #gate-pre-editorial
    Note over Op: 16a-specific record (Round 2 §3): lane B manually regenerated<br/>the snapshot FROM 16a.json with SHAs recorded, so 16a's provenance<br/>is manually chained; the projection gap and the accept-command's<br/>sibling-render artifacts remain its real residual weaknesses.

5. Concept-ownership table (AS-IS)

6. LLM trust boundary (AS-IS)

flowchart LR
    EV[Hostile evidence<br/>email + CRM text] --> P1[Extraction prompt<br/>raw <source> framing #delimiter-injectable]
    EV --> P2[Narration prompt]
    EV --> P3[Editorial prompt]
    P1 --> V1[validate: discovery quotes ✔<br/>messages/calls NOT verified #msg-call-atoms-unverified]
    P2 --> V2[validate: quotes ✔ (min-len 1)<br/>subject binding ✘ #subject-unbound<br/>dates: dead validator]
    P3 --> V3[validate: allowlist from untrusted text<br/>failures silently filtered #editorial-silent-delete]
    V1 --> SCORE[Engagement scoring]
    V2 --> LEDGER2[(fact ledger)]
    V3 --> HTML[Delivered HTML]
    AG[Agentic session] -->|graph_search_messages:<br/>ANY address, all mailboxes #agentic-scope| EV
    AG -->|evidence log: bare cast, raw PII #agentic-pii| LEDGER2

No per-run cost ceiling exists on any path (#no-cost-ceiling). Injection defenses are asserted by prompt-string containment tests only (#injection-tests-tautological); the CLI backend carries a defense sentence the API backend lacks.

7. What is healthy (kept in future state)

• Metric store: typed registry, candidate/accepted/superseded lifecycle, partial unique indexes.
• Graph client immutable-ID discipline (tested, including nextLink).
• Quote-verification spine exists at 14 call sites (semantics need hardening, but the chokepoint is real and reusable).
• Deterministic weekly-fact channel with coverage validation (Approach 4) — the design pattern to generalize.
• Coverage gate before final reports; writer-lock + verified-backup machinery (2 days old, adoption gaps noted).
• Person-node identity spine (in flight) — the template for every other typed authority.

Future-State Architecture (TO-BE) — DRAFT (Round 2, Claude)

Status: DRAFT pending Round-1 rebuttals. Each element is annotated with the defect slugs it retires (register maps slugs → F-IDs in Round 3/4). Design incorporates Codex's corrections from the delta discussion: no wholesale DTO moves, typed authorities land one vertical at a time behind dual-run seams, dependency direction is lint-enforced from the first vertical.

1. Target layering (C4 level 2, TO-BE)

flowchart TB
    subgraph Domain["src/domain — pure types + policies (NO I/O, NO LLM)"]
        IDS[Branded IDs<br/>PartyId ContactId SourceRef RunId WeekKey]
        STATUS[StatusAuthority<br/>parse → typed stage+name, ONE membership semantics]
        WEEK[UtcWeekWindow / BusinessWeekWindow<br/>distinct types]
        MONEY[Money + Unit types<br/>single formatter each]
        RECEIPT[EvidenceReceipt<br/>minted from immutable upstream refs only]
        ARTIFACT[ArtifactLineage<br/>content-hash chain types]
        IDENTITY[Person-node contract<br/>(in flight — the template)]
    end

    subgraph App["src/application — use cases + PORT interfaces"]
        SELECT[Selection]
        EVID[Evidence assembly]
        BUNDLE[Canonical report document assembly<br/>ONE assemble+enrich core — versioned canonical JSON]
        MANIFEST[ReportReleaseManifest<br/>content-hash chain owner]
        ACCEPT[Acceptance<br/>verifies chain, gates the DELIVERED artifact]
        PORTS[(Port interfaces:<br/>CrmPort MailPort StorePort LlmPort)]
    end

    subgraph Adapters["adapters (clients/db/storage/llm/ingest, migrated incrementally)"]
        OPA[OnePage adapter<br/>response schemas, GET-only proven]
        GRA[Graph adapter<br/>tombstones + 410 recovery, host-pinned]
        DBA[DB adapter<br/>batch-atomic, D1-compatible]
        LLMA[LLM adapter<br/>cost ceilings, one framing]
    end

    subgraph Present["src/presentation — view DTOs + rendering"]
        VIEWS[View builders]
        HTML[Renderers]
    end

    Domain --> App
    Domain --> Adapters
    Domain --> Present
    Adapters -->|implement| PORTS
    App --> Present
    ROOTS[Composition roots<br/>scripts / Worker entrypoints] --> Adapters
    ROOTS --> App

Dependency rules (lint-enforced from the first vertical, per the Round-1 amended set): domain imports no internal package; application imports domain only (never concrete adapters, never presentation internals); adapters import domain + application port types to implement them, never presentation or scripts; presentation consumes the application's canonical report document and imports domain — never concrete adapters or pipeline policy; only composition roots may import both adapters and application/presentation; no new pipeline/engine/db → report/presentation edge; every temporary exception names owner, replacement F-ID, and expiry phase. Retires: #layer-inversion #model-in-presentation #god-module (structurally).

WeeklySalesReport splits three ways (AGREED R2): domain gains its concepts (status, money, unit, week, receipts, identity); the canonical report document (versioned, canonical JSON) lives at application level because acceptance/eval need it; presentation keeps only view DTOs.

2. Artifact lineage & acceptance (TO-BE)

sequenceDiagram
    autonumber
    participant R as ReportBundle core
    participant M as Run manifest (content hashes)
    participant E as Editorial stage (declared)
    participant H as Delivered HTML
    participant G as Acceptance gate
    participant J as James hard eval

    R->>M: profile#hash, bundle#hash, view#hash
    R->>E: bundle (typed enrichment coverage —<br/>"unavailable" is REPRESENTED, never empty-rendered) 
    E->>M: editorial#hash (fail-closed: rejected items → quarantine records)
    E->>H: delivered HTML
    H->>M: html#hash, evalsnapshot#hash
    G->>M: verify FULL chain — refuse on any mismatch
    G->>H: gate assertions on the DELIVERED artifact
    J->>H: recall/point terms scored against the RENDERED view projection
    Note over M: --skip-render legal only when every hash matches.<br/>Retires #eval-lineage #eval-projection #gate-pre-editorial<br/>#render-fork #render-mutates-input #artifact-lineage

One assemble+enrich core; fresh/offline/accept become thin CLIs over it. The offline path renders the same document or explicitly marks sections unavailable(reason) — never silently empty.

3. LLM trust boundary (TO-BE)

flowchart LR
    EV[Hostile evidence] --> FRAME[ONE evidence framing<br/>escaped delimiters, both backends]
    FRAME --> GEN[Generation<br/>per-run cost ceiling]
    GEN --> VAL{Validators — fail closed}
    VAL -->|identity: response subject/project MUST match request| OK1
    VAL -->|source: every atom's source_id exists in scope<br/>messages+calls included| OK2
    VAL -->|quote: length floor + negation guard +<br/>symmetric normalization| OK3
    VAL -->|coverage: week-fact dispositions complete| OK4
    OK1 & OK2 & OK3 & OK4 --> OUT[Accepted output]
    VAL -->|any failure| Q[(Quarantine records —<br/>visible in gate + telemetry)]
    JUDGE[LLM judge] -.->|advisory triage ONLY —<br/>cannot override any validator| OUT
    AGENT[Agentic tools] -->|scope bound to subject's<br/>evidence set only| EV

Retires: #msg-call-atoms-unverified #subject-unbound #editorial-silent-delete #allowlist-from-untrusted (allowlist derives from typed entities: node catalogue + typed metric values) #agentic-scope #agentic-pii (evidence log schema-validated, PII-redacted at write) #no-cost-ceiling #delimiter-injectable #injection-tests-tautological (fixtures drive a fake model that OBEYS injections; validators must quarantine).

4. Identity spine (TO-BE — the in-flight person-node work, extended)

flowchart LR
    M[Evidence mention] --> NODE{Node assignment at extraction}
    NODE -->|exact CRM identity| CRM[CRM-bound node<br/>onepage_contact_id]
    NODE -->|roster evidence bar| STAFF[Staff node<br/>sg-p id / payroll id]
    NODE -->|named, no binding| PROV[Provisional node<br/>naming receipts]
    NODE -->|role-only| ANON[Anonymous node]
    CRM & STAFF & PROV & ANON --> REFS[party_refs in ALL downstream surfaces<br/>narration segments, edges, activity, watch, gate]
    REFS --> MERGE[Merge lineage<br/>email = strongest signal<br/>SAME-project collisions raise candidates too]
    subgraph Absorbed["Absorbed from this session (cheap now)"]
        A1[#subject-unbound → narrative response binds to requested party_id]
        A2[#email-collision-split → same-project email conflict = review candidate, never silent]
        A3[#gate-name-matching → gate flags take contact IDs]
    end

5. Persistence integrity (TO-BE)

• All supersession writes are batch-atomic (D1-compatible: no interactive read-modify-write); partial unique current-row indexes on every lifecycle table including fact_ledger. Retires #ledger-nonatomic.
• source_evidence becomes revisioned (content-hash versions) so cited text is immutable; re-verification job flags citation drift. Retires the mutable-evidence hole.
• Tombstones: @removed → explicit tombstone records → evidence suppression + dossier re-evaluation trigger. 410 → checkpointed failure → date-bounded resync with immutable-ID dedupe. Retires #tombstones-dropped #no-410-recovery.
• Client responses schema-validated; malformed success payloads fail closed, never become [].
• Writer lease acquired inside the DB client for any non-file URL or write path — safety is opt-out-impossible, not opt-in-per-script.

6. Verification harness (TO-BE) — AGREED (Round 2), per Codex's Round-1 four-tier text

Known-wrong current behavior enters the baseline as reviewed expected-deltas, never silently immortalized.

7. Migration path (how AS-IS becomes TO-BE without a big bang)

One vertical at a time, each: introduce typed authority → dual-run old+new on frozen inputs → diff via the harness → switch the single caller → delete the old path in the same increment → extend dependency lint. Order (from the merged phase plan, agenda item 2): artifact/run lineage → integrity stoppage (ledger, tombstones, 410, payload validation) → status + week → receipt/source → identity absorption → money/unit → render-core strangling → LLM boundary hardening → god-module decomposition last, when it is mostly mechanical.

Joint Architecture Working Session — Discussion Log

Date: 2026-07-16 Status: Round 5 merge record; bilateral architecture work complete; Round 6 unused Scope: audit trail for rounds 0–5 and the five joint deliverables under tmp/review/joint/ Execution record: documentation-only session; no source change, migration, generation, render, editorial, eval, acceptance, or live-source run was performed

1. Final deliverables

flowchart LR
    R0[Round 0<br/>Claude critique] --> R1[Round 1<br/>Codex rebuttal + positions]
    R1 --> R2[Round 2<br/>Claude concessions + revisions]
    R2 --> R3[Round 3<br/>Register + charter drafts]
    R3 --> R4[Round 4<br/>Claude adversarial acceptance]
    R4 --> R5[Round 5<br/>Merge + audit log]
    R5 -. no bilateral issue requires it .-> R6[Round 6<br/>UNUSED]

2. Round index

Round 0 — Claude critique of Codex review

Claude verified and conceded three high-impact misses from its own review: unverified LLM message/call atoms, unbound narrative subject, and same-project email collision splitting. It charged Codex with four material coverage gaps: acceptance/eval lineage, editorial trust boundary, orchestration, and structural/ranking analysis. It also challenged Codex's no-P0/not-releasable wording, transient red snapshot, duplicate register items, and review method.

Final result: the three unique Codex findings are agreed F-066, F-067 and F-059; all four coverage gaps are accepted with the Round-2 method refinement; the calibration issue is resolved by the two-axis rule; transient lint state was removed as a repository finding; tombstone/lifecycle remain separate F-IDs under one parent; the duplicate D1 guard evidence is merged.

Round 1 — Codex rebuttal and opening architecture positions

Codex conceded the lineage-flow miss, editorial under-read/“274 read” overclaim, gross orchestration gap, weak architecture triage, context-free transient-red framing, duplicate D1 guard row, and coverage-language weakness. It held against Claude's absolute “file-unit review cannot see flows” and “zero scripts findings” claims, showing actual flow traces and one scripts finding. It resolved the no-P0/not-releasable tension by separating incident severity from release policy.

Codex proposed: the register schema; phases 0–5; four-tier harness; domain/application-port/adapter/presentation ownership; P6 envelope and email-collision gates; integrated vertical delivery; the two-level canonical artifact; and historical repair as a first-class objective.

Final result: the absolute method claims were narrowed; every architecture proposal was accepted in Round 2 with the exact amendments preserved in the final charter.

Round 2 — Claude rebuttals, concessions, and diagram revisions

Claude conceded four critique/process defects: Round-0 non-self-containment, the “zero orchestration findings” absolute, method monocausality, and premature agreement labels. It accepted the register schema, phase plan, harness, ownership model, P6 gates, delivery strategy, canonical artifact, repair objective, tombstone/lifecycle split and D1 merge.

Claude amended severity reachability to include recorded operating practice and corrected 16a's provenance record: lane B regenerated the eval snapshot from delivered 16a JSON and recorded hashes, while the view-projection gap and accept-command sibling artifacts remained.

Final result: Codex accepted the reachability amendment in Round 3. F-001 and F-002 split reader-projection failure from artifact-lineage failure; both are P1 and release-blocking because practice proves reachability while manual precision/SHA work is artifact-specific containment. The 16a caveat is carried to Adam.

Round 3 — Codex register and charter drafts

Codex produced the 78-row union register and remediation charter. The register separates impact, confidence, reachability, containment, severity and release block; maps all source-review headings and architecture slugs; and assigns every F-ID interim, forward, historical and deterministic verification work. The charter records the accepted severity rule, two-level ReportReleaseManifest, phases 0–5 with mechanical exits, four-tier harness, dependency law, P6 gates, integrated delivery and historical repair.

Final result: accepted in Round 4 subject to two small edits. No architectural redesign was requested.

Round 4 — Claude attack on register and charter

Claude spot-checked structure, 33 slugs, union coverage, sampled severity fields, baseline discipline and the full charter. It found two defects only:

1. F-057 omitted the agreed normal-path stable-cache positional-ID payload evidence and the corresponding promotion condition.
2. Charter §10 did not mechanically require interim containment on later-phase release blockers.

Claude re-derived F-003, F-005, F-011 and F-058 as P1 + release-blocking under the joint rule; F-057 as P2 with the expanded promote condition; these became A(R4). F-047 remains disputed: Claude says three weeks of manual-review misses make manual checks ineffective containment and therefore holds P0; Codex holds P1 because the failure remains repairable and the actual variant/release path has not been demonstrated. Phase 2 and release policy are identical under either label.

Final result: both Round-4 defects accepted; no Round 6 needed.

Round 5 — Codex merge pass

Applied exactly the commissioned substantive changes:

• F-057 now cites src/pipeline/live.ts:2243-2270,2309-2334, the normal-path cache payload, normal ledger remap and focused persistence test; promotion now includes cache positional IDs causing stale-hit/replay divergence.
• Charter §10 now makes missing interim containment on any phase ≥1 RB=Y row a ratification-blocking charter defect.
• F-003, F-005, F-011, F-057 and F-058 changed from held to A(R4).
• F-047 remains held exactly as commissioned.

Round-5 note on changes beyond the two substantive edits: three derivative consistency edits were necessary and are flagged here. The register's CH definition was made holder-neutral, its open-items paragraph was updated to remove resolved holds, and charter §11 decision 4 was updated to remove resolved rows. No severity, phase, release block, remediation direction, architecture or Adam decision changed beyond the Round-4 commission. F-063, F-073, F-075 and F-076 retain their previously recorded held labels because Round 4 did not name them among the five status flips.

Round 6 — unused

Neither architect contests Round-4 §§1–2. Round 6 is not invoked. All non-product bilateral items are settled or explicitly preserved as held calibration with identical operational treatment.

3. Item-by-item final resolution ledger

No bilateral architecture item is ESCALATE TO ADAM because the architects could not reason further. The Adam list below contains product authority and governance choices that only Adam can make, plus an optional canonical severity label whose operational treatment is already agreed.

4. Concession accounting

Counts include explicit factual/method/calibration corrections, not ordinary acceptance of a good proposal and not Round-4 label convergence that Claude explicitly said was the joint rule re-deriving its own result.

Not counted as concessions:

• F-003/F-005/F-011/F-058 label convergence in R4: Claude expressly classified it as the agreed rule producing the same result, not capitulation.
• Architecture proposals accepted in R2: convergence, not correction of an established factual claim.
• F-001/F-002 P1 + RB=Y: the split incorporates evidence from both sides; neither side's initial one-dimensional label survived unchanged.

The session therefore satisfies Adam's requirement for concessions in both directions without manufacturing false symmetry or using concession count as severity evidence.

5. Decisions required from Adam — carried forward

1. Canonical artifact ratification. Approve the two-level authority: versioned application canonical JSON and exact final delivered HTML bytes under immutable ReportReleaseManifest, with editorial as a declared stage.
2. 16a status. Choose keep-with-caveat now plus mandatory Phase-0 reacceptance, or suspend accepted status until manifest reacceptance. Joint recommendation: keep with the exact caveat now; mandatory reacceptance at Phase-0 exit.
3. Interim policy. Ratify charter §10: no skip-render acceptance; offline not production preview; gate delivered set; eval from delivered JSON with hashes; hard terms checked in delivered view; post-editorial manual approval; persisted expectations; explicit sibling metric receipt; existing P6 hard hold.
4. Canonical severity only if governance needs it. F-047 remains Claude P0 / Codex P1. F-063, F-073, F-075 and F-076 retain their recorded held labels. All phases, release blocks and remediation are already fixed; Adam need decide labels only if one canonical governance report requires them.

Separate standing constraint, not counted as a fifth architecture decision: person-node P6 remains on HARD HOLD. This session does not approve its generation plan, migration, render, eval or supersession of 16a.

6. Stop condition

The five requested documents exist. Round 4 accepted the architecture, register and charter subject to edits now applied. No architect contests Round-4 §§1–2. Round 6 is unnecessary. Per Adam's hard constraints, this working session stops here without implementation.