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

**Nothing is implemented.** This repository currently contains founding
documents, the preserved founding exploration under `history/`, and
`workplans/INFD-WP-0001`. There is no package, no service, no deployment, and
no UI.

This file exists because the Repo Manager requires it and because an honest
empty boundary is more useful than an imagined one. It is rewritten in
`INFD-WP-0001-T06`, once the `gate-house` layer ruling (T02) and the
specifications (T03–T05) have fixed the real boundary. **Do not read the
sections below as describing working code.**

## 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.

## 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 that produces `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, not yet built)

- The Decision Memo object and its versions, promoted from
  `history/20260909-initial-exploration/` into governed `schemas/`.
- Canonicalization of the binding and awareness documents, with the four
  isolation vectors under test.
- 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 — `comment`, `discuss`, `return`, `forward`,
  `escalate`, `acknowledge`, `accept`, `decline`, `withdraw`, `configure` —
  and its legality tables.
- The browser-facing OIDC client for human principals: authorization-code +
  PKCE against `key-cape`, yielding a token with `aud=approval-engine`,
  `principal_type: human`, scope `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`. This surface never caches validity, never infers
  consumption, never requests `approval:consume`.
- Approval doctrine: which acts require approval, how many approvers, which
  separations of duty — `gate-house`.
- Identity and authentication — `key-cape`. Identity is imported, never
  invented here.
- The evidence archive — `audit-core`. This repository emits and exports.
- Credentials materialized after a decision — `secrets-engine`.
- Notification transport, ticketing, and general workflow.
- L4/L5, QES, QTSP integration, qualified archival retention.
- The mandate graph. Stage 1 routes to a named approver and does not maintain a
  map of who may bind what — a known, accepted limitation recorded in `GOAL.md`.

## Layer placement

**Provisional and unratified.** The working position is PEP-shaped under
statute §6.4 and companion §5. `layer.yaml` does not exist yet and is written
from the `gate-house` ruling in `INFD-WP-0001-T02`, not from this file.
-												Correct repo flavor to product; add SCOPE, AGENTS, classification

fix-consistency surfaced that GOAL.md's `repo_flavor: project` was wrong.
project-repository-flavor_v0.1.md reserves the prj- flavor for bounded
cross-repo coordination efforts and says durable products use INTENT.md and an
ordinary category. informed-decision is a durable product, so the C-35
"prj- flavor forbids shipping both INTENT.md and GOAL.md" contradiction was
self-inflicted rather than a real conflict.

- .repo-classification.yaml: category product, domain infotech.
- GOAL.md: drop repo_flavor/project_status, add a flavor note explaining that
  GOAL.md is retained as the stage statement alongside a stable INTENT.md.
- SCOPE.md: honestly empty — states that nothing is implemented and that
  INFD-WP-0001-T06 rewrites it after the gate-house ruling and the specs.
- AGENTS.md: shared State Hub / session / workplan boilerplate, plus the hard
  rules for this repository — never decide, never own approval state, never
  invent identity, never let awareness enter view_hash, never let an agent
  bind, never fork the schema, fail closed.
- INFD-WP-0001: T01 records both corrections; T06 now rewrites SCOPE.md.

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

											
										
										
											2026-09-09 12:38:41 +02:00
+								# 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
 								**Nothing is implemented.** This repository currently contains founding
 								documents, the preserved founding exploration under `history/`, and
 								`workplans/INFD-WP-0001`. There is no package, no service, no deployment, and
 								no UI.
 								This file exists because the Repo Manager requires it and because an honest
 								empty boundary is more useful than an imagined one. It is rewritten in
 								`INFD-WP-0001-T06`, once the `gate-house` layer ruling (T02) and the
 								specifications (T03–T05) have fixed the real boundary. **Do not read the
 								sections below as describing working code.**
 								## 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.
 								## 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 that produces `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, not yet built)
 								- The Decision Memo object and its versions, promoted from
 								  `history/20260909-initial-exploration/` into governed `schemas/`.
 								- Canonicalization of the binding and awareness documents, with the four
 								  isolation vectors under test.
 								- 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 — `comment`, `discuss`, `return`, `forward`,
 								  `escalate`, `acknowledge`, `accept`, `decline`, `withdraw`, `configure` —
 								  and its legality tables.
 								- The browser-facing OIDC client for human principals: authorization-code +
 								  PKCE against `key-cape`, yielding a token with `aud=approval-engine`,
 								  `principal_type: human`, scope `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`. This surface never caches validity, never infers
 								  consumption, never requests `approval:consume`.
 								- Approval doctrine: which acts require approval, how many approvers, which
 								  separations of duty — `gate-house`.
 								- Identity and authentication — `key-cape`. Identity is imported, never
 								  invented here.
 								- The evidence archive — `audit-core`. This repository emits and exports.
 								- Credentials materialized after a decision — `secrets-engine`.
 								- Notification transport, ticketing, and general workflow.
 								- L4/L5, QES, QTSP integration, qualified archival retention.
 								- The mandate graph. Stage 1 routes to a named approver and does not maintain a
 								  map of who may bind what — a known, accepted limitation recorded in `GOAL.md`.
 								## Layer placement
 								**Provisional and unratified.** The working position is PEP-shaped under
 								statute §6.4 and companion §5. `layer.yaml` does not exist yet and is written
 								from the `gate-house` ruling in `INFD-WP-0001-T02`, not from this file.