kings-guard/workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	quality_dor	quality_dor_at	quality_dor_by	state_hub_workstream_id
KG-WP-0002	workplan	Canonical immune contracts and first posture pilot	infotech	kings-guard	ready	codex	netkingdom	2026-07-23	2026-07-23	DoR-Ok	2026-07-23	codex	5c5c5a26-dfca-4d42-86a7-b87877677207

Canonical immune contracts and first posture pilot

Establish kings-guard as the adaptive security layer that sits beside the existing NetKingdom security lanes instead of competing with them. The first strand should produce stable contracts and one narrow posture pilot before any broader implementation or automation claims.

This workplan deliberately keeps authority boundaries clear:

• key-cape remains identity and attestation input.
• flex-auth remains authorization policy and final allow/deny owner.
• railiance-platform and secrets-engine remain secret-custody and delivery owners.
• ops-warden remains the operational SSH certificate lane.
• kings-guard evaluates health/posture, emits signals, and requests bounded response.

Task: Define canonical immune contracts

id: KG-WP-0002-T01
status: todo
priority: high
state_hub_task_id: "9982a3b4-1e65-493a-9b61-322f23d4fd2d"

Write the first repo-owned canonical contract for the core vocabulary: security_genome, security_phenotype, immune_observation, immune_signal, effector_request, tolerance, inflammation, and immune_memory.

Done when:

• each term has a concise, non-overlapping definition;
• producer/consumer expectations are named for each contract;
• the contracts are usable without requiring one particular product stack.

Task: Write adjacent-system boundary contract

id: KG-WP-0002-T02
status: todo
priority: high
state_hub_task_id: "0c44035e-b1b8-4f5d-8a6c-e6514b4bc897"

Author a boundary document that shows how kings-guard consumes evidence from key-cape, flex-auth, secrets-engine, ops-warden, and Railiance runtime layers without taking over their responsibilities.

Done when:

• each adjacent system's primary authority is stated explicitly;
• kings-guard inputs, outputs, and non-goals are named per system;
• tenant-isolation and non-secret evidence rules are captured.

Task: Scaffold a minimal posture loop

id: KG-WP-0002-T03
status: todo
priority: high
state_hub_task_id: "c88a7da6-a9ff-4bd9-ba47-7c199321666b"

Create the initial repository structure for a minimal posture engine or schema package that can ingest normalized observations, compare them against declared intent, and emit typed posture/signal results.

Done when:

• the repo has a clear implementation layout rather than only prose;
• one sample input/output path exists end-to-end for observation -> posture -> signal;
• tests or fixture-driven validation prove the contract shape is stable.

Task: Choose and specify the first pilot lane

id: KG-WP-0002-T04
status: todo
priority: medium
state_hub_task_id: "77e1dc69-9902-4381-8028-ce1cfac7e9d5"

Pick one narrow pilot integration lane and specify it precisely. Preferred pilot order:

1. ops-warden sign-request posture hinting
2. secrets-engine exec-delivery posture hinting
3. Railiance workload reconstitution signal generation

Done when:

• the chosen lane has a concrete request/response flow;
• the pilot can run without granting kings-guard secret, identity, or final authorization authority;
• bounded-response and rollback expectations are documented.