Close INFD-IN-0001; design the independent evidence path; track both blockers

Housekeeping the ruling left behind, plus the one piece of blocked work that was
substantially ours to move.

INFD-IN-0001 closed with its resolution recorded, matching approval-engine's
IN-0002 form. It was still open after GH-DEC-2026-012 answered it.

INFD-IN-0003 and docs/evidence-path-design.md take up O-02, which was sitting in
the blueprint as "mechanism unchosen". Read independence and the local
transactional outbox are settled and not in question. The real question is what
travels, and it is sharper for us than for approval-engine because a
presentation record carries the brief and packet material actually shown to a
human. Three candidates with costs; proposal is commitment-only for Stage 1 —
hashes, principal, timestamps, acks, co-referenced approval id — which
discharges limit 3 and removes our ability to alter the record, while leaving us
able to erase the content. That residual is declared alongside the existing
compromised-surface one rather than papered over.

Deliberately not proposing the full binding document unilaterally: it would put
commercial and personal material into the audit fabric under retention and
export entitlements designed for audit events. That is a meaningful change in
what audit-core holds and is its owner's to accept, not ours to assume. The
third option, a separate evidence store, is refused here because that store has
no owner and inventing one routes around the §16 decision against stronger
archival custody.

Cadence declared and its form argued rather than copied: approval-engine's
heartbeat answer suits genuinely low-volume classes, but ours are mixed —
presentations are one per render, while dispositions and stance applications are
low-volume and are the security-relevant ones. Reconciliation per class as
primary, heartbeat for the low-volume classes. Depends on AUDIT-WP-0009 T04/T06;
declared, not claimed operating.

INFD-IN-0002 files the tenant blocker as a tracked record rather than leaving it
in message threads and a blueprint footnote. T07 and T08 now name their blocking
intakes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568

docs/evidence-path-design.md

