informed-decision/docs/specs/EvidenceModel.md

Evidence Model

Repo: informed-decision Workplan task: INFD-WP-0001-T06 Status: draft, pending review Companions: ProductRequirementsDocument.md, UseCaseCatalog.md, ArchitectureBlueprint.md (gated on INFD-WP-0001-T02) Normative algorithm: history/20260909-initial-exploration/canonicalize.md Governed implementation: informed_decision/canonicalize.py Tests: tests/test_canonicalize.py

---

1. What this model claims

This person, in this role, was shown this view, and bound this act.

Not "the file was signed". The difference is the whole product. A signature over a document proves a key was used on some bytes; it does not establish what the signer was looking at when they decided, which is the question an auditor actually asks and the question no e-signature product answers.

The mechanism is dynamic linking: the human-readable content actually presented is canonicalized and its digest is bound into the act.

2. What this model does not claim

Stated first, because an evidence model that oversells is worse than none.

E-01 — It does not prove the person understood. It proves what was presented and what was explicitly acknowledged. Comprehension is not observable and this model does not pretend to observe it.

E-02 — It does not prove the person read anything. Deliberately. Evidence of informedness is the hash of the presented view plus explicit acknowledgment — never dwell time, scroll depth, or attention telemetry. That choice trades a weaker claim for the absence of surveillance, and the trade is intentional (INTENT.md principle 12, PR-70/PR-71).

E-03 — It does not survive a compromised surface. view_hash is computed by the same component that renders. A compromised surface can present X and attest Y. This is structurally the same residual approval-engine names for adversarial omission at a compromised source, and it is not closed here, not closable at this layer, and never to be described as closed.

E-04 — A hash chain proves records were not altered or truncated after arrival. It cannot prove a record was never sent. Carried over from approval-engine's reasoning rather than rediscovered: a suppressed event leaves the chain perfectly intact and verification reports intact. Completeness is a separate obligation met by cadence, not by chaining.

E-05 — Stage 1 binding is organizational only. No AES, no QES. The object carries binding_level so higher levels are expressible without a schema change; nothing above organizational is implemented or claimed.

E-06 — A Stage 1 escalation is an assertion, not a verified claim. Without the mandate graph, guard G_ESC cannot be fully evaluated. The bundle records what the approver asserted and marks it unverified.

3. The two hashes

	view_hash	awareness_hash
Over	the binding document	the awareness document
Signed	yes, from organizational level up	no
Purpose	what the person committed to	what they were oriented with
In AES/QES signed attributes	yes	no, unless promotion ran

Binding allow-list: memo_id, memo_version, question, requested_act, binding_level, brief, locale, ui_release, normalized packet, normalized highlights, binding, and optionally awareness_promoted.

Awareness allow-list: proposed hat and its source, available hats and scopes, last session, situation note.

Profile: JCS-inspired restricted JSON — UTF-8, keys sorted by code unit, no insignificant whitespace, integers only, unknown keys stripped, nulls dropped.

canonical = dumps(document)
hash      = SHA-256(UTF-8(canonical))

Why the split exists

The login case forced it and it now applies everywhere. Defaulting a role to last-used is required for situational awareness — an operator who cannot see which hat they are about to wear is less safe, not more — and is forbidden from silently entering the signed payload. A person must not be bound to orientation material they did not commit to.

Promotion is the only bridge: moving a field from awareness into binding creates a new memo version, invalidates outstanding presentations, and copies the named fields into awareness_promoted where view_hash covers them (guard G_PROMOTE).

4. The four isolation properties

These are the model. Each is a test in tests/test_canonicalize.py and each must stay green; a failure means view_hash no longer means what §1 claims.

#	Property	Protects	Test
1	Shuffling object keys does not change either hash	Any verifier, in any language, agrees with us	test_key_order_does_not_change_*
2	Editing an awareness field does not change view_hash	The person is bound only to what they committed to	test_editing_awareness_does_not_change_view_hash
3	Changing binding.target does change view_hash	Positive control — without it, 2 could pass vacuously	test_changing_binding_target_changes_view_hash
4	Selecting a hat after login does not rewrite view_hash	Post-bind session state is a different object	test_post_bind_hat_selection_does_not_change_view_hash

Property 3 is not decorative. Properties 1, 2 and 4 are all negative — they assert that things do not change the hash. A canonicalizer that returned a constant would pass all three. Property 3, plus the per-field variants over question, requested_act, binding_level and packet, is what makes the suite meaningful.

