# Human decisions and guided procedures in Emergent Security Emergent Security teaches agents how to recognize a security situation and find its owner. **informed-decision** (the actual repository name is singular) makes a human's decision informed and attributable to a presentation. **runbook-tutorials** guides the procedure and records progress. Their records link together; none can replace another owner's authority. ```mermaid flowchart TD K[Emergent Security: scope, sources, owner routing] --> Q{Human decision required?} Q -->|Yes: prepare one question| M[informed-decision: draft, presentation, human disposition] Q -->|Existing delegation suffices| P[Effect owner: current prerequisites] M -->|Return or discuss| D[Revise draft; decision still unresolved] M -->|Decline| S[Stop or revise the proposed act] M -->|Accepted: verify exact approval object| A[approval-engine: approval facts and consumption] A --> P P --> E[access-engine: operational PDP decision] E --> R[Owning procedure via runbook-tutorials] R --> O[Owner performs separately authorized effect] O --> V[Owner verification and audit evidence] V --> K ``` This is a conceptual routing diagram, not an implemented orchestration service or mandatory temporal order between all owner calls. The PEP follows its current request, claim, consumption and effect contracts. Owner-attributed plan exceptions remain exactly scoped; this diagram does not invent a new gate. ## Ownership and evidence links | Record | Owner | Link retained by the handoff | What it cannot establish | | --- | --- | --- | --- | | Orientation receipt | emergent-security | Package version/digest, card, source status, resolved scope | Delegation, live readiness or permission | | Decision Memo / presentation | informed-decision | Memo ID/version, packet hashes, presentation `view_hash`, distinct `awareness_hash`, human disposition reference | PDP allow, approval consumption, verified mandate graph or root activation | | Approval object | approval-engine | Exact approval ID, binding digest, validity and consumption receipt where required | What the person was shown; automatic execution | | DecisionEnvelope | access-engine | Submitted request binding, current policy/facts, lifetime and owner verification | Reusable authority after changed scope/expiry | | Runbook pack/run | Procedure owner / runbook-tutorials engine | Owner path, pack digest, run ID, environment, gate/check evidence, deviations | Authenticated human approval or independent custody from a local checksum | | Effect and verification | Actual executor / effect owner | Decision and approval references, effect result, checks, rollback result | Success of unobserved effects | | Evidence / work tracking | audit-core / Statehub respectively | Custody receipt and live task/decision references | A missing event never happened; a work note is a runtime approval | Preserve original delegator, drafting agent, authenticated submitter, requester, represented principal, human reviewer and runtime actor as separate identities. Carry non-secret references between these records. Private packet contents stay in the owner's approved storage; they are not copied into the general knowledge package or a runbook capture. Do not join records by similar display names or substitute one digest for another. ## Delivered integration Release **0.2.0 (pilot)** adds `decisions` and `runbooks` cards, startup discovery, and revision-pinned owner contracts/code. There are 14 cards, 24 owners and 69 source files. This is file review, not live capability verification. Release **0.2.1**, which clarifies withdrawn-procedure refresh and missing-event reconciliation recipients after provider evaluation. The unsigned adoption draft always binds the current corrected release. Exact-release reports and remaining closure gates are indexed in `docs/evidence/2026-10-03-closure-attempt.md`. - `runbooks/security-orientation/pack.yaml` is a native v0.2 pack owned here. It resolves scope, prepares an unsigned question when needed, identifies the current owner procedure and records unresolved prerequisites. All steps are manual-only; no step or verification shell commands exist. A completed run means preparation only. It does not mean a human answered or any effect ran. - `docs/decisions/profile-adoption-intake.draft.json` is a concrete **unsigned, unsubmitted** owner-format draft for the existing adoption decision. It asks only about this exact knowledge profile. Its `serves.resolves` is `never`, so it cannot automatically close the broader owner-adoption decision. - `tools/build_adoption_draft.py --check` binds that draft to the current knowledge release and packet content. Rebuild after a release change and review again. The proposed `knowledge-profile` class and `net-kingdom-admins` group are not claimed as an admitted submitter route. Tests use a synthetic grant only, and separately demonstrate refusal without admission. - Eight additional provider scenarios distinguish drafting/binding, current intake readiness, the different hashes, auto-confirm, waivers, seals, pack ownership, and returned decisions. Existing pilot pointers load the shared package, so no repeated edits to their agent instructions are required. Previous 0.1.1 provider evidence remains historical; it is not silently relabeled as evidence for 0.2.0. ## Current limits and concrete owner dependencies | Dependency | Current evidence and next step | Live work record | | --- | --- | --- | | Automated memo submission | Informed Decision `b4f6373` records local intake delivery: empty registries, notification without a URL, posed evidence, and write-back default off. state-hub `d61ba32` preserves `requires_new_bind`, `required_ack`, and `sealed` in the dev fixture. No live submitter is registered and `INFD_HUB_WRITEBACK` stays unset. audit-core `70e4044` registers `informed-decision.memo.posed` locally and is not deployed. access-engine `103d8b6` deploys compact-sitting v9. The v8 attribute branch still has empty admit sets, and one exact record admits the accepted profile memo. Listener deployment, workload custody, admission activation, and live rollout remain blocked. T08 still waits on the service account, grant, and T05/T06. A creating approval without a retained receipt is not retried. Keep the local draft ready and use the attended route when submission is authorized. Do not mint a submitter grant. | INFD-WP-0005 T05–T08 and T10; EMERGENT-WP-0002 T02/T09 | | Profile adoption | The founder accepted informed-decision memo `emergent-profile-adoption-0-2-6` at 2026-10-04T00:16:08Z as non-normative orientation of knowledge 0.2.6. Cross-owner ratification, publication, and class/group admission remain open. The hub decision stays unresolved because the packet resolves never. | Decision `d20a9750-2b29-534e-8227-fb866581a6ca`; `informed-decision/docs/evidence/2026-10-04-emergent-profile-acceptance.json`; EMERGENT-WP-0002 T02 | | Engine execution/index | Automatic step execution, estate index and inter-pack dependencies remain deliberately deferred. Use explicit owner pack paths. No need to implement these to use the preparation pack. | RBT-WP-0006; existing decision `1e517449-2114-4a8f-9c6b-fcdbe977378e` | | Runtime enforcement bridge | Pack actor/privilege/authorized_by fields and local waivers are not authenticated owner facts. No external approval/PDP gate plugin is claimed. Future execution requires an exact owner design, not a generic `approved: true` field. | EMERGENT-WP-0002 T06 mapping; RBT-WP-0006 T01/T06 | | Independent assurance and rollout | Codex, Claude, and Grok reloaded startup after resume on 0.2.4 and refused effect authority. Context compaction, governed harness proof, independent review, owner feedback, and fleet reach remain open. | EMERGENT-WP-0002 T05/T07/T08/T09/T10 | Informed Decision's SCOPE explicitly retains signature-attribution, presentation-to-entry correlation and commitment-only custody gaps. This integration preserves those limits. Runbook auto-confirm can execute checks and auto-confirm manual checks, although it never executes the step command. Generic waivers, overrides and push-through remain local engine features; they cannot satisfy an external human decision. A local seal is a recomputable checksum. ## Reproduce the offline checks With the reviewed owner checkouts next to this repository: ```bash PYTHONPATH=src python3 -m emergent_security.knowledge --repositories .. show decisions PYTHONPATH=src python3 -m emergent_security.knowledge --repositories .. show runbooks PYTHONPATH=../runbook-tutorials python3 -m rtut validate . EMERGENT_OWNER_ROOT=/home/worsch python3 -m pytest tests/test_owner_links.py -q python3 tools/build_adoption_draft.py --check ``` Set `EMERGENT_OWNER_ROOT` to the actual checkout parent on another machine. Tests load the real owner validators/engine, create run state only in temporary fixtures, and never call a live service. Owner-contract tests are explicitly skipped without the environment variable; ordinary package tests remain portable. To view the actual pack, use the owner's installed `rtut ui .` in this checkout. A UI session is not started or exposed by this integration. Authoritative references: the pinned `informed-decision` and `runbook-tutorials` entries in `knowledge/sources.yaml`; related contracts in `docs/operational-contracts.md` and owner map in `docs/netkingdom-integration-map.md`. Release **0.2.2** invalidates loaded knowledge after local release changes and serves the exact validated card bytes, addressing Whitehat findings WH-KNOW-001/002. The owner-reviewed Glas source correction preserves absent observed model metadata as unknown. Neither change resolves the existing human adoption or native continuity gates. Release **0.2.3** re-pins Informed Decision's inventoried workplan at `f0c60637`. That note recorded the unadmitted 0.2.2 route and did not change intake code. Release **0.2.4** reviews the later published offline intake at `15c330cc`, digest `025aab4f38246219c924bc94954e70ea0e6e7f72bcaf8d4344cd599602d345c3`. The decisions card recorded the empty registries, the blocked live route, and the refusal to retry a creating approval without a retained receipt. 0.2.3 Whitehat library acceptance does not extend to that seal. Fresh 0.2.4 provider probes are recorded in `docs/evidence/2026-10-03-024-provider-probes.md`. Earlier provider reports do not certify that seal. Release **0.2.5** re-pins Informed Decision at `b4f63732`, digest `9e186dbd6f2d5eb455bca24db4b03cd866c63c4e94660430dd15f2ca9856215f`. The decisions card records fresh-login/p01 acceptance, the open browser freshness error, empty registries, notification without a URL, local posed evidence, write-back left off, and boolean-preserving dev forwarding. T08 still waits on the service account and T05/T06. At that release, the unsigned draft bound this digest. 0.2.4 probes, resumes, and pilots do not certify that seal. No listener or submitter route is claimed. Current pilot **0.2.6**, digest `8d1d6a9d4d07fec7b619618de7dfe2be2254c1790f85f4198c7fe19db9751c02`, keeps the `b4f63732` pin. A provider switch or compaction reload goes to the session owner, and glas-harness owns that boundary. A live zone-endpoint question goes to zone-engine. The unsigned draft binds this digest and is unsubmitted. 0.2.4 route results do not certify this wording.