tegwick
ebd35b59cf
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 |
||
|---|---|---|
| docs | ||
| history/20260909-initial-exploration | ||
| intakes | ||
| workplans | ||
| .custodian-brief.md | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| INTENT.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
informed-decision
User interface for executive decisions, modelled as a sign-and-return book — the German Umlaufmappe / Zeichnungsbuch, made cryptographic.
A Decision Memo carries a question, the context needed to answer it, the requested act, and a binding between identity, what was shown, and what was bound. The promise is not "the file was signed" but "this person, in this role, was shown this view, and bound this act."
One object model from a ten-second login (L0) to a multi-party instrument (L5).
Where to start
| File | What it is |
|---|---|
INTENT.md |
Why this repository exists and what it must never become |
GOAL.md |
The current stage, its invariants, and its definition of done |
workplans/ |
Current work |
history/20260909-initial-exploration/ |
Founding exploration — schema, state transitions, canonicalization, vectors |
Stage 1
Own the browser-facing approver UI that approval-engine deliberately does
not contain, and answer in writing who owns it. approval-engine is a
bearer-token resource server with no browser client; key-cape
(KEY-WP-0013-T02) is waiting on a client_id and callback URI that no
component has claimed. This repository claims them.
See GOAL.md.
Boundaries
This repository renders questions and records answers. It does not decide
(access-engine), does not own the approval object (approval-engine), does
not author approval doctrine (gate-house), does not authenticate anyone
(key-cape), and does not archive the trail (audit-core).