# 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 | An offline intake service, schema-3 ledger, and durable outbox exist. Registries are empty and transports are injected. Listener deployment, workload custody, admission, and live rollout remain blocked. 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 | Owner review must decide accuracy/publication, class/group and the exact submission path. Drafting is already authorized; no human answer or owner assent has been fabricated. | Decision `d20a9750-2b29-534e-8227-fb866581a6ca`; 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 | Prior Grok routing retries timed out; actual compaction/harness proof, independent review, owner feedback and fleet reach remain unproven. | 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.

Current pilot **0.2.4** reviews the later published offline intake at
`15c330cc`, digest
`025aab4f38246219c924bc94954e70ea0e6e7f72bcaf8d4344cd599602d345c3`.
The decisions card now records the empty registries, the blocked live route,
and the refusal to retry a creating approval without a retained receipt.
The unsigned draft binds this digest and is unsubmitted. 0.2.3 Whitehat
library acceptance does not extend to this seal, and earlier provider reports
do not certify it.