Adaptive immune security architecture for netkingdom
The standard moved v0.1 -> v0.4 after our assent. Reviewed; assent stands unchanged. §9.1/§9.2/§9.3 adopt the KG-DEC-2026-001 finding and generalise it estate-wide, and §12 now states that an unsatisfiability finding is a success of the conformance loop. Docs repointed at v0.4 (INTENT, SCOPE, AdjacentSystemBoundary, the architecture spec note). KG-DEC-2026-001 still cites v0.1 deliberately — it records what was assented to at the time. INTENT gap table reshaped to §5.3's field names (capability, intended_owner, blocked_on, review) so one register can hold both kinds, with review dates set to 2026-11-28, and marked explicitly as unowned capabilities rather than §5.3 declared contacts — kings-guard makes no Tooling contact and is Conforming under §11. Four findings sent to gate-house: §9.1 not carried through to the observation claim; §13 conflating declared contacts with unowned capabilities ahead of the maturity-engine migration; §9.6's unstated consequence for posture (suppression biases posture optimistic and our confidence score cannot express the doubt); and disclosure that §12's fourth step is unstaffed while the pilot remains fixture-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UEtvmYUBP2fDtirJGWn5MW Assistant: claude-code Assistant-Model: opus Assistant-Process: 4014379@bnt-lap001 Assistant-Session: 4af9e20f-1768-4afc-951b-b507784e382b |
||
|---|---|---|
| .repo-manager | ||
| decisions | ||
| docs | ||
| history | ||
| intake | ||
| intakes | ||
| specs | ||
| src/kings_guard | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
kings-guard
Adaptive security contracts and posture-evaluation scaffold for NetKingdom's immune-architecture work.
Layer: Staff (NetKingdom Security Layer Model v0.1). kings-guard publishes posture and requests bounded response through engine APIs; it never touches Tooling directly and never renders an authorization decision.
Current slice
This repository now contains four aligned pieces:
INTENT.md/SCOPE.mdfor the repo's stable boundaryspecs/NetKingdomImmuneArchitecture.mdfor the reference architecturespecs/ImmuneContracts.mdfor the first canonical contract layersrc/kings_guard/plustests/for a minimal posture loop scaffold
The current implementation is intentionally narrow. It does not enforce anything. It provides:
- typed contracts for security genome, phenotype, observation, posture, signal, effector request, and immune memory entry;
- a minimal posture evaluator that turns a normalized observation into a posture assessment and bounded response hints;
- a fixture-driven pilot based on
qonto-assistant, chosen because it already exposes a security genome record, an audit stream, and a fast local loop.
Repo layout
specs/NetKingdomImmuneArchitecture.mdspecs/ImmuneContracts.mddocs/AdjacentSystemBoundary.mddocs/pilots/QontoAssistantPosturePilot.mdsrc/kings_guard/tests/workplans/
Dev commands
# preferred, if make + pip are available
make install-dev
make test
make lint
make run-demo
# direct shell fallback used in minimal environments
python3 -m pytest -q
PYTHONPATH=src python3 -m kings_guard.main --pilot qonto-assistant