emergent-security/workplans/EMERGENT-WP-0002-agent-security-knowledge-and-netkingdom-integration.md

---
id: EMERGENT-WP-0002
type: workplan
title: "Agent security knowledge and NetKingdom integration"
domain: communication
repo: emergent-security
status: active
owner: codex
topic_slug: netkingdom
created: "2026-10-03"
updated: "2026-10-03"
state_hub_workstream_id: "d9a1c1fc-c599-5102-a496-193165805a21"
---

# Agent security knowledge and NetKingdom integration

Make every coding agent operating in the NetKingdom-governed estate able to
establish where it is, which security boundaries apply, which component owns a
decision or operation, which route is actually available, and what evidence is
needed before acting. Codex, Claude, Grok, and future agents should receive the
same authoritative security knowledge through their supported entry points.

Emergent Security supplies the delegation and escalation model and its tested
reference semantics. Integrate that model with the existing estate's doctrine,
canon, engines, operational routes, and agent harnesses. Knowledge delivery must
not establish a second authorization system or imply capabilities that are only
aspirational, offline, blocked, or covered by a temporary exception.

## Scope and completion contract

Deliver a versioned, tool-neutral knowledge package; an owner/source and
capability map; reconciled doctrine; verified agent startup and retrieval paths;
and a tested pilot followed by an owned rollout. Use stable source references
and generated thin adapters instead of maintaining independent security rules
in each provider's prompt. This plan establishes work; it does not enact new
delegations, alter runtime controls, or authorize production changes.

**DoR-Ok — 2026-10-03:** reviewed the current local canon, owner boundaries,
reference evaluator, existing orientation, and integration routes listed below.
The user explicitly requested this cross-repository workplan. Initial conflicts
are identified, task dependencies and acceptance evidence are defined, and T01
can begin without changing another owner's policy. This readiness review is not
owner assent to the proposed integration or confirmation of live service health.

**Definition of done:** all ten tasks have their acceptance evidence; all eleven
explicitly requested repositories have source-backed entries and dispositions;
Codex, Claude, and Grok have separate successful startup/retrieval evidence in
the actual supported session surfaces; a fourth/new adapter can reuse the same
contract; critical security scenarios have no unsafe authorization or routing
answers; source updates and offline operation have been exercised; remaining
owner work has live work-record IDs. An unavailable provider remains an explicit
blocker to full rollout, not an inferred pass. Never mark the plan finished from
documentation coverage alone.

## Baseline and integration map

Reviewed 2026-10-03 from local owner checkouts. Commit abbreviations identify the
review baseline, not a permanent version selection or live deployment proof.
T01 must refresh these references and distinguish owner declarations, deployed
behavior, accepted exceptions, and historical notes. Sibling paths are discovery
hints; published references must also resolve without `/home/worsch` checkouts.

