diff --git a/decisions/decisions.md b/decisions/decisions.md index f6a0c3b..bb17285 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -151,3 +151,81 @@ advisory and fixture-driven, which is the honest state and not a workaround. - kings-guard's assent removes one of the two adaptations §11 lists as outstanding. The standard remains proposed pending `flex-auth` and `ops-warden`. + +## KG-DEC-2026-002 — The posture/maturity boundary is recomputability, not volatility + +```yaml +id: KG-DEC-2026-002 +kind: decision +title: The posture/maturity boundary is recomputability, not volatility +status: resolved +owner: Bernd Worsch +repo: kings-guard +standard: net-kingdom/canon/standards/security-layer-model_v0.7.md +origin_ref: KG-IN-0003 +commentary: docs/PostureMaturityBoundary.md +affects: +- kings-guard +- gate-house +- maturity-engine +- net-kingdom +created: '2026-08-29' +updated: '2026-08-29' +decided_by: Bernd Worsch +disposition: revision-proposed +``` + +## Context + +`gate-house` asked `kings-guard` (`KG-IN-0003`) to check a boundary it had not +drawn: posture and maturity are both graded, and two engines grading the same +subject would be the same shape of mistake as a second decision point. Its +proposed line was posture as volatile current state about an actor against +maturity as slow progression of a capability. + +## Decision + +**Revision proposed.** The line is nearly right and drawn on the wrong axis. +Volatility is an observation about data, not a definition, and it fails at both +edges — evidence can land in a burst, and a healthy subject can hold one posture +for months. More importantly it describes the two things without partitioning +them, and every case it leaves to argument is a route by which a second grading +authority arrives. + +The discriminator is already in the statute. §9.5 requires maturity to return +the same level from the same criteria and evidence, and says that determinism is +what makes it an Engine rather than an opinion; §3.3 says a repository whose +core function is inference is Staff by construction. So: + +> Given the same criteria and the same evidence, recompute. If you must get the +> same answer, it is maturity and belongs in an engine. If you cannot promise +> the same answer, it is posture and belongs in Staff. + +This is one rule read from both sides. §9.5 already states the maturity half — +a criterion that cannot be evaluated by rule is not yet a criterion. The posture +half is its mirror: a judgment that can be evaluated by rule is not posture, it +is a criterion in the wrong repository. Together they partition; "volatile +versus slow" does not. + +Full argument: `docs/PostureMaturityBoundary.md` (KG-COM-0001). + +## Consequences accepted by kings-guard + +- **Capability readiness is not an input to posture.** Readiness is + deterministic and posture is not; feeding one into the other would make + posture partly recomputable and blur the boundary from our side. Accepted as a + constraint on this repository. +- Consequently, tracking our gaps in `maturity-engine` creates no incident-path + dependency: we never consult our own readiness to judge an observation, so + `maturity-engine` being unreachable mid-incident changes nothing about posture + evaluation. This answers the second half of `KG-IN-0003`. +- Anything we currently call posture that proves recomputable belongs in + `maturity-engine` as a criterion, and we will hand it over rather than keep it. + +## Limit + +The test says "the same evidence", which is not yet well defined estate-wide. +Until §17's schemas exist, two parties can disagree about whether they hold the +same evidence and recomputability is a thought experiment rather than a check. +§17 is therefore load-bearing for this decision; `kings-guard` owns the +emission-cadence half under `KG-WP-0003-T02`. diff --git a/docs/PostureMaturityBoundary.md b/docs/PostureMaturityBoundary.md new file mode 100644 index 0000000..27f7359 --- /dev/null +++ b/docs/PostureMaturityBoundary.md @@ -0,0 +1,142 @@ +--- +title: "Commentary — the posture/maturity boundary" +document_id: KG-COM-0001 +version: 1.0.0 +status: Published +date: 2026-08-29 +repo: kings-guard +kind: commentary +commentary_on: net-kingdom/canon/standards/security-layer-model_v0.7.md +sections: ["8", "9.5", "3.3"] +answers: KG-IN-0003 +classification: Public +--- + +# Commentary — the posture/maturity boundary + +A commentary, not a proposed edit. `gate-house` owns the rules (statute §2); +this is `kings-guard`'s reading of a boundary it asked us to check, offered in +the form the conformance loop expects. Adopt, revise, or reject. + +## The question + +`KG-IN-0003` asks us to check a line `gate-house` had not drawn: + +> 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 + +with the concern stated plainly: *a second grading authority would be the same +shape of mistake as a second decision point.* + +That concern is correct and it is the reason the line has to be exact. + +## The line is nearly right and drawn on the wrong axis + +Volatility is the wrong discriminator. Rate of change is an observation about +the data, not a definition of it, and it fails at both edges: a maturity +criterion can move quickly when evidence lands in a burst, and a posture can sit +unchanged for months on a subject that stays healthy. A boundary that has to +hold under §6 cannot rest on how fast a value happens to move, because nothing +prevents the value from moving at a different speed tomorrow. + +Worse, "volatile versus slow" describes the two things without partitioning +them. Every case it does not obviously cover is an argument, and arguments at a +boundary are how a second grading authority arrives — gradually, and each time +for a good local reason. + +## The line the statute already draws + +The discriminator is in §9.5 and does not need to be invented: + +> Given the same criteria and the same evidence it MUST return the same level; +> that determinism is what makes it an Engine rather than an opinion. + +And in §3.3, generally: + +> A repository whose core function is inference or judgment fails this test by +> construction and is Staff, however much of its work happens at runtime. + +So the test is **recomputability**: + +> Given the same criteria and the same evidence, recompute. If you must get the +> same answer, it is **maturity** and it belongs in an engine. If you cannot +> promise the same answer, it is **posture** and it belongs in Staff. + +This is the statute's own organizing principle — determinism — applied to the +one boundary where it had not yet been used. It is not a new rule. It is the +existing rule read at a place it had not been pointed. + +## It is one rule read from opposite sides + +§9.5 already states the maturity half: *a criterion that cannot be evaluated by +rule is not yet a criterion.* That is maturity refusing to absorb inference. + +The posture half is its mirror, and stating it completes the pair: **a judgment +that can be evaluated by rule is not posture — it is a criterion sitting in the +wrong repository.** + +Together they partition rather than describe. There is no case the pair leaves +to argument, which is exactly what "volatile versus slow" cannot offer. + +## Three consequences + +**1. The migration direction is defined, permanently.** Anything currently +called posture that turns out to be recomputable should move to +`maturity-engine` as a criterion. Anything in `maturity-engine` that needs +judgment is not yet a criterion and moves back to Staff. The boundary maintains +itself under change instead of needing to be re-adjudicated, because the test is +mechanical and applies to each item rather than to the category. + +**2. The second-grading-authority failure is structurally prevented, not +conventionally avoided.** `gate-house`'s worry is answered by the shape of the +test rather than by both parties agreeing to stay on their own side. Two +authorities cannot grade the same subject on this line, because a single subject +property is either recomputable or it is not, and that fact is not a matter of +which repository claims it. + +**3. Capability readiness must not be an input to posture.** This is the +constraint the test imposes on *us*, and we accept it. Readiness is +deterministic; posture is not. If readiness fed posture, posture would become +partly recomputable and the boundary would blur from the kings-guard side — the +same failure, arriving through the door we own. + +This also answers the second half of `KG-IN-0003`. Tracking our gaps in +`maturity-engine` creates no dependency we would rather not carry during an +incident, because we never consult our own readiness to judge an observation. If +`maturity-engine` is unreachable mid-incident, nothing about posture evaluation +changes. The dependency would only exist if we had already made the mistake this +consequence forbids. + +## A caution about the word + +`posture` has the drift profile that `control plane` had: it sounds specific, +and it quietly absorbs whatever sits next to it. That is how this repository +came to describe itself as a control plane in the first place, and §8 exists +because the estate has been bitten by exactly this. + +The recomputability test is a defence against that drift, because it is +mechanical and can be applied to a candidate before the word is stretched to +cover it. We would rather be held to it than trusted about it. + +## What this commentary does not claim + +- It does not touch §8's three-way split. `kings-guard` publishes posture, + `gate-house` defines its authority meaning, `access-engine` renders it. That + division is unaffected and we are not asking to widen our half. +- It does not make posture an engine concept. Posture stays non-deterministic + and stays Staff. The test explains *why*, which is what was missing. +- It proposes no §4 catalog change. + +## An honest limit + +The test says "the same evidence", and that phrase is not yet well defined +anywhere in the estate. Until §17's request-claim and gap-record schemas exist, +two parties can disagree about whether they hold the same evidence, and +recomputability is a thought experiment rather than a check. + +That is a real limit and it is not an argument against the line — a boundary +that is correct but not yet mechanically checkable is still better than one that +is checkable and wrong. It does mean §17 is load-bearing for this commentary, +and `kings-guard` has the emission-cadence half of that work under +`KG-WP-0003-T02`. diff --git a/intakes/intakes.md b/intakes/intakes.md index 6662621..aba8f53 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -77,9 +77,11 @@ id: KG-IN-0003 kind: intake title: 'Review requested: security layer model v0.3 (maturity-engine, and the posture/maturity boundary)' -status: open +status: closed origin: cross-repo origin_ref: net-kingdom security-layer-model_v0.3 +outcome: promoted +promoted_to: KG-DEC-2026-002 priority: medium owner: kings-guard requested_by: gate-house @@ -103,5 +105,15 @@ description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the v0.2 a Assent, revision, or rejection acceptable.' created: '2026-08-28T20:40:12.260389Z' updated: '2026-08-28T20:40:12.260389Z' +closed: '2026-08-29' +resolution: 'Answered with a proposed revision. The boundary is recomputability, + not volatility: given the same criteria and the same evidence, if you must get + the same answer it is maturity and belongs in an engine, and if you cannot + promise the same answer it is posture and belongs in Staff. Drawn from statute + section 9.5 and section 3.3 rather than imposed on them, and it partitions + where volatile-versus-slow only describes. kings-guard accepts the constraint + this puts on its own side: capability readiness is not an input to posture, + which also answers the incident-dependency question. Commentary: + docs/PostureMaturityBoundary.md. Decision: KG-DEC-2026-002.' state_hub_intake_id: "01a04d8d-66f8-70ef-b2b5-1eff03569471" ```