tegwick
b78c15a7ef
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 |
||
|---|---|---|
| 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).