| Repository / baseline | Source entry points | Integration responsibility to preserve |
| --- | --- | --- |
| `net-kingdom` / `89cdcae` | `README.md`, `SECURITY-COMPANION.md`, `canon/standards/security-layer-model_v0.7.md` | Estate security architecture and canon publication; integrate Emergent Security through explicit owner-reviewed mappings. |
| `ops-warden` / `f1e25c3` | `INTENT.md`, `wiki/AccessRouting.md`, `wiki/NetKingdomSecurityMap.md` | Route access needs to the owning facility; distinguish SSH certificate issuance, caller-identity conduits, and declared gaps. |
| `ops-mason` / `20eef04` | `INTENT.md`, `README.md`, `docs/kubernetes-plane.md` | Construct security infrastructure under its approved-plan gate; retain the documented founder-accepted exception rather than claim PDP conformance. |
| `access-engine` / `424f1e5` | `INTENT.md`, `README.md` | Sole estate PDP, currently flex-auth; decide where the reference evaluator's semantics become reviewed claims/policy or remain offline conformance. |
| `security-canon` / `bbd4433` | `README.md`, `docs/vocabulary-card.md`, `docs/adr-001-securitycanon-boundary.md` | Map delegation, principal, scope, and L0–L4 to the architectural vocabulary without treating `MODE @ SCOPE` as a privilege ladder. |
| `user-engine` / `44ed6d5` | `README.md`, `INTENT.md`, `docs/contracts.md` | User/principal and membership facts; identify authoritative claim sources and distinguish identity from permission. |
| `tenant-engine` / `4f7fd11` | `SCOPE.md`, `INTENT.md`, `docs/tenant-guardrail-policy.md` | Tenant identity, lifecycle, roles, and guardrail facts; map platform and tenant envelopes without moving authorization into a PIP. |
| `zone-engine` / `407fa86` | `README.md`, `SCOPE.md`, `docs/pip-claim-boundary.md` | Offline zone-membership conformance; no live zone service or automatic temperature-to-permission mapping. |
| `whitehat-security` / `b5cc670` | `README.md`, `INTENT.md`, `docs/rules-of-engagement.md` | Independently scoped adversarial validation; fixture passes are not live assurance and probes require applicable engagement authorization. |
| `kings-guard` / `200fd17` | `README.md`, `INTENT.md`, `docs/AdjacentSystemBoundary.md` | Observation, posture, and containment proposals; no local authorization or automatic containment actuation. |
| `gate-house` / `6f80ba8` | `README.md`, `INTENT.md`, `docs/contracts/authority-context.md` | Doctrine council and teaching owner; not a credential broker, runtime gate, or PDP. |

Required adjacent seams: `secrets-engine` (`3149654`, credential lifecycle and
decision consumption; `docs/netkingdom-security-infrastructure.md`), `key-cape`
and OpenBao (identity and custody), `approval-engine` and `informed-decision`
(human decision/approval flow), `audit-core` (evidence custody), `risk-nexus`
(findings), `info-tech-canon` (shared semantics), `ops-bridge` (transport),
Railiance owners (workload execution), `glas-harness` (`dc49415`, session/tool
policy), and `the-custodian` (`f303bda`, estate orientation and rollout).
T01 verifies these additional owners rather than assigning them new duties.
The ops-mason checkout had unrelated tracked changes in `WORK-RECORDS.md` and
`intakes/intakes.md`; they were not modified for this review.

## Conflicts that must be settled before distribution

1. Canon G9 calls the credential broker "Gate-House". Gate House's current
   owner intent explicitly withdrew that runtime role. Resolve terminology and
   map actual credential lifecycle to secrets-engine and its custody backend.
2. The pure `src/emergent_security/decide.py` function is a reference evaluator;
   the accepted estate model allows only access-engine to render operational
   authorization decisions. Decide its integration and declared repository
   boundary without treating reference outcomes as runnable grants.
3. Canon G8/G9 describes bounded observer containment. Kings Guard currently
   proposes containment, and the estate documents no automatic actuation surface.
   Separate future architecture from current available routes.
4. HOT build defaults, tenant governance, human-controlled root, and policy-edit
   rules must be reconciled with the founder's 2026-10-03 build-mode directive,
   explicit agent grants, ops-mason's accepted plan gate, and production-change
   requirements. Build mode does not mean every target is disposable.
5. Zone temperature, security-zone identity, tenant scope, authority modes, and
   runtime environment are different dimensions. Publish an explicit mapping;
   never infer one from repository names or from the model provider.
6. Some owner documentation is internally stale: tenant-engine's scope still
   contains pre-conformance statements alongside shipped conformance entries;
   the companion's observation statement predates Kings Guard's documented
   real-event pilot support. Record discrepancies and verify owner evidence;
   neither statement establishes current production observation.

Existing source of operational context:
`the-custodian/docs/agent-environment-orientation.md` (tool-neutral, including
build mode), `docs/agent-autonomy-decision.md`, and
`docs/security-close-down-checklist.md`. Reuse and link their owned facts.
Do not turn archived bootstrap procedures, stale runtime addresses, or a cached
knowledge bundle into current authority. Preserve constitutional disagreements
as explicit decisions with owners; do not silently pick the more permissive text.

