emergent-security/docs/decision-runbook-integration.md
tegwick ee2e17a2d2 Reconcile published offline intake in knowledge 0.2.4
Informed Decision 15c330cc documents an offline intake service with empty
registries and no live listener. The decisions card carries those limits.
The unsigned draft binds the new digest and is not submitted.
EMERGENT-WP-0002 stays blocked.

Assistant: grok
Assistant-Session: 01a10286-9185-7bb2-b411-89cf6ab4c0c6
2026-10-03 20:14:41 +02:00

140 lines
9.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.