tegwick
d99f395aa1
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
244 lines
12 KiB
JSON
244 lines
12 KiB
JSON
{
|
|
"schema": "repo_manager.index.v1",
|
|
"slug": "layer-model-v03-review",
|
|
"repo_root": "/home/worsch/kings-guard",
|
|
"head_sha": "3686f8994bef468499abf58ddb6020503ed285e6",
|
|
"observed_at": "2026-08-28T20:40:12.405988Z",
|
|
"source_fingerprint": "cfeafedc875687fa1f24d10127b22b0b6dcce30f1faddf803b7c2a19e046cf12",
|
|
"source_files": [
|
|
".repo-classification.yaml",
|
|
"INTENT.md",
|
|
"decisions/decisions.md",
|
|
"intakes/intakes.md",
|
|
"workplans/KG-WP-0001-statehub-bootstrap.md",
|
|
"workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md"
|
|
],
|
|
"work_records": [
|
|
{
|
|
"kind": "workplan",
|
|
"id": "KG-WP-0001",
|
|
"status": "finished",
|
|
"title": "Bootstrap State Hub integration",
|
|
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
|
"uuid": "b7ff79b9-ae27-4a46-a782-49482392eb83",
|
|
"parent_id": null,
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0001-T01",
|
|
"status": "done",
|
|
"title": "Review Generated Integration Files",
|
|
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
|
"uuid": "add34171-9f18-48b9-a88e-07ea34cb6382",
|
|
"parent_id": "KG-WP-0001",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0001-T02",
|
|
"status": "done",
|
|
"title": "Verify Local Developer Workflow",
|
|
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
|
"uuid": "17fb3a0c-91c5-4b45-967e-962ef6c89ac5",
|
|
"parent_id": "KG-WP-0001",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0001-T03",
|
|
"status": "done",
|
|
"title": "Seed First Real Workplan",
|
|
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
|
"uuid": "5b5f56d9-7e89-43b6-94c3-db4461e9eed4",
|
|
"parent_id": "KG-WP-0001",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "workplan",
|
|
"id": "KG-WP-0002",
|
|
"status": "finished",
|
|
"title": "Canonical immune contracts and first posture pilot",
|
|
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
|
"uuid": "5c5c5a26-dfca-4d42-86a7-b87877677207",
|
|
"parent_id": null,
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0002-T01",
|
|
"status": "done",
|
|
"title": "Task: Define canonical immune contracts",
|
|
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
|
"uuid": "9982a3b4-1e65-493a-9b61-322f23d4fd2d",
|
|
"parent_id": "KG-WP-0002",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0002-T02",
|
|
"status": "done",
|
|
"title": "Task: Write adjacent-system boundary contract",
|
|
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
|
"uuid": "0c44035e-b1b8-4f5d-8a6c-e6514b4bc897",
|
|
"parent_id": "KG-WP-0002",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0002-T03",
|
|
"status": "done",
|
|
"title": "Task: Scaffold a minimal posture loop",
|
|
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
|
"uuid": "c88a7da6-a9ff-4bd9-ba47-7c199321666b",
|
|
"parent_id": "KG-WP-0002",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "task",
|
|
"id": "KG-WP-0002-T04",
|
|
"status": "done",
|
|
"title": "Task: Choose and specify the first pilot lane",
|
|
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
|
"uuid": "77e1dc69-9902-4381-8028-ce1cfac7e9d5",
|
|
"parent_id": "KG-WP-0002",
|
|
"extra": {}
|
|
},
|
|
{
|
|
"kind": "decision",
|
|
"id": "KG-DEC-2026-001",
|
|
"status": "resolved",
|
|
"title": "Assent to Staff placement, release of control-plane vocabulary, and the posture asymmetry",
|
|
"source_path": "decisions/decisions.md",
|
|
"uuid": "80313094-9b5d-4954-b37b-3313deac6b65",
|
|
"parent_id": null,
|
|
"extra": {
|
|
"record": {
|
|
"id": "KG-DEC-2026-001",
|
|
"kind": "decision",
|
|
"title": "Assent to Staff placement, release of control-plane vocabulary, and the posture asymmetry",
|
|
"status": "resolved",
|
|
"owner": "Bernd Worsch",
|
|
"repo": "kings-guard",
|
|
"standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
|
|
"origin_ref": "KG-IN-0001",
|
|
"related": [
|
|
"gate-house/decisions/decisions.md GH-DEC-2026-001",
|
|
"gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md"
|
|
],
|
|
"affects": [
|
|
"kings-guard",
|
|
"gate-house",
|
|
"net-kingdom",
|
|
"access-engine",
|
|
"secrets-engine",
|
|
"user-engine"
|
|
],
|
|
"created": "2026-08-28",
|
|
"updated": "2026-08-28",
|
|
"decided_by": "Bernd Worsch",
|
|
"disposition": "assent-with-finding",
|
|
"state_hub_decision_id": "80313094-9b5d-4954-b37b-3313deac6b65"
|
|
}
|
|
}
|
|
},
|
|
{
|
|
"kind": "intake",
|
|
"id": "KG-IN-0001",
|
|
"status": "closed",
|
|
"title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
|
|
"source_path": "intakes/intakes.md",
|
|
"uuid": "01a049ea-2e37-7dde-9772-fab7e788d8d7",
|
|
"parent_id": null,
|
|
"extra": {
|
|
"record": {
|
|
"id": "KG-IN-0001",
|
|
"kind": "intake",
|
|
"title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
|
|
"status": "closed",
|
|
"outcome": "absorbed",
|
|
"promoted_to": "KG-DEC-2026-001",
|
|
"origin": "cross-repo",
|
|
"origin_ref": "gate-house GH-DEC-2026-001",
|
|
"priority": "medium",
|
|
"owner": "kings-guard",
|
|
"requested_by": "gate-house",
|
|
"standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
|
|
"description": "gate-house asks kings-guard to assent to its placement in the NetKingdom security layer model. (1) kings-guard is Staff \u2014 agentic and non-deterministic \u2014 not an Engine. Acting at runtime does not make a repository an Engine; being agentic makes it Staff. (2) Consequently its self-description as an adaptive security control plane needs revisiting: control plane is Engine-layer vocabulary (standard section 8). This is not a demotion \u2014 it is the reason kings-guard may contain a threat only by calling an engine, never by reaching into OpenBao or a cluster directly (the binding rule, standard section 5: Staff never touches Tooling directly). (3) The posture contract with gate-house and its asymmetry: adaptive systems may reduce authority, require step-up, or request containment; they must never probabilistically manufacture additional authority. kings-guard publishes posture, gate-house defines its authority meaning, access-engine renders it. If the binding rule is impractical for containment in a real incident, say so \u2014 that is exactly the kind of finding that should change the doctrine rather than be worked around.",
|
|
"created": "2026-08-28T19:30:17.201213Z",
|
|
"updated": "2026-08-28T19:30:17.201213Z",
|
|
"closed": "2026-08-28",
|
|
"resolution": "Assent with finding. All three points assented and adopted in INTENT.md, SCOPE.md, README.md, AGENTS.md, and docs/AdjacentSystemBoundary.md. The invited challenge to the binding rule was taken up and answered: do not weaken section 5 \u2014 but section 4 catalogs kings-guard as owning containment while no engine exposes a containment surface, so the charter is currently undischargeable. Two rulings requested of gate-house. Full record: decisions/decisions.md KG-DEC-2026-001. Vocabulary sweep of the architecture spec handed off as KG-IN-0002.",
|
|
"state_hub_intake_id": "01a049ea-2e37-7dde-9772-fab7e788d8d7"
|
|
}
|
|
}
|
|
},
|
|
{
|
|
"kind": "intake",
|
|
"id": "KG-IN-0002",
|
|
"status": "open",
|
|
"title": "Sweep \"control plane\" and layer vocabulary through NetKingdomImmuneArchitecture.md",
|
|
"source_path": "intakes/intakes.md",
|
|
"uuid": "01a049ea-3a04-74b9-a9b1-e2630f8d5628",
|
|
"parent_id": null,
|
|
"extra": {
|
|
"record": {
|
|
"id": "KG-IN-0002",
|
|
"kind": "intake",
|
|
"title": "Sweep \"control plane\" and layer vocabulary through NetKingdomImmuneArchitecture.md",
|
|
"status": "open",
|
|
"origin": "residual",
|
|
"origin_ref": "KG-DEC-2026-001",
|
|
"priority": "low",
|
|
"owner": "kings-guard",
|
|
"standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
|
|
"description": "specs/NetKingdomImmuneArchitecture.md (approx. 1900 lines) predates the NetKingdom Security Layer Model and uses \"control plane\" in several places \u2014 including a \"Platform Immune Control Plane\" subgraph \u2014 where the layer model reserves that vocabulary for the Engine layer. A scoping note now sits at the head of the document so no reading takes it as a kings-guard self-description, but the body is not adapted. Sweep it: separate the components that are engine-layer authorities from the observation-and-judgment surface kings-guard actually owns, and check that no part of the architecture places a decision point in Staff (layer model section 6).",
|
|
"created": "2026-08-28",
|
|
"updated": "2026-08-28",
|
|
"state_hub_intake_id": "01a049ea-3a04-74b9-a9b1-e2630f8d5628"
|
|
}
|
|
}
|
|
},
|
|
{
|
|
"kind": "intake",
|
|
"id": "KG-IN-0003",
|
|
"status": "open",
|
|
"title": "Review requested: security layer model v0.3 (maturity-engine, and the posture/maturity boundary)",
|
|
"source_path": "intakes/intakes.md",
|
|
"uuid": null,
|
|
"parent_id": null,
|
|
"extra": {
|
|
"record": {
|
|
"id": "KG-IN-0003",
|
|
"kind": "intake",
|
|
"title": "Review requested: security layer model v0.3 (maturity-engine, and the posture/maturity boundary)",
|
|
"status": "open",
|
|
"origin": "cross-repo",
|
|
"origin_ref": "net-kingdom security-layer-model_v0.3",
|
|
"priority": "medium",
|
|
"owner": "kings-guard",
|
|
"requested_by": "gate-house",
|
|
"description": "v0.3 is proposed and changes sections 4, 9 and 13 only; the v0.2 assent record stands. It responds directly to KG-DEC-2026-001. Section 9.5 assigns graded progression to a new maturity-engine, which now owns the gap register with intended_owner, blocked_on and review dates, and capability readiness \u2014 so your three declared engine gaps and the pending containment claim become queryable facts rather than footnotes in a standard. Your finding also produced 9.1 in v0.2, and v0.3 applies it to gate-house itself: gate-house was catalogued as owning conformance review with no engine to act through, exactly the defect you named for containment, and it now acts through maturity-engine. THE QUESTION FOR YOU is a boundary we have not drawn: posture and maturity are both graded, and we do not want two engines grading the same subject. Our reading is that posture is volatile current security state about an actor, published by kings-guard and rendered by access-engine, while maturity is slow progression of a capability against declared criteria. If that line is wrong, or if maturity-engine would absorb something you consider posture, say so now \u2014 a second grading authority would be the same shape of mistake as a second decision point. Also worth your view: does capability readiness for containment belong in maturity-engine, or does tracking your own gaps there create a dependency you would rather not carry during an incident? Assent, revision, or rejection acceptable.",
|
|
"created": "2026-08-28T20:40:12.260389Z",
|
|
"updated": "2026-08-28T20:40:12.260389Z"
|
|
}
|
|
}
|
|
}
|
|
],
|
|
"events": [
|
|
{
|
|
"type": "repo.command.applied",
|
|
"command": "repo.work.create_intake",
|
|
"operation": "create",
|
|
"correlation_id": "aae5e5ae-a706-4da5-82fc-a0fb8982ca5b",
|
|
"kind": "intake",
|
|
"id": "KG-IN-0003",
|
|
"git_sha": "3686f8994bef468499abf58ddb6020503ed285e6",
|
|
"files_touched": [
|
|
"intakes/intakes.md"
|
|
],
|
|
"source": "repo-manager",
|
|
"emitted_at": "2026-08-28T20:40:12.406045Z"
|
|
}
|
|
]
|
|
}
|