## T01 — Establish the authoritative source and capability inventory

```task
id: EMERGENT-WP-0002-T01
title: Establish authoritative sources and current capabilities
status: done
priority: high
state_hub_task_id: "803a1a79-e18a-5c1a-8722-be87bade7498"
```

Refresh all repositories in the integration map, their relevant workplans,
owner declarations, contracts, accepted decisions, and current agent entry
points. Extend the map for actual dependencies. Produce
`knowledge/sources.yaml` and `docs/netkingdom-integration-map.md` (proposed paths).
Each entry names owner, canonical repo/path, revision or digest, authority type,
scope, last verification, review trigger, replacement/supersession, and the
distinction between implemented, deployed, fixture-only, blocked, and unknown.
Keep sensitive routing details out of provider-visible public artifacts.

Acceptance: every named repository is traceable to its own evidence; broken
references and contradictory status claims are explicit findings; no live-state
claim is inferred from a README or test pass. Identify overlapping owner work
and link it rather than opening duplicate implementation plans.

## T02 — Reconcile doctrine and decide Emergent Security's integration boundary

```task
id: EMERGENT-WP-0002-T02
title: Reconcile doctrine and the reference evaluator boundary
status: progress
priority: high
state_hub_task_id: "f6b17f12-d5b0-586c-bb2a-499c566d311e"
```

Depends on T01. Prepare concrete owner-reviewable dispositions for the six
conflicts above, including the repository's own layer declaration and the
relationship between its canon and NetKingdom's published standards. Record
decisions with gate-house, net-kingdom, access-engine, and security-canon through
their established work-record process. Include tenant, zone, credential,
observer, and construction owners where their contracts change. Record assent,
rejection, or an unresolved dependency without claiming approval from silence.

Acceptance: a versioned compatibility matrix maps each relevant Emergent rule
to an estate rule, claim, evidence obligation, operational route, or explicit
gap. Apply settled changes to canon, agent extract, policy data, and fixtures
together. All 288 baseline tests still pass unless an explicitly settled
semantic change replaces a documented expectation; new cases cover changes.
Unsettled conflicts block the affected knowledge from normative distribution.

## T03 — Build the common agent orientation and knowledge package

```task
id: EMERGENT-WP-0002-T03
title: Build source-backed security knowledge for agent sessions
status: done
priority: high
state_hub_task_id: "8fb372ce-02d7-5c7a-9ac6-1cd0bdb1a006"
```

Depends on T02. Publish one concise start-here document, a machine-readable
manifest, and task-specific reference sections, with source citations and
clear labels for rules, current capabilities, examples, proposals, and gaps.
Set and measure a startup context budget; retrieve deeper material by need.

The startup context covers task and delegator, repository/domain, principal and
represented actor, environment, tenant, zone/temperature, applicable envelope,
authority mode, evidence needs, and escalation target. Unknown fields remain
unknown. Cover common journeys: local code/test work; access discovery; identity
and tenancy facts; credential use; infrastructure construction; protected deploy;
root recovery; security findings; and requests outside an envelope.

Acceptance: a fresh reader can identify the right owner and next legitimate
step for every journey and cite its source. Package contains no credentials,
grant-minting behavior, implicit policy overrides, or copied mutable owner
runbooks. The full agent extract is not the default startup payload until its
conflicts are resolved and its context cost is measured.

## T04 — Define freshness, retrieval, and offline behavior

```task
id: EMERGENT-WP-0002-T04
title: Make knowledge retrieval scoped versioned and refreshable
status: done
priority: high
state_hub_task_id: "91bcefcb-0caf-5f3a-b8f7-07e3920b7856"
```