Published vectors reproduce byte for byte and are asserted in CI:

login       view_hash       492d9d31…1b06b8
login       awareness_hash  2be77429…4fe05d1
ADR-0042    view_hash       1c89ec07…e91f202

Provenance is tested. history/20260909-initial-exploration/ is never edited. test_governed_vectors_match_the_preserved_history_copy asserts the governed fixtures have not drifted from the founding copies, so a silent edit to a vector to make a failing test pass is itself a test failure.

5. The presentation record

Every render creates one. It carries:

• memo_id, memo_version
• principal — who it was shown to
• locale, ui_release — both inside view_hash
• rendered_at
• acked_highlight_ids
• view_hash, awareness_hash
• phase — pre_bind | bind | post_bind

A disposition references exactly one presentation, of the same memo version (guard G_PRES). A presentation taken at version n cannot bind after the memo advances to n+1 — no silent upgrade (NC-07).

Because locale is inside view_hash, the same memo read in German and in English produces two different presentations of one binding. Intended, and documented rather than smoothed over (PR-61).

6. The evidence bundle

An export, not a screenshot (INTENT.md principle 7). Contains the memo and all its versions, every presentation with both hashes, every disposition, the thread, the route as executed, and the append-only hash chain.

Requirements:

• Verifies offline. No network, no access to this service. A verifier recomputes view_hash from the bundle's own binding document and compares.
• Detects mutation. Altering any covered field breaks verification.
• States its own bound. The residuals in §2 travel with the bundle as metadata. An auditor must not have to read this document to learn that E-03 exists.
• Marks unverified assertions as such — see E-06.

7. Relationship to audit-core

audit-core holds the archive; this repository holds the operative record and produces the export. This surface emits its transitions there and does not duplicate the archive's role.

Its guarantee is bounded and the bound is inherited, not re-litigated: audit-core is not WORM or object-locked, its tamper evidence is conditional on live preconditions, and stronger custody was decided against in statute §16. This repository must not plan around a stronger archive, and must not imply the bundle is more durable than the archive it reconciles against.

8. Open — view_hash versus the approval binding digest

Unresolved. Filed as INFD-IN-0001 R3 with gate-house.

approval-engine's claim carries "a digest over the same canonical binding the decision point already computes." view_hash is also a digest over "the binding". They cover different material: the approval digest exists with no human in the loop; view_hash additionally covers brief, packet, highlights, locale and UI release.

Ruled GH-DEC-2026-012 R3, and now re-opened as INFD-IN-0004. The ruling: distinct attestations with an authority rule — the binding digest is authoritative for what the request is, view_hash for what was shown, neither substitutable, and a disagreement between them is a finding against the presenting surface rather than a fact about the request. Linkage by co-reference, not nesting.

approval-engine has since published what its digests actually cover (docs/approval-claim.md) and recommends the opposite linkage — that our binding document carry their binding.digest as a field, which is the option GH-DEC-2026-012 refused. Their reason is the stronger version of the risk we raised: our binding slice canonicalizes principal and target, two of their five digest fields, so co-reference by identifier alone leaves two independent canonicalizations of one act rather than removing the duplication.

Raised as a finding rather than resolved bilaterally (docs/finding-r3-linkage-conflict.md). Re-ruled by GH-DEC-2026-015: gate-house reversed itself — nesting is permitted for this pair, so view_hash may carry binding.digest and our binding slice stops independently canonicalizing act material.

The decisive ground was not the cycle argument we led with. It was that our binding slice canonicalizes principal and target, two of the five fields in their digest, so co-reference by identifier left us performing a partial recomputation of one act in a second vocabulary — closer to the translation R3 forbade than nesting is. Nesting removes the duplication; co-reference manages it.

Activated 2026-09-10. approval-engine met the condition and we verified it here rather than taking it on report: their docs/approval-claim.md carries "Presentation exclusion — GH-DEC-2026-015 §4" in normative language, and test_presentation_changes_cannot_change_the_approved_act pins the input set from both sides — widening (presentation material leaves the digest unchanged) and narrowing (each of the five act fields changes it). The narrowing half is what makes it real: without it, a digest over four fields, or over a constant, would pass the widening half perfectly. Run and confirmed passing.

