informed-decision/SCOPE.md

# SCOPE

> Implemented-and-first-cut boundary for agents and contributors. Aspirational
> direction belongs in `INTENT.md`; the current stage belongs in `GOAL.md`;
> current work and gates belong in `workplans/`.

## Status — 2026-09-09

**Specification, declaration and the domain core are complete. No service is
deployed.**

What exists and is tested (87 tests):

- layer and stance declarations — `layer.yaml`, `pep-stance.yaml`,
  `informed_decision/stance.py`, with published-equals-shipped asserted;
- the governed canonicalizer and schema, with the three published vectors
  reproducing byte for byte and all four isolation properties pinned;
- the **domain core**: `memo.py` (the Decision Memo, its versions and the
  binding document), `presentation.py` (the sole writer of `view_hash`),
  `disposition.py` (the verb vocabulary and guards `G_NOAGENT`, `G_STEP`,
  `G_PRES`, `G_ACK`, `G_REASONS`, `G_SEALED`), `provenance.py` (claim routes,
  A-16), `evidence.py` (the local outbox and commitment records);
- `approval_client.py` — the seam to `approval-engine` plus a fake carrying its
  actual refusal semantics.

What does not exist: any HTTP surface, any persistence, any UI, any deployment.
The origin `decisions.coulomb.social` is live but serves an nginx placeholder.

`INFD-WP-0001-T08` remains open for the live end-to-end proof, which is gated on
`APPROVAL-WP-0002-T01` and a deployed `approval-engine`.

## One-liner

informed-decision is the presentation and binding surface for decisions: it
renders a Decision Memo to the human who holds the mandate, records what was
shown, and binds their identity to the act — and owns the browser-facing
approver UI that `approval-engine` deliberately does not contain.

## Layer

**PEP-shaped**, ruled by `GH-DEC-2026-012`. Not an Engine. Companion §5 owed,
statute §6.4 in full. Declared in `layer.yaml` in this repository's own voice.

It emits one PIP-like fact — *what was presented* — as a claim, under three
limits that are the substance of the permission rather than caveats on it:

1. the claim carries presentation and nothing else, and must never carry,
   restate, summarise or imply a decision or verdict;
2. the claim must never be an input to the decision it presents for;
3. the evidence copy reaches `audit-core` **independently** of this repository.

Limit 2 is load-bearing: the argument that a renderer attesting its own
rendering is not self-dealing was accepted *because* that limit holds.

## Core Idea

A decision surface is not a workflow engine and not a decision point. This
repository owns the Decision Memo object, the presentation record, the
canonicalization producing `view_hash` / `awareness_hash`, the disposition
vocabulary, and the evidence bundle export. It does not evaluate whether an act
is permitted, does not hold approval current-state, and does not archive the
trail.

## In Scope — first cut (Stage 1)

**Built and tested:**

- Canonicalization of the binding and awareness documents, with the three
  published vectors reproducing byte for byte and all four isolation properties
  pinned (`tests/test_canonicalize.py`).
- The Decision Memo schema and worked examples, governed under `schemas/`.
- The unreachable-engine stance map, built to v0.8 obligation 3, with
  published-equals-shipped asserted by test (`tests/test_layer_conformance.py`).

**Specified, not built:**

- The presentation record: what was rendered, to whom, when, in which locale and
  UI release.
- Required-highlight acknowledgment as a precondition of binding.
- The disposition vocabulary and its legality tables. Only `accept` reaches
  `approval-engine`; `return`, `discuss`, `escalate` and the rest are
  memo-level.
- The browser-facing OIDC client: authorization-code + S256 PKCE against
  `key-cape`, scopes `[openid, approval:read, approval:approve]`.
- An L3 approver surface calling `approval-engine`'s approval-entry mutation.
- The evidence bundle as an offline-verifiable export.

## Out of Scope

- Authorization decisions — `access-engine`, always and only (statute §6).
- The approval object, its state machine, validity and consumption —
  `approval-engine`. Never cached, never inferred, never `approval:consume`.
- Approval doctrine — `gate-house`.
- Identity and authentication — `key-cape`. Imported, never invented. The
  `assurance` shape is `key-cape`'s and is cited, not restated.
- The evidence archive — `audit-core`.
- Credentials materialized after a decision — `secrets-engine`.
- Notification transport, ticketing, general workflow.
- **An approvals inbox.** Foreclosed upstream as well as here:
  `approval-engine` exposes get-by-id only and will not add a list.
- L4/L5, QES, QTSP, qualified archival retention.
- The mandate graph — so a Stage 1 `escalate` is an assertion, not a verified
  claim.

## What this repository does not claim

Stated here because a scope file that only lists capabilities overstates them.

- **The decision path is not validated.** `GH-DEC-2026-010` requires a decision
  be attributable to `access-engine`; no consumer can satisfy that today because
  the envelope is unsigned (`FLEX-WP-0024`). This surface records
  `decision_attributable: false` and must not describe validation as complete.
- **The residual is open.** A compromised surface can present X and attest Y.
  `GH-DEC-2026-012` states it is not closed and does not credit this repository
  with closing it.
- **`view_hash` is not inside the approval entry.** `POST /entries` discards its
  body by design. Correlation is `(approval_id, subject, approved_at)`, so an
  auditor holding only the approval object cannot reach the presentation.
- **Commitment-only evidence is not reconstructability.** `GH-DEC-2026-014`
  granted it for Stage 1 and bounded it: it satisfies non-alteration, and moves
  integrity out of our control while leaving *availability* entirely inside it.
  The party that can withhold the content is the party the evidence is about.
  Narrowed by the required existence assertion; not closed.
- **The registration-bound tenant is a declared bounded gap**, not the terminal
  state. `GH-DEC-2026-013` ruled directory-sourced terminal and admitted
  `key-cape`'s shape because its distinguishing case fails closed. Build to it
  as transitional.
- **Nothing is deployed**, so nothing is observed in production and nothing is
  contained automatically.

## Open

- **The deployed origin** — the one remaining input to `T07`. `client_id` and
  the callback URI must name a real origin, since redirects match exactly.
- **`audit-core` registration and cadence** — the payload is ruled
  (commitment-only, with the existence assertion); the sender registration and
  whether reconciliation-plus-heartbeat suits a mixed-volume source are still
  `audit-core`'s to answer. Required before `T08` ships.

*Closed 2026-09-10:* the human token tenant (`GH-DEC-2026-013`, `key-cape`
`329e48f`) and the evidence payload question (`GH-DEC-2026-014`).