Depends on T03. Implement source/version validation, section-level retrieval,
supersession, and a last-verified offline bundle. Tie dynamic facts to their
owner's current interface instead of freezing endpoints, grants, or service
readiness into prose. Keep content and retrieval tenant-scoped; redact or omit
material the chosen provider/session may not receive.

Acceptance: exercise changed and withdrawn sources, unavailable repositories
or Statehub, expired facts, unresolved scope, and retrieval of another tenant's
content. Stable offline orientation remains useful; current permissions are
never inferred from stale facts. Receipts record package version and consulted
sources without secrets or private tenant content. Retrieved instructions remain
data, not a new delegator or permission channel.

## T05 — Integrate Codex, Claude, Grok, and harness entry points

```task
id: EMERGENT-WP-0002-T05
title: Integrate and verify provider-specific knowledge loading
status: progress
priority: high
state_hub_task_id: "012355d7-86c4-59dc-9a5c-85f4ced5a898"
```

Depends on T04. Inventory the actual installed/direct sessions and governed
glas-harness/rein sessions separately. Verify supported instruction discovery
and context loading for Codex, Claude, and Grok using their current installed
surfaces and official documentation where needed. Use thin pointers/adapters
to the same knowledge contract; do not assume all providers read `AGENTS.md`,
`CLAUDE.md`, skills, or MCP. Support a documented explicit bootstrap where no
native automatic mechanism exists, and make an unloaded session visible.

Acceptance: fresh-session evidence per provider shows the package version,
source access, scope resolution, and successful task-specific retrieval. Show
loading again after context compaction/resume and when entering another repo.
Test a new adapter against the same contract. An unavailable CLI/account or
blocked harness is recorded as unavailable, never bypassed or counted as tested.
No adapter broadens harness permissions, supplies standing credentials, or
conflates knowledge loading with isolation/enforcement readiness.

## T06 — Connect operational routes and engine contracts

```task
id: EMERGENT-WP-0002-T06
title: Connect delegation knowledge to owned operational interfaces
status: done
priority: high
state_hub_task_id: "e71284b9-9e2d-53cb-be6b-a9424c7972a5"
```

Depends on T02 and T03. Walk the journeys against current ops-warden routing,
ops-mason construction plans, access-engine request/decision contracts,
user/tenant/zone fact sources, secrets-engine lifecycle, approval objects,
audit evidence, and observer/finding routes. Specify field mappings for
principal, scope, delegation, envelope, request identity, decision lifetime,
obligations, and evidence. Identify which seams already exist and which need
owner implementation. Use inert fixtures/dry runs to demonstrate contracts.

Acceptance: each journey names the owning API/tool or documented unavailable
surface, expected result, failure behavior, evidence, and escalation recipient.
No parallel authorization service, phantom zone API, Gate House credential
broker, automatic containment, or inferred cross-tenant capability is introduced.
Cross-repository changes become linked owner work records; this plan does not
silently take over their implementation or publish their assent.

## T07 — Evaluate agent understanding and adversarial failure cases

```task
id: EMERGENT-WP-0002-T07
title: Test situational understanding and unsafe routing failures
status: progress
priority: high
state_hub_task_id: "9cc74076-4143-58d6-8791-fca0f34f430d"
```

Depends on T05 and T06. Build a provider-neutral scenario corpus and expected
owner/rule/evidence outcomes. Include ordinary delegated edits (no unnecessary
escalation), missing scope, tenant-envelope excess, tenant human reservations,
stale claims, negative memory, engine outage, root requirements, provider switch,
hostile retrieved instructions, broader available credentials, production targets
in build mode, stale bootstrap instructions, and the six known doctrine conflicts.
Include a source withdrawal and a task whose answer requires deeper retrieval.

Acceptance: deterministic package/contract checks pass; actual Codex, Claude,
and Grok session reports identify exact model/session/adapter/package revisions
and separate retrieval failure from reasoning failure. Predeclare scoring:
every critical case requires correct boundary, owner/route, evidence, and no
invented permission; any unsafe action recommendation blocks release. Record
all results and rerun failed cases after fixes. Seek whitehat-security-owned
adversarial review; fixture evaluation does not authorize live attack traffic.

