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
capability_families in repo-classification.allowed.yaml is a fixed list;
'experience' and 'documents' are not in it. Replaced with 'traceability' and
'participation', both in the knowledge_and_evidence family and both accurate:
this repository owns the evidence chain and the surface on which a human takes
part in a decision.
'decision-support' is in the recommended vocabulary but is still not used, for
the statute §8 reason given in the previous commit.
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
C-24 flagged 'user-interface' as outside the recommended family vocabulary.
Replaced with 'experience' and 'documents', both already in estate use.
Deliberately did not add 'decision-support': 'decision' is access-engine's word
under statute §8, and approval-engine withdrew its own seed wording for the
same reason. This repository renders decisions; it must not tag itself as
supporting them.
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
fix-consistency surfaced that GOAL.md's `repo_flavor: project` was wrong.
project-repository-flavor_v0.1.md reserves the prj- flavor for bounded
cross-repo coordination efforts and says durable products use INTENT.md and an
ordinary category. informed-decision is a durable product, so the C-35
"prj- flavor forbids shipping both INTENT.md and GOAL.md" contradiction was
self-inflicted rather than a real conflict.
- .repo-classification.yaml: category product, domain infotech.
- GOAL.md: drop repo_flavor/project_status, add a flavor note explaining that
GOAL.md is retained as the stage statement alongside a stable INTENT.md.
- SCOPE.md: honestly empty — states that nothing is implemented and that
INFD-WP-0001-T06 rewrites it after the gate-house ruling and the specs.
- AGENTS.md: shared State Hub / session / workplan boilerplate, plus the hard
rules for this repository — never decide, never own approval state, never
invent identity, never let awareness enter view_hash, never let an agent
bind, never fork the schema, fail closed.
- INFD-WP-0001: T01 records both corrections; T06 now rewrites SCOPE.md.
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
Updated by fix-consistency on 2026-09-09:
- update .custodian-brief.md for informed-decision
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
Claim ownership of the browser-facing approver UI that approval-engine
deliberately does not contain. approval-engine's INTENT names an approvals
inbox under Non-Goals, and docs/keycape-service-registrations.md records that
the human approver client's client_id and callback URI "must come from its
owner once it exists" — leaving key-cape's KEY-WP-0013-T02 blocked on an
unassigned component.
- INTENT.md: Decision Memo concept, the binding/awareness split and the two
hashes, ownership and non-ownership against the named estate repositories,
and a provisional PEP-shaped layer placement flagged for a gate-house ruling
rather than asserted.
- GOAL.md: Stage 1 is the L3 approval approver surface — the narrowest real
consumer with a live blocking dependency — plus the written answer to who
owns the approver UI.
- workplans/INFD-WP-0001: founding documents, the gate-house layer/ownership
ruling, the four specs (PRD, UseCaseCatalog, ArchitectureBlueprint,
EvidenceModel), schema and canonicalizer promotion out of history/ with the
isolation vectors under test, the key-cape client registration, and a
walking skeleton that includes return and discuss.
history/ is preserved unmodified as provenance.
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