So view_hash now carries binding.digest, and the act-scope is no longer independently canonicalized here. The act has exactly one canonicalization, computed by the layer that owns it, and view_hash means this person was shown this presentation of this act.

The cycle condition did not go away — its protection moved. It is no longer enforced by refusing nesting but by approval-engine's normative exclusion: containment stays one-directional because binding.digest must never cover presentation material. If that exclusion is relaxed, this linkage must be revisited before the widening ships. layer.yaml carries it as cycle_condition so a future widening meets a rule rather than silence.

One thing we did not assume. approval-engine's principal is the party on whose behalf the approval was issued; ours is the person being bound — the approver. Different roles. Dropping ours on the strength of "the digest covers principal" would remove who was shown this from view_hash and gut the promise. We kept it, declared the overlap open in layer.yaml, and raised it with approval-engine. If the two are the same field, ours drops too.

Our ordering-dependency objection to option (c) was withdrawn as mistaken and recorded as withdrawn: binding.digest is over act material, determined before anyone is presented anything. We stated that cost, gate-house took it from us, and neither of us checked it.

For reference, three hashes answering three questions:

Hash	Owner	Covers	Answers
binding.digest	approval-engine	action, actor, principal, purpose, target	which act is approved
binding.pdp_digest	approval-engine	the PDP's decision-request binding	which decision request
view_hash	here	brief, packet, highlights, locale, UI release, binding slice	what a person was shown
docs/gate-house-decision-request-layer-placement.md §2 R3. The outcome to be
avoided is both digests shipping with no stated authority rule, leaving the
estate with two canonicalizations of one act.

8b. Where view_hash actually lives (Stage 1)

It is not in the approval entry, by the engine's deliberate design.

POST /v1/approvals/{id}/entries reads the request body and discards it. Approver identity, assurance and evidence_ref come only from the verified token (evidence_ref is jwt-sha256:<digest of the presented token>). The reasoning is sound and we adopt it rather than argue it: a caller-supplied approver field is provenance, not evidence, and that entry is currently the one record containing no caller-supplied data.

Stage 1 arrangement, requiring no change to approval-engine:

1. this repository holds the presentation record and computes both hashes;
2. it emits that record to audit-core as its own evidence;
3. correlation to the approval entry is by (approval_id, subject, approved_at) — all three returned by the engine after a successful entry.

Consequence for an auditor, stated plainly: someone holding only the approval object cannot reach the presentation. They need this surface's record or audit-core as well. GOAL.md DoD-3 — "the approval entry is reconstructable from a view_hash" — is satisfied by the correlation triple, not by a hash stored on the entry.

Putting the binding inside the approval object would be a real change request against approval-engine (an optional, verified-alongside-token view_hash on the entry) and it is doctrine before it is a change request, so it goes to gate-house first. Not raised at Stage 1; recorded here so the option is not lost.

assurance is the only carrier of authentication facts

approval-engine persists the token's assurance claim verbatim and interprets nothing — an empty {} is accepted and evidences nothing. It is therefore the single place where "this was bound under MFA" survives into the approval record. The shape must carry authentication method, acr/amr and auth_time at minimum, and informed-decision and key-cape own it between them. Nothing downstream reconstructs it.

Principal type is verified evidence; subject_id is not

Schema v4 records entries[].principal_type from the verified token. Design principle 10 (humans bind, agents draft) is enforceable from the evidence chain by reading that field. Never infer it from the shape of subject_id — a naming convention is not a verified claim. Entries written before v4 are null and must not be read as human.

8c. Act-scope is not membership — GH-DEC-2026-013 §5

Gate House made the sharpest observation anyone has made about this object model, and it is worth carrying in full because it changes what we record even though it changes no field.

Two different facts are being asked to travel in one claim named tenant:

Fact	Property of	Who needs it
Which scope is this act being entered into	the act	this repository's binding slice
Which tenant is this person a member of	the principal	approval-engine's exact-match admission

"A binding slice that must commit the scope being entered should commit THAT SCOPE, not borrow a membership claim to stand in for it."

Our schema already does the right thing. binding.target is the act-scope: the tenant, environment and system being entered, committed in the binding document and therefore inside view_hash. It is not derived from, and must never be replaced by, the token's tenant claim.

What was missing is not a field but a statement and a record:

