# informed-decision

Decision lifecycle service for agents and humans: research, retrieve, prepare,
evaluate, register, publish, comment, refine and human acceptance. The deployed initial
architecture separates a headless foundation from the UI at
`decisions.coulomb.social`; new decisions are runtime data, requiring no
per-decision infrastructure rollout.

See the [product and architecture contract](docs/specs/DecisionLifecycleService.md)
and [delivery workplan](workplans/INFD-WP-0007-decision-lifecycle-service.md).
The initial production audience is live and human acceptance is confirmed.
[SCOPE.md](SCOPE.md) records the delivered boundary and remaining work.

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`).

## Production intake and historical fallback

For the admitted State Hub / decision-record audience, register, revise and
publish through the private lifecycle API, request review, then explicitly queue
the returned envelope in the State Hub dispatcher. The human reviews through
the existing protected browser path. See [the deployed release](deploy/lifecycle/README.md).

`tools/create_sitting_approvals.py` / `.sh`, `tools/attach_compact_bindings.py` and
`tools/load_sitting_memos.py` are historical compact-sitting fallback tools. They
are not the normal path for new admitted decisions. Their original attended
custody and approval requirements still apply; do not use them to bypass intake,
uncertain-create handling, policy checks or human binding. Historical batch
runbooks remain provenance, not the current intake workflow.