@@ -0,0 +1,184 @@
+# The independent evidence path — design and decision request
+
+**From:** informed-decision
+**Raised:** 2026-09-09
+**Intake:** `INFD-IN-0003`
+**Blocks:** `INFD-WP-0001-T08`
+**Governing:** `GH-DEC-2026-012` limit **L3-independent-evidence-path**
+**Addressed to:** `audit-core` (registration and payload), `gate-house` (the
+content question, if it is doctrine)
+
+---
+
+## 1. The obligation
+
+`GH-DEC-2026-012` permitted this repository to emit a presentation claim under
+three limits. The third:
+
+> The evidence copy reaches `audit-core` **independently** of you. Claim
+> endpoint and evidence path are different things and neither substitutes for
+> the other. […] audit evidence is protected from the actor being audited, and
+> here the actor and the source are the same component. The copy that is
+> evidence must not be reachable only through the party it is evidence about.
+
+Gate House named this the limit that matters most in our case, and we agree: we
+render the view, we compute the hash over it, and we are the party an auditor is
+checking. A design where the only route to the evidence runs through us is not
+evidence.
+
+`docs/specs/ArchitectureBlueprint.md` `O-02` records the mechanism as unchosen
+and states T08 must not ship without it, because "we will add the independent
+path later" is how limit 3 becomes limit-3-in-principle.
+
+## 2. What is settled and not being asked
+
+**Read independence is the property.** A reader obtains the evidence from
+`audit-core` without asking us and without our cooperation. Our claim endpoint
+serves presentation claims to consumers; it is a different surface with a
+different purpose and does not discharge this obligation.
+
+**The write path is a local transactional outbox.** Adopted from
+`approval-engine`'s reasoning rather than rediscovered: the queue lives in our
+own store, written in the **same transaction** as the state change it evidences.
+Emit-after-commit is a defect. The queue is local so an `audit-core` outage
+cannot block a binding act, for the same reason it must not block a revocation
+upstream.
+
+**Atomicity covers accident, not compromise.** It does not close the residual in
+`layer.yaml` and will not be described as doing so.
+
+**Cadence is owed.** Our `layer.yaml` declares presentation evidence
+**load-bearing**, so §9.6 requires a declared cadence. See §5.
+
+## 3. The question: what travels
+
+A presentation record is not like an approval transition. It contains, or points
+at, the **brief and packet material actually shown to a human** — which is
+frequently commercially or personally sensitive. So "emit the evidence" is
+ambiguous in a way it was not for `approval-engine`, and the ambiguity has to be
+resolved before we build, not after we have shipped a payload shape.
+
+Three candidates.
+
+### (a) Commitment only — hash and metadata
+
+Emit `memo_id`, `memo_version`, `presentation_id`, `principal`, `locale`,
+`ui_release`, `rendered_at`, `acked_highlight_ids`, `view_hash`,
+`awareness_hash`, the co-referenced approval identifier, the disposition verb,
+and the stance application. **Not** the brief, not the packet, not the highlight
+text.
+
+- **Proves independently:** that this principal was shown a view whose canonical
+  form hashes to H, at time T, and bound act A against approval X.
+- **Cost:** the *content* lives only here. An auditor can verify that content we
+  later produce matches H, and can detect alteration — but if we destroy it,
+  nobody can ever see what was shown. Audit-core proves the commitment, not the
+  material.
+- **Also:** this is strictly stronger than storing nothing, because it removes
+  our ability to alter the record after the fact. It does not remove our ability
+  to erase it.
+
+### (b) Full binding document
+
+Emit the canonical binding document itself, from which `view_hash` is
+recomputable.
+
+- **Proves independently:** everything (a) does, plus what was actually shown,
+  surviving our compromise or our deletion.
+- **Cost:** `audit-core` now holds business-sensitive and possibly personal
+  content, under retention profiles and export entitlements designed for audit
+  events rather than for the substance of commercial decisions. Its
+  secret-finding and redaction surfaces would be operating on material where a
+  redaction is not a defect-signal but routine. That is a meaningful change in
+  what `audit-core` is holding, and it is theirs to accept or refuse — not ours
+  to assume.
+- **Also:** an L4 instrument under (b) puts contract text in the audit fabric.
+
+### (c) Split — commitment to `audit-core`, content to a separate evidence store
+
+(a)'s payload to `audit-core`, plus the full bundle to a store that is neither
+`audit-core` nor us.
+
+- **Proves independently:** as (b).
+- **Cost:** a store with no owner. There is no such component today, and
+  inventing one to satisfy a limit is how a surface acquires an operational axis
+  it was never given. §16 also decided against stronger archival custody for
+  approval evidence, and we should not route around that decision by building a
+  parallel archive under another name.
+
+## 4. What we propose
+
+**(a) for Stage 1, with the gap stated rather than papered over.**
+
+Reasoning:
+
+1. It discharges limit 3 as written. The copy that is evidence — the commitment
+   that a presentation with hash H happened to principal P at time T — is
+   reachable from `audit-core` without us.
+2. It does not silently expand what `audit-core` holds. Expanding that is a
+   decision for its owner, and (b) presented as a fait accompli would be exactly
+   the drift we asked gate-house to prevent in a different context.
+3. It is honest about what it does not close: **we can still erase the
+   content.** That residual is adjacent to the one `layer.yaml` already declares
+   (a compromised surface presents X and attests Y) and belongs in the same
+   place — declared, tracked, not claimed as closed.
+4. (b) remains available and is a payload change, not a redesign, if the estate
+   later decides a commitment is insufficient.
+
+**We are not asking to defer (b) indefinitely.** We are asking whether the
+content question is `audit-core`'s to answer as its custodian, or `gate-house`'s
+as doctrine. If it is doctrine and the ruling is (b), we will implement (b).
+
+## 5. Cadence
+
+Presentation evidence is declared load-bearing, so §9.6 requires a cadence and
+rate monitoring is not automatically the right form.
+
+Note a difference from `approval-engine`: their classes are genuinely low-volume
+(a handful of revocations a month), which is why heartbeat is their answer.
+Ours are mixed:
+
+- **Presentations** are relatively high-volume — one per render.
+- **Dispositions and stance applications** are low-volume and are the
+  security-relevant ones.
+
+So we propose **reconciliation as the primary form**, per class: our own count
+of presentations, dispositions and stance applications compared against
+`audit-core`'s event count per class, with divergence a finding. Plus a
+**heartbeat for the low-volume classes**, because a quiet month of dispositions
+is indistinguishable from suppression by rate alone — the same argument
+`approval-engine` makes.
+
+This depends on `AUDIT-WP-0009` T04/T06, which we understand are open. We are
+declaring the cadence now and will not describe it as operating until those
+land.
+
+## 6. What we need
+
+| From | Decision |
+| --- | --- |
+| `audit-core` | Sender registration for `informed-decision`, and whether payload (a) or (b) is acceptable to hold |
+| `audit-core` | Whether reconciliation-plus-heartbeat is the right cadence form for a mixed-volume source |
+| `gate-house` | Only if the content question is doctrine rather than custody |
+
+Proposed registration, following `approval-engine`'s form:
+
+| Field | Value |
+| --- | --- |
+| Sender and permitted source | `informed-decision` (exact) |
+| Tenants | `["tenant:platform"]` — but see the open tenant question, `INFD-IN-0002` |
+| Write / read | `true` / `false` |
+| Evidence kind | `load-bearing` |
+| Cadence form | reconciliation, plus heartbeat for low-volume classes |
+| Secret policy | `redact` |
+
+`redact` chosen for the same reason `approval-engine` chose it: a receiver
+should retain a legitimate record with an accidentally secret-shaped field
+removed rather than reject the event and leave delivery pending. Under payload
+(a) the exposure is small by construction; under (b) `redact` would be doing
+substantially more work, which is itself an argument for (a).
+
+**Note the coupling:** the tenant on our registration is the same unresolved
+question as `INFD-IN-0002`. If a human token cannot carry `tenant:platform`, our
+audit registration tenant and our approval tenant should be settled together
+rather than separately.