• binding.target is the authoritative act-scope commitment. The tenant claim is a membership fact about the principal and is not the act-scope.
• The two must never be collapsed. Where they agree, that agreement is itself a fact worth recording; where they disagree, issuance is refused upstream (key-cape 329e48f) and this surface records the refusal rather than choosing a winner.
• The tenant claim's provenance is recorded. key-cape emits tenant as a bare string, so a consumer cannot tell a tenant the directory asserted about the person from one a registration supplied about the client they came through. GH-DEC-2026-013 §5 requires the claim to carry its provenance; until it does, this surface records which route the value arrived by rather than storing an undifferentiated string.

This is the same rule as unknown versus absent in the stance map and erased versus never held in §8d: wherever a system reaches one appearance by two routes, the record must say which route, or the safer reading becomes unavailable to everyone.

8d. What commitment-only does and does not establish — GH-DEC-2026-014

Commitment-only emission is granted for Stage 1. It is granted on the test GH-DEC-2026-013 set: its distinguishing case fails closed. A reviewer who cannot obtain the content gets no reconstruction rather than a wrong one.

It satisfies non-alteration. It does not satisfy reconstructability, and must not be described as doing so — not here, not in audit-core's documents, and not in any conformance claim.

A commitment-only record is weaker than an archive in a specific way. An archive proves records were not altered or truncated after arrival, never that one was never sent (§2, E-04). A commitment additionally does not carry what it commits to. It establishes that the commitment was made when it says and has not changed. About what was committed to it establishes nothing — except conditionally: if a document is later produced, whether it is the one.

The gap, in the right words

An earlier draft of ours said commitment-only "leaves us able to erase the content". That understates where the problem sits, and Gate House corrected it:

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. The reduction is real. It is not sufficient alone — which is why the grant carries the condition below.

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 evidence path must carry, alongside the commitment:

1. an assertion that committed content exists, and
2. where custody sits,

such that failure to produce at retrieval is a conformance failure attributable to the custodian.

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

This is not a reversal candidate. If it proves expensive, the answer is a cheaper mechanism for the same property, never removal of the property.

Residual, again

Not closed, not credited. The existence assertion narrows the erasure gap — a detectable non-production tells a reviewer something is missing and who owed it. It does not produce the missing thing.

8e. Cadence — declared, and now supportable

audit-core registered this source as proposed (AUDIT-IN-0003, docs/informed-decision-source-registration.md) and landed the detection half (AUDIT-WP-0009 T04/T06/T07). The cadence can stop being described as declared-but-not-operating once heartbeats are flowing.

Per class, not per source — the shape this repository argued for and audit-core adopted. A per-source heartbeat from a mixed-volume emitter is satisfied by its chattiest class and says nothing about the quiet, security-relevant one, which is the only reason heartbeats exist.

Class	Volume	Heartbeat	Reconciliation
presentation	one per render	yes — legitimately silent for days at Stage 1	yes
disposition	low, security-relevant	yes	yes
stance_application	low, security-relevant	yes	yes

Reconciliation applies to every class including the high-volume one: rate detects a stream stopping, never a stream missing the particular renders that mattered.

A heartbeat is an ordinary event — same envelope, same append-only custody, same chain. Deliberately so: a heartbeat stored outside the chain would be the one record that could be back-dated.

Note no_heartbeat_since_registration: declaring a heartbeat and never sending one is its own finding, not a skip.

The bound on both controls

Reconciliation compares audit-core's counts against counts we compute from our own state. Where the emitter is compromised, both controls agree with it — a compromised surface suppresses the event and its own count together, and emits a truthful-looking nothing-to-report.

Both cover loss, outage, drain failure and accident, which is most of what actually goes wrong. Neither covers the residual we already declare, and neither may be described as covering it. Closing it needs an observer independent of the emitter, which §16 put outside audit-core's scope.

Tenant provenance is not in the envelope

audit-core's tenant is not an identity claim they resolve; it is a value our credential is permitted to write, checked by exact string equality. Recording a route in the audit event would be them restating something they did not observe — the same error as claiming an event occurred. It lands in the registration document instead, whose authority is GH-DEC-2026-013's bounded gap rather than a populated directory record. If that gap closes, the entry is revisited rather than assumed still correct.

9. Signed attributes (L4+, horizon)

When AES/QES arrives, the signed attributes carry memo_id, memo_version, disposition.verb and presentation.view_hash. They do not carry awareness_hash unless promotion ran. Recorded here so nothing built at Stage 1 forecloses it.