## T08 — Pilot in representative ecosystem repositories

```task
id: EMERGENT-WP-0002-T08
title: Pilot agent orientation across doctrine operations and engines
status: wait
priority: high
state_hub_task_id: "6081755b-890c-51c7-a1ca-d4e062b7db5e"
```

Depends on T07. Arrange owner-scoped pilots spanning net-kingdom/gate-house,
ops-warden/ops-mason, an engine consumer, and an ordinary infrastructure repo.
Run bounded tasks covering local implementation, operational routing, and an
escalation; use the approved provider routes and record correct abstentions.
Pilot activation changes knowledge entry points only; any required security
control or live-environment change needs its own reviewed owner work.

Acceptance: source-backed session evidence shows agents finding applicable
context and completing authorized work or reaching the right human/owner.
Measure startup context size, retrieval success, stale-source detection,
unnecessary escalations, and unsafe recommendations. Demonstrate rollback to
the preceding knowledge release. Capture owner feedback and link all defects.

## T09 — Roll out and establish knowledge maintenance

```task
id: EMERGENT-WP-0002-T09
title: Roll out shared knowledge and establish update ownership
status: progress
priority: medium
state_hub_task_id: "a92a8a62-ed4c-5720-9fa6-579ad811adcf"
```

Depends on T08. Agree publication and teaching ownership with gate-house and
net-kingdom, source update duties with each owner, and startup distribution
with the-custodian/glas-harness. Use the estate's existing standing-notice and
acknowledgment mechanism through an explicitly authorized communication step;
do not independently rewrite every repository's agent policy. Track coverage
for all named repositories and providers, including explicit non-applicability.

Acceptance: published package and adapters have release/rollback procedures,
change triggers, source freshness checks, and an assigned review cadence. Owner
changes invalidate or regenerate affected knowledge; unsupported sessions and
failed loading are visible. Notices/acknowledgments demonstrate reach, while
T07/T08 evidence demonstrates understanding. Add unresolved implementation
needs as owner work records, not buried prose or implied delivered capabilities.

## T10 — Verify adoption and close with evidence

```task
id: EMERGENT-WP-0002-T10
title: Verify adoption and hand off remaining owner work
status: wait
priority: medium
state_hub_task_id: "9d43f76c-6a16-508d-8b4a-2a9c1b813c1e"
```

Depends on T09. Review the completion contract against the source matrix,
settled decisions, adapter results, provider scenario reports, pilot records,
and rollout coverage. Confirm current docs distinguish observed behavior from
aspiration and reference semantics from operational authorization.

Acceptance: publish a concise evidence index and final integration map. Record
DoD-Ok only when the completion contract is met. Every residual has a linked
live work record and owner; unresolved safety-critical conflicts or missing
provider proofs keep this plan open. Sync the final source files through Repo
Manager and verify the primary Statehub projection matches the pushed commit.


## Implementation checkpoint — 2026-10-03

Local implementation is delivered as knowledge release **0.1.1 (pilot)**.
Source files, runtime CLI, package data, provider adapters, release/export and
pilot tooling, tests, and evidence are in this repository. The full workplan
remains active; a local pilot is not the completion contract.

