net-kingdom/canon/standards/bounded-execution-admission_v0.1.md

id	type	title	domain	status	version	owner	created	updated	last_reviewed	review_interval	scope	schema	validator	examples	related
netkingdom-bounded-execution-admission-v0.1	standard	NetKingdom Bounded Execution Admission v0.1	netkingdom	proposed	0.1	net-kingdom	2026-10-31	2026-10-31	2026-10-31	3m	accountable-automation	canon/schemas/bounded-execution-admission_v0.1.schema.json	tools/bounded-execution-admission/validate.py	examples/bounded-execution-admission/	canon/standards/service-identity-privilege_v0.1.md canon/standards/playbook-capability-contract_v0.2.md workplans/NK-WP-0056-bounded-executor-path.md workplans/NK-WP-0040-execution-attribution-receipt.md

NetKingdom Bounded Execution Admission v0.1

0. Status

Proposed (NK-WP-0056-T01). Nothing here is enforced by a running service yet. The executor runtime is T02/T03, budget and kill-switch enforcement is T07, and the first live use is the T06 pilot. A document that passes the validator is a well-formed request. It is an admission only together with a carrier record that a person approved (section 5).

1. Purpose

SI-15 names the golden path prepare → admit → execute → verify → retain, and allows "a bounded executor under the admission" at step 3. This standard defines what that admission is. The founder approves, at aal2:

• an exact plan, by digest;
• a validity window;
• a scope ceiling in SI MODE @ SCOPE terms;
• a blast-radius rule;
• a stop-and-revert policy tied to named machine checks;
• a risk class;
• an expense budget.

The executor consumes the admission once. Top-level decisions and guardrails stay with the person, and execution below them is delegated, bounded and reconstructable.

Out of scope: who runs the executor (T02), how a carrier stores approvals (Approval Engine owns that), and the receipt's emission and custody (NK-WP-0040-T02).

2. Vocabulary

