approval-engine/docs/decision-services-alignment-answer.md

Decision services alignment — Approval Engine owner answer

Status: owner answer to the NetKingdom review net-kingdom/docs/proposals/2026-10-31-decision-services-alignment-review.md (hub message 81cafbf3-8d54-44c6-9235-6f46e95aaf74), 2026-10-31. Also answers the pod-scoped ingress request (hub 39a3bffa-2c7c-4ca6-8a57-61e4ed94820f). This is an engine-owner technical position, not a founder decision. Nothing here is deployed.

Summary

Item	Position
Roles (§4.1)	Accepted. No change of role is needed here
Present an existing approval (§4.2)	Works on today's API. Step 3 needs only GET /v1/approvals/{id} with approval:read
S6 / T01 aal2 floor	Implemented in source (schema v7). Not yet released or deployed
S6 / T02 actor_consumes	Supported, still waiting. Owner proposes splitting it from principal_approves
§6.3 presentation_ref at create	Declined as proposed. Counter-proposal: the link goes on the entry, from the presenter
Executor ingress	Prepared in source: deploy/networkpolicies.yaml, policy approval-engine-bounded-executor. Live apply is founder-run

1. Roles

The proposal matches this engine's INTENT and SCOPE:

• The engine keeps the object: binding, entries, consume, supersede, revoke and outbox evidence.
• Only the actor creates. POST /v1/approvals already refuses unless binding.actor equals the token subject. informed-decision stays a legitimate actor for approvals it uses itself.
• The engine stays not-an-inbox: get by id, no list and no notification. Discovery belongs to State Hub (the index) and informed-decision (the surface).

For the §4.2 verify step, informed-decision reads everything it needs from one GET: status, entries, binding.human_control, binding.actor and binding.digest. It should also check binding.required_assurance (T01, once deployed) when a C2 class requires aal2. With human_control: true, the engine already refuses an entry posted under informed-decision's own service token. The founder's entry must carry the founder's token, as it does today.

One addition to §4.2 step 3: compare validity as well, so a memo cannot present an approval whose window has already passed or is far wider than the packet says.

2. S6

T01 (aal2 floor): done in source.

• POST /v1/approvals accepts an optional required_assurance: {"level": "aal1"|"aal2"|"aal3"}.
• POST /entries refuses a weaker, missing or unknown level from the verified token.
• The claim reports assurance_unsatisfied, and consume refuses a persisted entry below the floor.
• The floor is inherited on supersession and is not part of the act digest.
• Legacy rows migrate to NULL, meaning no floor.

The member appears in GET and the claim only when declared. The access fact reader rejects unknown members, so undeclared claims keep their exact bytes. Contract: docs/approval-claim.md. It needs a v7 image release and a founder-run rollout with a verified pre-v7 backup. Until then the executor keeps its own aal2 check. Whether KeyCape issues aal2 stays KeyCape's question.

T02 (correspondence): supported, not implemented. The owner proposes splitting it:

• actor_consumes (consumer subject must equal binding.actor). It is low-risk and closes the denial-of-run gap: today any tenant service holding approval:consume can spend the object. It adds no new identity mapping, because the actor is already pinned to the creator's token subject. The owner is ready to implement it as an opt-in issue flag once Gate House (or the founder) agrees that actor means "the only consumer" when the flag is set.
• principal_approves (entry subject must equal binding.principal). It stays waiting. NetKingdom's principal labels (for example admin) must first equal KeyCape subjects exactly, and C2 doctrine (S5) may name approvers that are not the principal.

3. Open question 6.3 — presentation_ref at create

Declined as proposed, for three reasons:

1. Ordering. In §4.2 the actor creates the approval before it submits the memo, so no memo id exists at create. Setting the field later would make the object mutable outside its state machine. The binding is immutable by design.
2. Wrong asserter. A reference set by the actor is the actor's claim about where it will be presented. The evidence that matters is what the approver was shown, and only the presenting surface can state that.
3. The join already exists in one direction. The memo carries approval_id and the binding digest (§4.2 step 2), and audit-core can join on (approval_id, subject, approved_at).

Counter-proposal (needs informed-decision agreement; not implemented): an optional entry-level presentation record. The approving surface posts it with the entry, for example {"memo_id", "revision", "view_hash"}. The engine stores it on that entry, serves it in GET and emits it in the issuance and use threshold evidence. It is labelled surface-asserted: the engine checks its shape, not its truth. Identity, principal type and assurance still come only from the token. This closes Finding 5 (view_hash not inside the entry) without changing creation. If agreed, it becomes a new APPROVAL-WP-0007 task.

4. Executor ingress

approval-engine-bounded-executor admits TCP 8080 to the approval-engine pod from pods labelled app.kubernetes.io/name=bounded-executor in namespace sso. The rule needs both selectors to match: they sit in one from element. It does not label sso and does not change approval-engine-callers. tests/test_networkpolicies.py holds that shape, so a split into two peers, which would admit all of sso, fails the test. Network admission grants no authority: the executor still needs its KeyCape token and scopes. To apply (founder-run):

kubectl apply -f deploy/networkpolicies.yaml

Founder decisions needed

1. Release and roll out the v7 image (T01) when the pilot needs the engine-side floor.
2. Agree the T02 split, and that actor_consumes may be implemented now.
3. Accept or decline the entry-level presentation counter-proposal (with informed-decision).
4. Apply the executor ingress policy.