informed-decision/docs/decision-services-alignment-answer.md

Owner answer: decision services alignment (S1, S3, S4)

Date: 2026-10-31 Answering: net-kingdom docs/proposals/2026-10-31-decision-services-alignment-review.md (commit b764561), trigger docs/proposals/2026-10-31-nk56-t17-founder-approval-path.md, hub message 6811164f. Workplan: workplans/INFD-WP-0010-present-existing-and-proportionate-decisions.md.

Summary

Item	Answer	Status
S1 present_existing	Accepted, adapted as a submitter profile on the existing /v1/memos route	Implemented locally and tested; not deployed. Two owner dependencies outside this repository before live use (below)
S4 C1 single-screen confirm	Accepted in principle as a lighter memo profile on the same memo model	Not built. Needs gate-house class doctrine (S5) and an access-engine policy action first
S3 hub write-back	Accepted. The write-back already exists (hub_writeback.py, INFD-WP-0005) behind INFD_HUB_WRITEBACK=1	Enablement is a founder decision; structured links need state-hub's decision-link fields

The founder's direction (one surface, weight proportional to risk, a clear split with approval-engine) fits INTENT.md directly: one memo model at every level is the thesis, and "never own approval state" makes the proposal's role split the correct one. Intake creating approvals as informed-decision was a Stage 1 convenience, not a principle. It stays for existing submitters (state-hub), because those approvals are used by nobody but the human review itself.

S1: present an existing approval

Fit

• INTENT.md and AGENTS.md: informed-decision never owns approval state, never consumes, never decides. Presenting an object someone else created keeps all three. It removes informed-decision from the actor role, which it should never have had for approvals that a service will execute against.
• The review side already re-reads the approval with the human's token on every open/accept, and compares the binding digest and actor to the intake record (review.py _authorize). Only intake and the recorded requester had to change.

Profile, not route (answer to review §6 Q2a)

present_existing is a property of the registered submitter, not of the request body. Same route (POST /v1/memos on the private workload listener), same envelope (informed-decision.memo-intake v1). Reasons: one admission path (TokenReview, daily budget, idempotency, secret scan, packet hashing all unchanged), and a submitter cannot choose its own weight. A row is either a create-path submitter or a present-existing submitter, never both.

Contract (as implemented)

Registry row (intake-submitters.json, reviewed deployment data, reloaded on every request):

"system:serviceaccount:sso:nk-bind-executor": {
  "submitter_id": "nk-bind-executor",
  "memo_classes": ["bounded-execution"],
  "review_groups": ["net-kingdom-admins"],
  "daily_limit": 10,
  "present_existing": {
    "approval_actor": "service:nk-bind-executor",
    "actions": ["bounded-execution"]
  }
}

The key is the Kubernetes service account (TokenReview, audience informed-decision-intake). The approval_actor is the KeyCape subject the same workload uses towards approval-engine. The registry is the only place that joins those two identities; the body never names the actor. approval_actor must match service:<slug> and must not be service:informed-decision. actions is a non-empty list of slugs.

Envelope differences for a present-existing submitter:

• memo.approval_id (UUID) and memo.approval_binding_digest (sha256:<64 hex>) are required. They remain forbidden (approval_pinned_by_submitter) for every other submitter.
• approval_intent.action must be in the profile's actions (action_not_admitted).
• approval_intent.target may be any flat object of 1–8 string fields (BEA uses {admission_id, admission_digest}). For other submitters it stays {id, type, system}.
• approval_intent.{action, principal, purpose, target} restate the approval's binding; the actor is taken from the profile.

Verification (intake_service.verify_existing), by a read-only GET /v1/approvals/{id}; every condition must hold, the first failure is the refusal (HTTP 409 unless noted):

Check	Refusal
returned id equals memo.approval_id	approval_mismatch
status == "requested"	approval_not_requested
entries == []	approval_has_entries
binding.human_control is true	approval_not_human_controlled
binding.actor == the profile's approval_actor	approval_actor_mismatch
binding.digest == memo.approval_binding_digest	approval_digest_mismatch
binding.{action, principal, purpose, target} equal the intent	approval_binding_mismatch
required_count == 1 (Stage 1 presents one approver)	approval_required_count_unsupported
validity.expires_at in the future	approval_expired
GET failed or no reader configured	approval_unreadable / present_existing_unavailable (503)
another memo already presents this approval	approval_already_presented

The action-class check happens at validation, before any read. On refusal the reservation is released (no engine side effect happened), so a corrected submission can be retried. In this path informed-decision never calls create, entries or consume. The receipt has the same shape as today (memo_id, approval_id, approval_binding_digest).