docs/specs/ArchitectureBlueprint.md

@@ -131,10 +131,19 @@ Consequences, binding on implementation:
 4. **Atomicity covers accident, not compromise.** It does not close the residual
    in `layer.yaml`, and must never be described as doing so.
 
-Open for implementation: whether the independent path is `audit-core` pull,
-a separately-credentialed push, or a third party drain. **T08 must not ship
-without one chosen**, because "we will add the independent path later" is how
-limit 3 quietly becomes limit 3-in-principle.
+**Cadence is owed**, because `layer.yaml` declares presentation evidence
+load-bearing (§9.6). The form differs from `approval-engine`'s: their classes are
+genuinely low-volume, so a heartbeat is the answer. Ours are mixed —
+presentations are high-volume (one per render), while dispositions and stance
+applications are low-volume and are the security-relevant ones. Proposed:
+reconciliation per class as the primary form, plus a heartbeat for the
+low-volume classes, since a quiet month of dispositions is indistinguishable
+from suppression by rate alone. Depends on `AUDIT-WP-0009` T04/T06; declared,
+not claimed operating.
+
+What travels is the open question — see `docs/evidence-path-design.md` and O-02.
+**T08 must not ship without it chosen**, because "we will add the independent
+path later" is how limit 3 quietly becomes limit 3-in-principle.
 
 ---
 
@@ -236,8 +245,15 @@ condition that it holds *only* because registrations are static and
 deployment-owned should be written into the contract, not left as reasoning in a
 message.
 
-**O-02 — The independent evidence path.** Its mechanism is unchosen. Must be
-resolved before T08 ships.
+**O-02 — The independent evidence path.** Design and decision request written:
+`docs/evidence-path-design.md`, filed as `INFD-IN-0003`. Read independence and
+the local transactional outbox are settled; the open question is **what
+travels**, because a presentation record carries the brief and packet material
+actually shown to a human. Proposal is commitment-only (hashes, principal,
+timestamps, acks, co-referenced approval id) for Stage 1, with the erasure
+residual declared rather than papered over. Awaiting `audit-core` on the payload
+and the sender registration, and `gate-house` only if the content question is
+doctrine. Must be resolved before T08 ships.
 
 **O-03 — Requester identity for an engine-originated memo.** `approval-engine`
 does not model a requester. Likely the approval's `principal`; needs confirming