Term	Meaning
Admission request	The immutable document defined here (BoundedExecutionAdmission), identified by spec.id and by its digest
Carrier	The system that records a person's approval of one request and its single consumption: Approval Engine, or a founder SSH signature (NK-WP-0049 practice)
Admission	A request plus a carrier record that passes BEA-C1..C7
Executor	The non-human identity that runs the plan: a WORKLOAD, SERVICE or harness-launched AGENT (SI-14)
Step class	delegable (the executor may run it under an admission), root-class (the founder admits each run; high risk only), human-intrinsic (never in an admission: for example a person's own password)
Check	A named, source-pinned machine check that must pass after a mutating step
Consumer	The unit the blast radius counts: a service whose behaviour a step can change

3. The admission request

A YAML or JSON document validated by canon/schemas/bounded-execution-admission_v0.1.schema.json:

Field	Meaning
spec.id, title, purpose, work_ref	Identity and intent. id is BEA-YYYY-NNNN
risk_class	low, medium or high. Bounds the window, the attempts, the ceiling and the step classes
window.not_before / not_after	When the admission can be consumed. At most 72 h (low), 24 h (medium) or 4 h (high)
approval	Who may approve (approvers, HUMAN, aal2) and through which carriers
executor	The executing identity, its principal type and runtime
scope_ceiling	Grants {mode, scope, environments} that bound every step. Scopes are /-separated paths, and a grant covers its own scope and anything below it
blast_radius	unit, the consumers the plan may touch, and max_concurrent
trust_requires	Playbook Capability Contract trust states the executor must find satisfied before the first step
plan.source	Repository, commit, and the sha256 of every file the run executes or checks with
plan.steps, plan.revert_steps	Ordered steps: operation, target, consumer, class, mutates, requires (the grant it needs), checks_after, revert or irreversible
plan_digest	sha256: over the canonical JSON of plan (sorted keys, no whitespace, UTF-8)
checks	Named checks: ref (a pinned file), sha256, timeout_seconds, optional settle_seconds, expect: pass
stop_and_revert	on_check_failure and on_budget_exhausted (revert or stop); on_unknown: stop; on_revert_failure: stop-and-alert
budget	wall_time_seconds, attempts, and cost (CPU seconds, egress bytes, currency, amount)
consumption	single_use: true, consume_before_first_step: true
receipt	The NK-WP-0040 execution-attribution receipt, where it goes, and that it is retained by hash with no secret values
not_authorized	What this admission explicitly does not cover

settle_seconds exists because of the T08 finding: privacyIDEA's resolver cache hides a broken bind for up to 120 s, so a check run sooner proves nothing.

4. Rules (validator: validate)

Rule	Requirement
BEA-1	The document matches the schema (HUMAN approvers at aal2, single use, on_unknown: stop)
BEA-2	plan_digest equals the digest of plan: the person admits exactly this plan
BEA-3	The window is positive and no longer than the risk class allows
BEA-4	The executor is not HUMAN and not an approver. An AGENT must be harness-launched (SI-14)
BEA-5	No SOVEREIGN or GOVERN in the ceiling. No CONSTRUCT in PRODUCTION. ADMINISTER needs max_concurrent: 1; at a whole-service scope (no /) it needs high risk and only root-class steps
BEA-6	Least privilege: every step and revert step is covered by a ceiling grant of the same mode, and every ceiling grant covers at least one step
BEA-7	No human-intrinsic step. A root-class step needs high risk
BEA-8	Every step's consumer is in the blast radius. medium and high risk change one consumer at a time
BEA-9	Every mutating step names checks, revert steps included: a revert must prove the restored state with its own checks. Every check is used and pinned: its ref and sha256 appear in plan.source.files
BEA-10	Every mutating step has a revert step, or is irreversible at high risk. Revert steps mutate and do not nest. Step ids are unique. The executor runs revert steps in their declared order (the recovery order: data, then delivery, then restart), limited to those whose forward step ran
BEA-11	A revertable plan reverts on check failure. A plan with nothing to revert stops
BEA-12	The wall time fits the window, the checks (timeouts plus settle times) fit the wall time, and attempts are at most 3 (1 at high risk)
BEA-13	The executed source is pinned by file and commit
BEA-14	No secret-shaped value anywhere in the document

Findings name the rule and a location, never a value.

5. Carrier and consumption (validator: check-approval)

A carrier record (netkingdom.io/bounded-execution-approval/v0.1) states the carrier, its approval reference, the admission id and digest, the approver (name, principal type, assurance), the approval time, and the consumptions.

The admission digest is sha256: over the canonical JSON of the whole request, including plan_digest. That digest is what a carrier binds.

Rule	Requirement
BEA-C1	The carrier is one the request allows, and the record has the expected shape
BEA-C2	The record names this admission's id and digest
BEA-C3	The approver is a listed HUMAN approver and not the executor
BEA-C4	The approval was made at aal2
BEA-C5	The approval was made before the window closed
BEA-C6	Consumed at most once
BEA-C7	The consumption happened in the window, after approval, by the executor identity

Approval Engine (preferred carrier). Approval Engine already stores an approval that binds action, actor, principal, purpose and target by digest, carries a validity window, and is consumed exactly once (POST /v1/approvals/{id}/consume), read back through GET /v1/approvals/{id}. The proposed mapping, which is for agreement with Approval Engine and Access under T02, not decided here:

• action: bounded-execution;
• actor: the executor identity;
• principal: the approver;
• purpose: spec.purpose;
• target: {admission_id, admission_digest};
• validity equal to window;
• the executor consumes before its first step (consume_before_first_step).

Approval Engine's own contract notes that consume does not check that the request digest is equivalent to the decision. An independent mediator must therefore fetch the approval and compare target.admission_digest itself. A consumed: true returned by the caller is not proof.

Founder SSH signature (transitional carrier). This is the NK-WP-0049 practice:

• the founder signs the canonical request with ssh-keygen -Y sign, namespace netkingdom-bounded-execution;
• the signature is verified against the repository's allowed_signers;
• aal2 is established by the signing key's custody, not by a token.

Single use is then only as strong as the executor's own consumption ledger. That is acceptable for the transition and is recorded as such in the receipt.

6. Mapping

SI-15 golden path.

Golden-path step	What it means here
Prepare	plan.source (source-reviewed, pinned files), tested on synthetic fixtures. For bind changes, NK-WP-0056-T08's synthetic stack
Admit	Carrier approval of the admission digest at aal2
Execute	The executor, inside scope_ceiling, blast_radius, window and budget, consuming once
Verify	The named checks during the run. Afterwards, an independent verifier checks the carrier record (BEA-C1..C7) and the receipt's source hashes
Retain	The receipt, kept by hash with no secret values

Playbook Capability Contract. trust_requires uses the contract's trust-state vocabulary. The executor refuses to start unless each state is satisfied, using the readiness checks of the capability declarations it runs. A step's operation should name a declared capability operation once Railiance declarations exist for it.

Execution-attribution receipt (Playbook Capability Contract v0.2, NK-WP-0040). One receipt per run:

Receipt field	Filled from
initiator	The carrier's approver (the founder). The person authorized the run; the executor ran it
delegation	Absent unless the approver acted through an agent
executing_workload, runtime_principal	executor.identity, executor.runtime
run_id	New per run
source_commit	plan.source.commit
artifact_digest	plan_digest
target, action	Per step
decision_refs	spec.id, the admission digest and the carrier's approval reference
time_interval	Measured

The receipt adds the outcome per step, check results, whether a revert ran, and the budget used. It never holds a secret value.

Founder decision 2026-10-31, agreed with audit-core (AUDIT-WP-0018):

• When the executor consumes the admission, before its first step, it emits a separate execution.run.started event, so a run that crashes before its receipt is still detectable.
• It then emits one execution.attribution.receipt per run:
  • target and action at the admission level (admission:<spec.id>, bounded-execution);
  • per-step detail in steps[];
  • decision_refs labelled admission, admission_digest and approval.
• Envelope ids are run:<run_id>:started and run:<run_id>:receipt.

Policy decision point. access-engine's gate (FLEX-WP-0040) has two decisions: start before consume, and execute-step after it. The T06 pilot runs without the gate: its receipt records the gate as not-evaluated and claims no allow. Any further admission needs the gate, or an exception the founder records (founder decision 2026-10-31).

Failure classes. A failed check, or an operation that reports a definite failure (for example a rollout that never becomes ready), reverts per on_check_failure. An error whose outcome is not established stops (on_unknown: stop) without reverting. Receipts name the error type, never its message.

Credentials during a run. Write roles exist only during the admitted window: the platform creates them when an admission is approved and deletes them after the receipt (CCR-2026-0058). A directory bind rotates its own password, so no password-manager account is needed (founder decisions 2026-10-31).

7. The bind split as admissions

NK-WP-0056 tagged each step of the 2026-10-30 LLDAP bind split. The examples express them:

Runbook step	Class	Example
2, 4, 10 (verify)	delegable, read-only	bind-split-read-only-verify.yaml: low risk, OBSERVE only, nothing to revert
3 create svc-* accounts	root-class	bind-split-create-service-accounts.yaml: high, whole-directory ADMINISTER (no narrower LLDAP grant, SI-X6), revert deletes what was created
5–8 switch one consumer	delegable	bind-rotation-svc-authelia.yaml: medium, one consumer, a synthetic-journey check after the restart, a revert per step. This is the T06 pilot shape
9 change LLDAP's super-admin	root-class	bind-split-switch-super-admin.yaml: high, one attempt, settle_seconds: 125 on the journey check (privacyIDEA cache)
10 admin's own password; seal ld-admin	human-intrinsic	Refused: tools/bounded-execution-admission/fixtures/invalid/human-intrinsic-step.yaml (BEA-7)

The examples are illustrative. They pin real files at a real commit, but the executor and its operations do not exist yet.

8. Conformance

make bounded-execution-admission-test     # validator tests
make bounded-execution-admission-check    # validate the examples
python3 tools/bounded-execution-admission/validate.py check-approval <admission> <carrier-record>
python3 tools/bounded-execution-admission/validate.py digest <admission>

Agents may run these: they are offline and read-only. Writing an admission is preparation, and approving one is the founder's act.

9. Open items

• T02: the carrier mapping with Approval Engine and Access (action name, actor and representation, digest equivalence, consume scope for the executor), and the executor runtime owner.
• T03: the executor identity and its grants, matching the ceilings in the examples.
• T07: enforcement of budget and attempts at run time, the founder's kill switch, and aggregate review through posture feedback (NK-WP-0031).
• NK-WP-0040-T02: receipt emission, custody and schema in audit-core.
• Recurring admissions (one approval for repeated runs of the same plan) are deliberately excluded from v0.1: every admission is single use.