informed-decision/docs/evidence-path-design.md

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) Ruled: GH-DEC-2026-014 split it — the payload is audit-core's custody question; what may be claimed from a record of this shape is doctrine. Commitment-only is granted for Stage 1, with the §4 condition below, which this repository did not propose.

---

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

Refusal endorsed by GH-DEC-2026-014, with an addition worth carrying: an evidence store owned by the party whose conduct it evidences is not an evidence store, whatever its integrity properties. The ownership objection is prior to the custody one.

(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. Our first wording — "we can still erase the content" — understated it, and GH-DEC-2026-014 corrected us: commitment-only moves integrity out of our control and leaves availability entirely inside it. The party that can withhold the content is the party the evidence is about. That is the condition limit 3 exists to prevent, reduced and not removed.
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).

4a. The existence assertion — required, and not ours

GH-DEC-2026-014 granted commitment-only on a condition we did not propose, and it is the condition that makes the grant safe.

Non-production must be detectable as a finding, not present as an absence.

If the independent path holds only a commitment, a reviewer who asks for content and gets nothing cannot distinguish erased, withheld, lost, and never held. The absence reads as an unremarkable blank.

So the emitted record MUST carry, alongside the commitment:

Field	Meaning
content_exists	An assertion that committed content exists
custody	Where custody of that content sits

such that failure to produce at retrieval is a conformance failure attributable to the custodian — here, this repository.

A commitment with no assertion that something is being committed to is indistinguishable from a commitment to nothing.

Not a reversal candidate. If it proves expensive, the answer is a cheaper mechanism for the same property, never the property's removal.

Two limits travel with the grant and belong in audit-core's design too:

• It satisfies non-alteration. It does not satisfy reconstructability, and must not be described as doing so in any document or conformance claim on either side.
• The residual is not closed and this repository is not credited with closing it. The existence assertion narrows the erasure gap by making non-production attributable; it does not produce the missing thing.

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.