| A3 | The founder runs `warden access informed-decision-sitting-requester-login --exec -- tools/create_sitting_approvals.sh` | The create-only client secret (`informed-decision-sitting-requester`, `approval:create` only, `sub=informed-decision`) is held in **attended reader** custody, so a human has to log in only to read it |
| A4 | Someone hand-edits `access-engine/examples/informed-decision-sitting/policy.md` (new exact record, version bump), CI builds it, the pin is redeployed, `deploy/sitting-admission.json` is bumped and the review service rolls out | Admission is an **exact-record list**: each memo id, approval id and binding digest is a policy value |
| A5 | An operator runs `attach_compact_bindings.py` and `load_sitting_memos.py` against the live store | There is no intake: memos are files that reach the store through an operator CLI |
| A6 | The founder signs in with fresh MFA and answers | **This is the only step that has to be human** |
So the attended human appears three times before the one act that needs him.
None of A3 to A5 adds judgment about the question. A3 is custody friction, A4
duplicates facts approval-engine already holds, and A5 is plumbing.
## 2. Target flow
```text
agent / service informed-decision (intake) approval-engine access-engine founder
| POST /v1/memos ------------> authenticate workload
| `idempotency_key` | Submitter-chosen, 8 to 128 chars `[A-Za-z0-9._:-]` |
| `memo_class` | One of the classes in the submitter's allow list (for example `credential-lane`, `work-record-accept`, `spend-envelope`, `adr-accept`) |
| `review_group` | For example `net-kingdom-admins`. Must be allowed for the submitter |
memo id, approval id, binding digest, submission digest; no content).
## 7. Invariants kept
| Invariant | Where it is enforced after the change |
|---|---|
| Humans bind; agents never accept/decline/seal | Intake has no bind route; workload tokens are refused on every browser route; approval-engine GH-DEC-2026-016 refuses non-human entries on `human_control` approvals; the requester client has no `approval:approve` |
| MFA freshness on answer | Unchanged PDP identity bar (900 s) plus the review service's own act-time check |
| One question per memo | Intake validation §3.3(3); anti-requirement unchanged |
| No approve-all | No batch act exists; intake creates one approval per memo; acts are per memo |
| Human sees exactly what is bound | `view_hash` per presentation; live approval read and digest compare before render and act; digest carried to PDP |
| No secret values | Secret-marker scan at intake; notifications carry no content; client secret only via ESO into the pod |
| Membership is not a bind | `review_group` is eligibility only; no auto-approval |
## 8. Write-back to State Hub
When a memo with `serves.hub_decision_id` and `resolves: "on-answer"` gets a
terminal human disposition (`accept` or `decline`; `return` and `discuss` do
not resolve), the review service calls the sanctioned hub write:
```text
POST /decisions/{hub_decision_id}/resolve
{"decided_by": "<reviewerdisplayname> via informed-decision",
"rationale": "<verb> in informed-decision memo <memo_id> v<version>; approval <approval_id>;
binding <digest>; view_hash <view_hash>; disposition <id> at <time>",
"write_log": true}
```
- Behind `INFD_HUB_WRITEBACK=1` (default off). Off means the payload is built
and recorded, not sent.
- Idempotent: `409 already resolved` with our memo id in the hub rationale is
success; a 409 without it is a recorded `conflict` for a human to look at.
Transport errors retry from a local outbox; the human's act is never undone
by a write-back failure.
- One decision, one resolving memo. A packet that spans several lanes (like D1)
uses `resolves: "never"` on its per-lane memos and gets a progress note
instead; the hub decision is resolved by its own resolving memo.
- The hub is a read model: the write-back reflects an act that already
happened in informed-decision. It never decides.
## 9. Build mode now, close-down later
| # | Relaxation accepted now | Re-arm at close-down |
|---|---|---|
| R1 | Posing is no longer operator-gated: any listed submitter can put a memo in front of the founder | Keep, but the submitter list and class list are reviewed data with a signed regeneration path |
| R2 | Workstation agents pose through State Hub, whose API is unauthenticated on the loopback tunnel; `drafted_by` is asserted | Hub authenticates its writers (agent workload/OIDC identity) before forwarding; the forwarded submitter carries that identity |
| R3 | PEP-carried approval and intake attributes in the PDP request (§5.3) | access-engine verifies a signed approval-engine claim and a signed intake receipt itself |
| R4 | The requester client secret moves from attended to workload custody (ESO into the review pod) | Rotation schedule, ESO read audit, and proof the pod cannot read sibling paths |
| R5 | Admitted classes/submitters baked into the access-engine image | Runtime-loaded policy data with integrity checks, or a reviewed regeneration pipeline (same as checklist row 6) |
| R6 | Hub write-back uses the unauthenticated hub API | Hub requires the informed-decision workload identity for `resolve` and records it |
| R7 | No `Idempotency-Key` on approval create; orphan drafts possible after a crash | approval-engine idempotent create |
| R8 | Notification only via hub inbox | Authenticated notification channel; no content beyond id and question |
Never relaxed, build mode or not: humans bind, fresh MFA on answer, one
question per memo, no approve-all, no secret values, audit-core evidence.
