# 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.