---
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.