T05 written after the ruling rather than before it, which was the point of
gating it. GH-DEC-2026-012 limit 3 did most of the shaping: the evidence copy
must reach audit-core independently of this component, because here the actor
being audited and the evidence source are the same. Booked as four binding
implementation consequences plus O-02, which must be resolved before T08 ships —
"we will add the independent path later" is how limit 3 becomes
limit-3-in-principle.
Other constraints fixed in the blueprint: presentation/ is the only writer of
view_hash; the approval-engine client exposes no validity cache; a fail-closed
outcome is never recorded as an approver's decline, since the human made none;
the assurance shape is cited from key-cape's contract rather than restated so it
cannot drift; and no polling loop may synthesise the inbox approval-engine
refuses to provide.
T06 closed with the SCOPE.md rewrite the ruling unblocked. It carries a "What
this repository does not claim" section, because a scope file listing only
capabilities overstates them: the decision path is not validated while
GH-DEC-2026-010 is open, the residual is not closed, view_hash is not inside the
approval entry, and nothing is deployed.
Two open items block the remainder. O-01, the human token tenant, blocks T07 and
is not ours alone to decide. O-02, the independent evidence path, blocks T08.
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
approval-engine replied to INFD-IN-0001 with docs/approver-surface-requirements.md
(31da1af, 5203f46) and two corrections. Several of my requirements were wrong or
incomplete; revised rather than appended to.
Corrected:
- PR-02 listed only approval:approve. Wrong — the surface also needs
approval:read to fetch what it renders. As drafted it would have shipped a
client able to submit an entry it could never display. That changes a
registration key-cape has already implemented, so it is their call (open
question A).
- NC-03 implied approval-engine refuses non-human approver entries. It does not;
only /consume is principal-restricted, and the operator service client holds
approval:approve. Enforcement of "humans bind, agents draft" is therefore ours
alone, and is auditable via schema v4's entries[].principal_type — never from
the shape of subject_id.
Added:
- PR-04 assurance shape. approval-engine persists it verbatim and accepts an
empty object, so it is the only place MFA survives into the approval record.
Needs auth method, acr/amr, auth_time, agreed with key-cape.
- PR-05 entitlement. A 200 from the engine is not permission to view; we owe
access-engine a check before rendering. Consuming a decision, not making one.
- PR-06 response mapping, including 409 duplicate_approver rendered as SUCCESS
(a browser double-submit is routine and the first entry stands) and 503 as
fail-closed.
- PR-07 and a matching INTENT wrongness condition: never render `approved` as
permission to act. That is a PDP in the browser wearing UI copy.
- L-05, L-06 and EvidenceModel 8b: view_hash cannot ride into the entry — the
POST discards its body by design — so Stage 1 correlates by (approval_id,
subject, approved_at). DoD-3 is satisfied by the triple, not by a stored hash.
PRD open question 1 is answered by construction: there is no inbox endpoint and
there will not be one, so the approvals-inbox shape is foreclosed upstream.
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
Verified the three published hashes reproduce byte for byte before promoting
anything, then moved the schema, canonicalizer and vectors into governed assets.
history/20260909-initial-exploration/ is untouched and stays the provenance
record.
- schemas/, informed_decision/, tests/vectors/ populated; the reference
canonicalizer's ad-hoc __main__ block replaced by a real
`python -m informed_decision` entry point.
- tests/test_canonicalize.py — 20 tests, all green. Published vectors, all four
isolation properties, canonical-form round-trip, key sorting, and a provenance
test asserting the governed fixtures have not drifted from history/.
- docs/specs/EvidenceModel.md — the two hashes, the split and why it exists, the
four isolation properties, the presentation record, the bundle, and the
relationship to audit-core.
- pyproject.toml, Makefile.
One test of mine was wrong on first run: it scanned for ", " to assert no
insignificant whitespace, which fires on prose inside a brief. Replaced with a
canonical round-trip comparison, which is the property actually meant. The
canonicalizer was correct.
EvidenceModel leads with what the model does NOT claim — no proof of
comprehension, no proof of reading (deliberately, since the alternative is
surveillance), no survival of a compromised surface, and audit-core's inherited
bound that a hash chain cannot prove a record was never sent.
T06 stays progress: the SCOPE.md rewrite is gated on the T02 ruling.
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
T02 — intake INFD-IN-0001 filed with gate-house and messages sent to gate-house,
key-cape and approval-engine. Status progress; it now waits on an external
ruling. key-cape was told explicitly why T07 is not answering KEY-WP-0013-T02
yet — a placeholder callback URI would either fail closed or register an origin
no component owns — and given the token shape to check now rather than at T07.
T03 — ProductRequirementsDocument.md. 30 requirements, each traced to a GOAL.md
DoD item, an INTENT principle or wrongness condition, a state-transition guard,
or a named external contract, and each with an observable pass condition.
Anti-requirements are stated as testable absences: no dwell timers, no attention
analytics, no dark patterns, no auto-approval, no approval-state caching, no
authorization endpoint. Four limitations are recorded up front, including that
escalate without a mandate graph is forwarding and that view_hash is computed by
the renderer.
T04 — UseCaseCatalog.md. L0-L5 with counterparties, plus ten negative cases
bound to guards and isolation vectors. Each case records the constraint it
places on the shared schema, so scale invariance is testable rather than
asserted. Closes with the four changes that would fork the object.
T05 and T07 remain gated on the ruling. T06 is independent and is next.
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
File the gate-house decision request that gates INFD-WP-0001-T02, before any
architecture is written, so the ruling constrains the design rather than being
retrofitted to it.
Three rulings requested: layer and role (proposed PEP-shaped, §6.4/companion
§5); whether a presentation attestation also makes this a PIP or must reach
consumers only through audit-core; and the relationship between view_hash and
approval-engine's binding digest.
The third is the highest risk and the reason this is filed first. Both digests
claim to canonicalize "the binding" but cover different material — the approval
digest exists without a human in the loop, view_hash covers the brief, packet,
highlights, locale and UI release. Three candidate rulings are set out with what
each costs; the proposal is distinct attestations with an explicit authority
rule, but any of the three is implementable. The outcome to avoid is both
shipping with no stated relationship.
The self-dealing objection is argued against ourselves rather than left for
review, and the residual is stated plainly: a compromised surface can present X
and attest Y, structurally the same residual approval-engine names for
adversarial omission at a compromised source. No claim is made to close it.
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
