tegwick
d0d0bad66d
The custodian's record was corrected on 2026-09-21 while this request was being
written. railiance-master had already established — with fuller citations than
this repository had — that flex-auth's validator set {Staff, Engine, Tooling} is
not §3's enumeration: §3 has four rows and `Taxonomy` is the first, defined in
§3.1, catalogued in §4, mapped in §7 and given its own §17. It added the sharper
finding this repository had not reached: §3's table writes `Engines` while §4
types eight rows `Engine`, so two faithful conformance runs disagree about every
engine in the estate.
This repository reached the first half independently and before seeing the
correction, and now records it rather than re-arguing it. The consequence is
what matters: `surface` is the only surveyed value outside §3 itself, and the
only one that needs a ruling on whether the vocabulary is closed. The two cases
do not behave alike and should not be ruled on together — which is what the
corrected record says, and this repository agrees.
One point carries over into the closed outcome: if §3's vocabulary is ruled
closed, the closed set should be written out as declaration values rather than
inferred from table row labels. `Engines`/`Engine` is what happens otherwise,
and it is B1's shape one level further in.
Position unchanged; the declared value remains unchanged pending the ruling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
|
||
|---|---|---|
| deploy | ||
| docs | ||
| history/20260909-initial-exploration | ||
| informed_decision | ||
| intakes | ||
| schemas | ||
| tests | ||
| tools | ||
| workplans | ||
| .custodian-brief.md | ||
| .dockerignore | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| Containerfile | ||
| Containerfile.memo-input | ||
| Containerfile.memo-input.dockerignore | ||
| GOAL.md | ||
| INTENT.md | ||
| layer.yaml | ||
| Makefile | ||
| pep-stance.yaml | ||
| pyproject.toml | ||
| README.md | ||
| requirements.lock | ||
| SCOPE.md | ||
| uv.lock | ||
| 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).