coulomb/emergent-security
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Implement source-backed NetKingdom agent security knowledge pilot

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a101af-e240-7882-a1e3-e37720cbdbea
This commit is contained in:
tegwick 2026-10-03 15:25:04 +02:00
parent caa7da2397
commit a835c11ae7
54 changed files with 3634 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

40
docs/decisions/EMERGENT-DEC-2026-001-integration-profile.md Normal file
View file

@ -0,0 +1,40 @@
# EMERGENT-DEC-2026-001 — Separate reference semantics from estate authority
Date: 2026-10-03. Status: implemented local boundary; cross-owner adoption pending.
Authority: the user's instruction to implement EMERGENT-WP-0002 within this repo.
This record does not claim another owner's assent or amend their contracts.
Emergent Security is Taxonomy with offline reference conformance tooling. It
publishes a model, reviewable policy examples, and agent knowledge. Its evaluator
does not act as an estate PDP, issue credentials, or cause protected effects.
The NetKingdom integration profile is a separate, versioned interpretation of
current owner boundaries. It cannot widen a grant or choose a more permissive
rule when generic doctrine and estate controls disagree. Existing v0.8 policy
fixtures keep their reference semantics. No runtime policy change is made.
| Conflict | Local disposition | Remaining owner work |
| --- | --- | --- |
| G9 Gate-House broker label | In the estate profile, gate-house owns doctrine; secrets-engine owns credential lifecycle over OpenBao. | Gate House / NetKingdom review the profile's wording and publication placement. |
| Reference evaluator vs sole PDP | Label all reference outputs as offline examples; do not expose an operational decision API. | Access Engine decides whether future reference rules become policy/claims; no automatic rule compiler. |
| Observer containment | Knowledge describes Kings Guard as proposal-only; future actuation is unavailable without owner proof. | Any actuation requires a separate owner implementation, not this knowledge rollout. |
| HOT/build defaults vs actual controls | Require resolved scope and actual task delegation; preserve founder change gates, plan exceptions, and harness limits. | Constitutional/policy changes need concrete owner/human decisions; generic defaults are not fleet-wide grants. |
| Authority modes, zone, tenant, temperature | Keep dimensions independent; map meaning and evidence, not privilege ranks. | SecurityCanon / NetKingdom review vocabulary mappings; no new wire claim schema here. |
| Conflicting capability claims | Cite revisions, list contradictions, withhold changed guidance; document facts as reviewed claims, not live proof. | Owners reconcile stale prose with their own shipped/runtime evidence. |
The profile is safe to pilot as orientation to existing published boundaries.
Cross-owner ratification of the generic canon remains open in T02; normative
fleet rollout remains gated in T09. This explicitly permits building and testing
the non-normative package while owner ratification is pending. It does not relax
the workplan's completion contract or make owner review optional.
The v0.8 canon and agent extract remain versioned reference artifacts. Their
current NetKingdom applicability is bounded by this profile; historical examples
must not be injected as live operational procedures. Code and envelope semantics
are unchanged, so existing policy fixtures continue to express the same model.
Sources: `knowledge/sources.yaml`, `knowledge/cards/compatibility.md`, and the
owner contracts linked in `docs/netkingdom-integration-map.md`.
Statehub adoption decision: `d20a9750-2b29-534e-8227-fb866581a6ca` (open; local implementation is not
cross-owner approval).