--- repo: informed-decision category: product stage: 1 stage_status: active started: "2026-09-09" --- > **Flavor note.** This is a durable **product** repository, not a `prj-` > project repository. Per `project-repository-flavor_v0.1.md`, durable products > use `INTENT.md` and an ordinary category; the `prj-` flavor is for bounded > cross-repo coordination efforts and is not used here. `GOAL.md` is retained > as the *stage* statement: `INTENT.md` is stable and aspirational, this file > is what the current stage must achieve and is replaced when the stage turns > over. # Goal — informed-decision, Stage 1 ## Outcome **The approver UI has an owner, and it is this repository.** Stage 1 is complete when a human approver can be shown a `approval-engine` approval request on a surface this repository owns, understand it, act on it with a vocabulary richer than approve/reject, and leave behind a reconstructable record of *what they were shown when they bound themselves* — and when `key-cape` holds the browser-client registration it has been waiting for since 2026-09-08. Two things are being settled at once, and they are the same thing: 1. **The ownership question.** `approval-engine` disowns the inbox by design and named the gap in `docs/keycape-service-registrations.md`. Nobody picked it up. Stage 1 picks it up, in writing, with a catalog placement agreed by `gate-house` rather than asserted. 2. **The capability.** A browser-facing approver surface that presents `approval:approve` tokens to `approval-engine` and records the presentation. ## Why this is the first stage The founding exploration reaches L5 — multi-party international instruments. Stage 1 deliberately does not. It takes the **narrowest real consumer with a live blocking dependency**, because a decision surface with no consumer is a design document, and this estate already has enough of those. The approval approver flow is L3 on the depth spectrum. It is the right first cut because it is the only level currently costing another repository progress. ## What Stage 1 delivers - `INTENT.md`, `GOAL.md`, `SCOPE.md`, and a `layer.yaml` derived from a `gate-house` answer. - The four specs: `docs/specs/ProductRequirementsDocument.md`, `docs/specs/UseCaseCatalog.md`, `docs/specs/ArchitectureBlueprint.md`, `docs/specs/EvidenceModel.md`. - The Decision Memo schema promoted out of `history/` into `schemas/`, with the canonicalizer and the isolation vectors under test in CI. - A published OIDC browser-client contract — `client_id` and callback URI — handed to `key-cape`, closing `KEY-WP-0013-T02`. - A working L3 approver surface against a deployed `approval-engine`. ## What Stage 1 explicitly does not deliver - L4/L5, QES, QTSP integration, or qualified archival retention. - Multi-party parallel sign-off (`Mitzeichnung` across several parties at once). - The mandate graph. Stage 1 routes to a named approver; it does not maintain a living map of who may bind what. Without that map, `escalate` is only forwarding — this is a **known and accepted** Stage 1 limitation, recorded here so it is not discovered later as a defect. - EUDI Wallet / eID identity import. Identity comes from `key-cape` only. - A general workflow engine, a notification transport, or a ticketing system. ## Invariants These hold for Stage 1 and for every stage after it. - **`access-engine` remains the only policy decision point.** This repository renders questions and records answers. No endpoint here answers "may this actor do X". A disposition recorded on a memo is evidence of a human act, not an authorization verdict. - **`approval-engine` remains the sole owner of approval state.** This surface calls its mutations and reads its introspection claim. It never caches validity, never infers consumption, and never holds approval current-state. `GH-DEC-2026-003` ordering is honoured: decision, then consume, then act. - **`approved` is never rendered as permission to act.** It is a state of an object. Presenting it as "you may now do the thing" is a policy decision point in the browser. - **The decision path is not validated, and must not be described as such.** `GH-DEC-2026-010` requires a decision be attributable to `access-engine`, and no consumer can satisfy that today — the envelope is unsigned (`FLEX-WP-0024`). This surface records that a decision was obtained and what it said, and records `decision_attributable: false`. - **Entitlement to view is `access-engine`'s.** A `200` from `approval-engine` is not permission to see the approval; that engine never answers "may this actor do X". This surface obtains a decision before rendering and never substitutes local judgment for it. - **Identity is imported.** Every principal on this surface is authenticated by `key-cape`. No local credential, no self-issued assurance level. Human principals carry `principal_type: human` and are refused `approval:consume` by the engine — this surface must never attempt it. - **The binding/awareness split survives contact with the first consumer.** `view_hash` covers only what the person committed to. Proposed roles, other-tenant orientation and last-session summaries are hashed separately and are not signed unless explicitly promoted into `awareness_promoted`. - **One question per memo.** An approval that bundles three unrelated acts is three memos. - **Humans bind, agents draft.** An agent may assemble a memo and may not complete a disposition. - **The schema does not fork.** Any Stage 1 field added for approvals must be expressible for an L0 login banner, or it does not go in the shared object. ## The question Stage 1 must answer in writing > **Who owns the approver UI?** **Answered 2026-09-09 by `GH-DEC-2026-012`.** The proposal below was confirmed in full. Recorded as proposed-then-ratified rather than rewritten as though it had always been settled: - **informed-decision owns it** — the surface, the presentation record, the browser client, and the evidence of informedness. - It is **PEP-shaped**, not an Engine: it is browser-facing and causes a protected side effect on the far side of a decision, so it owes companion §5 and statute §6.4. - It supplies exactly one PIP-like fact — *what was presented* — as a claim carrying `view_hash`, issuer and freshness, and it never evaluates that fact. - **Ruled:** PEP-shaped, confirmed as proposed. No second catalog row for the presentation claim — PEP and PIP are shapes a repository has. The claim is permitted under three limits (presentation-only; never an input to the decision it presents for; evidence reaches `audit-core` independently), and `view_hash` versus the binding digest is settled as distinct attestations with an authority rule, linked by co-reference and never by nesting. `layer.yaml` and `pep-stance.yaml` declare it; `INTENT.md` carries the reasoning. ## Definition of done 1. ~~`gate-house` has ruled on the layer placement and `layer.yaml` reflects it.~~ **Done 2026-09-09** — `GH-DEC-2026-012`; `layer.yaml`, `pep-stance.yaml` and `tests/test_layer_conformance.py`. 2. `key-cape` has the `client_id` and callback URI, and `KEY-WP-0013-T02` is unblocked with the answer traceable to this repository. 3. The four specs exist, are reviewed against the current `approval-engine`, `access-engine`, `key-cape` and `audit-core` contracts, and name their external gates. 4. `view_hash` / `awareness_hash` are computed by code in this repository, and the four isolation vectors from the exploration are green in CI. 5. One approval is approved end to end by a human through this surface against a deployed `approval-engine`, and the resulting approval entry is reconstructable from a stored presentation. 6. `return` and `discuss` are demonstrated on a real approval and are distinguishable from `decline` in the record. ## Stage 2 and beyond — direction only, not commitment L0 informed login/elevation in front of `key-cape`, then L2 ADR accept against the estate's own decision records. Those two prove scale invariance downward and sideways. L4 contract paths and any QES work wait for a named buyer and a retention answer, both open questions in the founding exploration.