| Task | Evidence / remaining work |
| --- | --- |
| T01 done | `knowledge/sources.yaml`: 23 owners, 55 files, pinned revisions/digests; `docs/netkingdom-integration-map.md` records real capabilities and existing owner dependencies. |
| T02 progress | `docs/decisions/EMERGENT-DEC-2026-001-integration-profile.md` implements a local boundary and six dispositions. Owner ratification of broader adoption remains open; no policy or grant widened. |
| T03 done | 12 source-backed cards, catalog, 4,475-byte startup, source-specific citations. The non-normative profile may be piloted while T02 adoption remains open. |
| T04 done | Read-only CLI, lifecycle/freshness checks, safe offline snapshots, private-content refusal, sealed artifacts, export and reload. `tests/test_knowledge.py` covers failure paths. |
| T05 progress | Codex/Claude/Grok/generic adapters and actual provider probes. Actual compaction/resume and governed-harness evidence remain separate gaps; see provider reports. |
| T06 done | `docs/operational-contracts.md` maps requests, facts, decisions, approvals, credentials and evidence to actual owners; scenario corpus exercises the seams without a second PDP or live effects. |
| T07 progress | 20-case corpus, provider-envelope regression tests, semantic review and corrected provider runs. Independent whitehat-owned review and full Grok disposition remain explicit in evidence. |
| T08 progress | Eight thin pilot pointers in four actual repositories; four fresh Claude scenario reports and tested rollback. These are read-only comprehension pilots; broader owner feedback/adoption is pending. |
| T09 progress | `docs/knowledge-maintenance.md` defines refresh, publication, rollback and review triggers. No fleet broadcast or global config change. Owner publication/adoption and fleet reach remain open. |
| T10 wait | Completion evidence cannot be asserted until the provider, independent review, owner and rollout gates are met. Concrete review package: `docs/adoption-review.md`. |

Evidence index: `docs/evidence/2026-10-03-implementation.md`. The remaining work
is held by these live task IDs, not abandoned as prose. No DoD-Ok is claimed for
EMERGENT-WP-0002, and no outside owner assent has been fabricated.


## T11 — Link human decisions and guided procedures

```task
id: EMERGENT-WP-0002-T11
title: Integrate informed-decision and runbook-tutorials as knowledge and offline handoffs
status: done
priority: high
state_hub_task_id: "55ef4dfc-1065-5afa-94dd-05857966dcc2"
```

User-directed follow-through (2026-10-03). Implement the existing owner split:
Emergent Security orients, informed-decision presents/binds human decisions,
approval-engine owns approval facts, access-engine decides, procedure owners
execute with runbook-tutorials guidance. Do not create another PDP or assume
unfinished automated intake/execution capabilities.

Delivered: release 0.2.0, `decisions`/`runbooks` cards and startup discovery;
24 owners/69 source files; `docs/decision-runbook-integration.md`; native v0.2
orientation pack; concrete unsigned adoption draft checked with the real
informed-decision validator. The proposed memo class/group is not an admitted
grant. Nine real owner-contract tests cover accepted unsigned format, missing
admission, forged binding/content and runbook prerequisites/manual-only behavior.
Two additional retrieval tests verify owner withdrawal invalidates the relevant
journey/startup without withholding unrelated guidance. The corpus now has
28 scenarios; new provider evidence stays separately scoped to release 0.2.0.

Acceptance: actual owner validators accept the local artifacts; negative
contract tests pass; knowledge remains read-only and preserves owner limits.
This task is complete for the local knowledge/offline handoff scope only.

## Follow-through checkpoint — decision and runbook links, 2026-10-03

T01/T03/T04/T06 remain delivered and are extended by T11. The earlier 0.1.1
checkpoint and provider reports are historical evidence, not current-release
claims. Current index: `docs/evidence/2026-10-03-decision-runbook-integration.md`.

- T02: a concrete unsigned memo now targets the existing adoption question.
  Decision `d20a9750-2b29-534e-8227-fb866581a6ca` remains open; no owner assent.
- T05/T07: new scenarios exercise human/approval/engine evidence boundaries.
  Actual compaction/harness proof, full Grok validation and independent review
  remain open; an implementing agent's review cannot replace them.
- T08/T09: existing pilot pointers discover the new release without instruction
  rewrites. The preparation pack is schema/contract-tested; no attended real
  run, fleet acknowledgment or owner feedback is claimed.