After intake: the ledger records profile: present_existing and approval_requester: <actor>. The review then checks on every open and accept that the live object's actor equals that requester, and it passes approval_requester to access-engine as the attribute context. Accept posts the founder's entry with their own token, as today. The executor then GETs and consumes the approval itself.

Code: informed_decision/intake.py (PresentExisting, pinned validation), intake_service.py (registry profile, verify_existing, one approval per memo), intake_approval.py (IntakeApprovalReader, GET-only), requester.py (read-scoped exchange, compose_intake wiring), store.py (recorded requester). Tests: tests/test_intake_present_existing.py (25 cases, one of them opt-in against approval-engine's real store with INFD_APPROVAL_ENGINE_SOURCE). Full suite: 676 passed, 83 skipped; with the real engine 735 passed, 24 skipped. Existing submitters behave exactly as before (asserted by test).

What still blocks live use (outside this repository)

1. access-engine policy. informed-decision.compact-sitting v13 hard-codes requester_ok if input.context.approval_requester == "informed-decision". A present-existing memo is therefore refused at review time with requester_mismatch, which fails closed, as it should. A new policy version must admit the (intake_submitter, approval_requester, memo_class) triple, here (nk-bind-executor, service:nk-bind-executor, bounded-execution), and should require aal2 for bounded-execution. This needs an access-engine/flex-auth owner change, followed by a pin update here.
2. KeyCape requester client scope. The intake-time GET needs approval:read on informed-decision-sitting-requester, which today holds only approval:create. Until key-cape grants it, the read exchange is refused and only present-existing submitters fail (503 approval_unreadable).
3. Deployment data and network. The registry row above, memo_class / submitter in the policy's admitted sets, a NetworkPolicy from sso/nk-bind-executor to the private workload listener (8081), and a projected token with audience informed-decision-intake on the executor Job. The founder runs these under the usual release.

Packet content (answer to review §6 Q2b)

The packet carries the admission YAML itself, not a digest plus link. A required highlight must point at the scope ceiling, the window, the budget and the revert. The view_hash covers what the founder was shown. A link would leave the shown content outside the evidence and outside informed-decision's custody, which the evidence model forbids for a binding memo. A later, optional check (WP-0010-T02) can require for bounded-execution that one packet item's digest equals target.admission_digest. This is open only because the admission digest's canonical form needs confirming with net-kingdom.

S4: C1 single-screen confirm

Accepted in principle, adapted. A C1 confirm is the memo model with less ceremony, not a second model:

• one question, one packet item, one required highlight, two to four options;
• fresh session (aal1, existing 900-second freshness);
• view_hash and disposition as today, and no approval-engine object;
• it resolves the hub decision it serves (S3).

This is what INTENT.md calls the lower depth levels (L1/L2). It is not built because three things must exist first:

1. gate-house doctrine for the C0–C3 classes and the rule that anything executed on the strength of a decision is C2 (review S5). informed-decision must not decide which class a decision has;
2. an access-engine policy action for a confirm without an approval object (today review refuses missing_act_binding);
3. a founder answer on whether C1 acceptances count as "binding" for N2 (workplan approvals, owner proposals).

S3: hub write-back

Accepted. It exists already: an intake envelope's serves: {hub_decision_id, resolves: on-answer} queues a resolution atomically with a terminal human disposition (accept or decline). The worker posts /decisions/{id}/resolve with decided_by: "<reviewer> via informed-decision" and a rationale naming the memo, the version, the approval, the binding digest, the view_hash and the disposition. Remaining work:

• the founder's decision to set INFD_HUB_WRITEBACK=1 in production (a release);
• with state-hub: structured fields (memo_id, approval_id, view_hash, evidence_ref) once state-hub has decision links (review §6 Q4), replacing the parse-the-rationale idempotency check;
• state-hub enforcing that a C1/C2 decision is resolved only by this write-back, not by text (state-hub owns that rule).

Open questions

1. Founder: are C0–C3 and "executed means C2" the right cut? This gates S4.
2. Founder: enable hub write-back in production now (S3)?
3. access-engine owner: policy version admitting present-existing requesters (blocker 1). Should aal2 be required per memo class in policy, or by approval-engine's required_assurance once APPROVAL-WP-0007-T01 enforces it?
4. key-cape owner: add approval:read to the sitting requester client (blocker 2), or register a separate read-only client.
5. approval-engine (review §6 Q3): a presentation_ref set at create would let the object point at its memo. informed-decision would welcome it, but it cannot be checked at intake because the memo does not exist yet. A post-accept back-link is a better shape, and it is approval-engine's call.
6. Multi-approver approvals (required_count > 1) are refused for now. Supporting them means one memo per approver against the same approval, which needs a deliberate change to "one approval, one memo".