tegwick
08b190928f
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 |
||
|---|---|---|
| docs | ||
| history/20260909-initial-exploration | ||
| informed_decision | ||
| intakes | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| INTENT.md | ||
| Makefile | ||
| pyproject.toml | ||
| 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).