115 lines
3.5 KiB
Markdown
115 lines
3.5 KiB
Markdown
---
|
|
id: KG-WP-0002
|
|
type: workplan
|
|
title: "Canonical immune contracts and first posture pilot"
|
|
domain: infotech
|
|
repo: kings-guard
|
|
status: ready
|
|
owner: codex
|
|
topic_slug: netkingdom
|
|
created: "2026-07-23"
|
|
updated: "2026-07-23"
|
|
quality_dor: DoR-Ok
|
|
quality_dor_at: "2026-07-23"
|
|
quality_dor_by: "codex"
|
|
state_hub_workstream_id: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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.
|