tegwick
3a7391fe63
approval-engine answered R3 and recommends exactly the option GH-DEC-2026-012 refused: that our binding document carry their binding.digest as a field rather than re-canonicalize action/actor/principal/purpose/target ourselves. We cannot comply with both, so this is raised as a finding rather than resolved. It is not a wording difference. Our binding slice canonicalizes principal and target, two of the five fields in their digest, so co-reference by identifier alone leaves two independent canonicalizations of one act linked by a shared id. GH-DEC-2026-012 manages that with an authority rule; approval-engine's proposal removes it. Both are coherent and they are not the same design. New information the refusal may not have had: their digest covers exactly five act fields, and they state that widening it to cover presentation would be a defect since a new UI release would invalidate every prior approval. The GH-DEC-2026-008 cycle condition is mutual containment, so if their digest structurally cannot contain view_hash the containment is one-directional. Not asserted as settling it — that cycle was found by two engines independently within hours, and "the cycle cannot arise here" is the belief such failures punish. Deliberately not adopted, despite coming from the layer that owns the digest and despite our having offered to let them settle R3. Gate House was right that a bilateral agreement produces agreement rather than an authority rule, and that applies to this one too. layer.yaml is unchanged and carries a linkage_under_review marker rather than a silent edit. Also carries the smaller doctrine question approval-engine handed on: whether approver evidence should be human-only at the engine, since entries[].principal_type is auditable after the fact and stops nothing, and there is no upstream backstop for humans-bind-agents-draft. 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 | ||
| layer.yaml | ||
| Makefile | ||
| pep-stance.yaml | ||
| 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).