NK-WP-0056-T02: founder chose the executor runtime owner; owner requests sent

net-kingdom writes the executor, a new rapp-* package deploys it (hub
decision 6d1adce9). Requests to approval-engine, access-engine,
secrets-engine, railiance-platform, audit-core, glas-harness and
railiance-apps recorded with an answer table.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 994874@bnt-lap001
Assistant-Session: 6017c416-d619-47eb-bd1a-f670a02d7d87

docs/proposals/2026-10-31-nk56-t02-owner-requests.md

@@ -0,0 +1,93 @@
+# NK-WP-0056-T02: owner requests for the bounded executor (2026-10-31)
+
+Basis: Bounded Execution Admission v0.1, proposed (`canon/standards/bounded-execution-admission_v0.1.md`,
+net-kingdom `989d5d4`), and its examples in `examples/bounded-execution-admission/`. The first live use is
+NK-WP-0056-T06: unattended rotation of the `svc-authelia` directory bind, under one founder admission
+(`bind-rotation-svc-authelia.yaml`).
+
+**Founder decision 2026-10-31 (hub `6d1adce9`):**
+
+- net-kingdom writes the executor runtime: source and tests, next to the admission validator, the bind
+  lanes and the synthetic journey;
+- a new `rapp-*` package builds the image and deploys it in `sso` (ADR-0015);
+- glas-harness becomes the path for agent executors later (GLAS-WP-0018).
+
+Every answer below is the owner's agreement. Nothing here assigns work to another repository.
+
+| Component | Owner (hub agent) | Asked to carry | Answer |
+| --- | --- | --- | --- |
+| Admission carrier | approval-engine | The admission as a consumable approval | pending |
+| Admission as input claim | access-engine | Policy decision for executor operations under an admission | pending |
+| Executor credential lanes | secrets-engine | Lifecycle of the executor's OpenBao credentials | pending |
+| OpenBao roles and CCR types | railiance-platform | Kubernetes auth role and policies for the executor; CCR request types | pending |
+| Receipt holder | audit-core | Execution-attribution receipts from the executor | pending |
+| Agent executors | glas-harness | Session contract so a harness-launched agent can be an executor | pending |
+| Runtime package | railiance-apps | Where the new `rapp-*` package lives and who creates it | pending |
+
+## approval-engine
+
+1. **Binding.** Can an approval carry a `BoundedExecutionAdmission` with these fields?
+   - `action: bounded-execution`
+   - `actor`: the executor identity (pilot: `service:nk-bind-executor`)
+   - `principal`: the approver (`admin`)
+   - `purpose`: `spec.purpose`
+   - `target: {admission_id, admission_digest}`
+   - validity equal to `spec.window`
+
+   The plan, plan digest, budget and ceiling are inside the digested document, so `target` covers them.
+2. **Assurance.** How does an approval record that the approver acted at `aal2`? The standard requires
+   it (BEA-C4).
+3. **Consume.** The executor's service principal consumes once, before its first step. Which scope and
+   which `request_digest` does that take? Your contract notes that `consume` does not check digest
+   equivalence, so we plan an independent `GET /v1/approvals/{id}` comparison of
+   `target.admission_digest`. Is that the reading you intend?
+4. **Revocation.** Can the founder revoke an approval that has not been consumed? This would be the
+   kill switch before the start (T07).
+
+## access-engine
+
+1. Should a PDP decision gate executor operations? For example: "executor X may run operation O on
+   target T under admission A", with the admission read as an input claim through approval-engine.
+2. If yes, what is needed: a `bounded-execution` action, a policy pack and its owner, and the
+   `execution_contract` coverage that your current apply rules do not evaluate. What is the timeline?
+3. For the T06 pilot, is it acceptable that the executor enforces the ceiling locally (validator plus
+   a Kubernetes Role), with the PDP check added later?
+
+## secrets-engine
+
+1. The pilot executor needs these OpenBao capabilities, at most 15-minute TTL:
+   - write the next version of `platform/workloads/net-kingdom/directory-binds/svc-authelia` (CAS);
+   - read it and `.../synthetic-journey/syn-journey` for its checks.
+
+   Does secrets-engine orchestrate these lanes for an executor workload, as with other lifecycle lanes?
+2. To set `svc-authelia`'s password in LLDAP, the executor needs a directory credential. Would that be
+   a dedicated LLDAP account (no narrower group than `lldap_password_manager` exists) delivered as a
+   cataloged credential? Or do you see another lane shape?
+
+## railiance-platform
+
+1. A Kubernetes auth role for the executor's ServiceAccount in `sso`, with policies limited to the paths
+   above (as in CCR-2026-0052..0054). Which CCR request types: `workload-kv-read` for the journey
+   secrets (NK-WP-0056-T10), and a new KV-write-next-version type for the rotation?
+2. Receipt sender: per NK-WP-0040-T02, you register senders for audit-core. Can the executor pod receive
+   an ESO-projected sender bearer like other in-cluster senders?
+
+## audit-core
+
+1. Will you hold the executor's execution-attribution receipts (Playbook Capability Contract v0.2,
+   NK-WP-0040) as audit events from a registered in-cluster sender?
+2. The receipt adds per-step outcomes, check results, revert yes/no and budget used, and binds the
+   admission id, admission digest and approval reference in `decision_refs`. Does that fit your event
+   model, or should these be separate events correlated by `run_id`?
+
+## glas-harness
+
+1. GLAS-WP-0018 (session contract): when could a harness-launched agent present as `AGENT` with a
+   verifiable "harness-launched" assertion? The standard's BEA-4 requires it for agent executors.
+2. Not needed for the pilot. This asks whether glas-harness wants to own the agent-executor path later.
+
+## railiance-apps
+
+1. The executor needs a deployment package under ADR-0015 (working name `rapp-bounded-executor`):
+   an image built by Forgejo, and a Deployment or Job in `sso` with its own ServiceAccount. Who
+   creates the repository, and which conventions apply?