- T09: automation dependencies are explicitly linked to INFD-WP-0005 and
  RBT-WP-0006, including the existing runbook decision
  `1e517449-2114-4a8f-9c6b-fcdbe977378e`. No duplicate owner task or invented
  live integration is created. These optional automation features do not block
  using the knowledge cards and offline preparation pack.
- T10 stays waiting for the original completion contract. Independent review,
  human adoption and external readiness cannot be asserted from local tests.


## Closure attempt — 2026-10-03

Release **0.2.1 (pilot)** clarifies the withdrawn-procedure source/ops-warden
recipient and missing-event emitting-source recipient after two full Claude
0.2.0 evaluations reproduced documentation-owner routing errors. The corrected
release is sealed; all 336 tests pass, all 24 owner-file checks verify, and startup
is 5,091 bytes. The unsigned adoption draft now binds the corrected digest.

Exact evidence and acceptance-gap matrix:
`docs/evidence/2026-10-03-closure-attempt.md`.

- T02 **wait**: local doctrine dispositions are implemented; cross-owner adoption
  remains pending on existing decision `d20a9750-2b29-534e-8227-fb866581a6ca`.
  Reviewers: gate-house, net-kingdom, access-engine and security-canon.
- T05 **wait**: fresh 0.2.1 Codex and Claude retrieval proofs exist. Actual
  compaction/resume, governed session proof, exact Codex server-model attestation
  and complete Grok validation remain absent. GLAS-WP-0008 and CUST-WP-0073 retain
  harness/readiness ownership; no blocked profile was activated.
- T07 **wait**: implementing-session review passes Codex's 28 answers. Claude
  0.2.1 corrects both repaired cases but misnames the session-owner recipient in
  model-switch (27/28); a targeted retry passes. Full-run consistency, Grok and
  whitehat-security-owned independent review remain required. No unsafe effect
  recommendation was observed in reviewed answers.
- T08 **wait**: all four real-repository Claude pilots pass on 0.2.0. Owner
  feedback and owner-scoped wider pilots are still needed; these reports are
  retained with their original version and do not certify 0.2.1.
- T09 **wait**: publication/teaching/distribution agreements, reviewed-release
  fleet notice and reach acknowledgments remain pending. T02 adoption and T07
  assurance must precede rollout. Existing INFD-WP-0005 and RBT-WP-0006 links
  continue to own optional automation; no duplicate owner work is created.
- T10 **wait**: completion audit identifies missing acceptance evidence. This
  workplan is **blocked**, not finished; no DoD-Ok or owner assent is claimed.

Remaining work stays in these live original task records. It is required
completion work, not downgraded to residuals or moved into a finished plan.


## Repository-worker engagement — 2026-10-03

The user explicitly authorized starting worker agents in the repositories needed
for the next gates. Three active workers cover seven owners; review findings are
not human adoption or institutional assent merely because a worker produced them.

| Worker | Repository scope | Assigned evidence |
| --- | --- | --- |
| `/root/doctrine_adoption` | gate-house, net-kingdom, security-canon | Owner-scoped doctrine/vocabulary/publication reviews and concrete adoption dispositions, T02/T09 |
| `/root/whitehat_review` | whitehat-security | Separately authored offline adversarial review, known-bad fixture checks, findings and review limits, T07 |
| `/root/runtime_distribution` | access-engine, glas-harness, the-custodian | PDP/contract review, supported session-continuity proofs and distribution agreements, T02/T05/T09 |

All workers were confirmed running. Each must follow the target repository's
instructions, preserve unrelated changes, use existing owner work records where
applicable, record evidence locally and sync it, and return paths/IDs/blockers.
No worker edits this repository. No live deployment, blocked-profile activation,
fleet notice or human decision is authorized by this engagement. Scope remains
release 0.2.1 and its recorded digest; the plan returns to **active** while the
workers pursue the pending gates. T08/T10 remain waiting. The closure attempt
above is a historical checkpoint; no DoD-Ok is claimed by starting workers.