kings-guard/docs/StatuteV08Review.md

---
title: "Commentary — review of security layer model v0.8"
document_id: KG-COM-0002
version: 1.0.0
status: Published
date: 2026-09-21
repo: kings-guard
kind: commentary
derived: true
derived_from: net-kingdom/canon/standards/security-layer-model_v0.8.md
derived_at: "net-kingdom@66eeaba"
status_as_of: "2026-09-21"
commentary_on: net-kingdom/canon/standards/security-layer-model_v0.8.md
sections: ["9.5", "11", "12"]
answers: KG-IN-0006
classification: Public
---

# Commentary — review of security layer model v0.8

> **Derived artifact.** This is a dated review record. It states
> `kings-guard`'s reading of `security-layer-model_v0.8.md` as of
> 2026-09-21 at `net-kingdom@66eeaba`, and **not** current state. The
> authoritative artifact is the statute body, not this file. Marked per
> the derived-artifact rule v0.8 adds to §12 and §11 — the rule is new in
> the version under review, so this review complies with it.

A commentary, not a proposed edit. `gate-house` owns the rules (§2). Adopt,
revise, or reject.

`gate-house` circulated v0.8 on 2026-09-06 and asked for findings, naming §9.5
as `kings-guard`'s boundary and asking specifically whether §12's step four is
still true. This reply is three weeks late; the delay is `kings-guard`'s and is
noted in `KG-IN-0006`. Nothing in the interval changed an answer.

## F1 — Assent to §9.5 at v0.8, including the clause we did not propose

`GH-DEC-2026-007` adopted `KG-DEC-2026-002` and added a clause of gate-house's
own:

> A criterion MUST bottom out in evidence about the subject, not in another
> party's conclusion about the subject. A recorded judgment may be evidence
> *that the judgment was made* — a fact with an issuer and a timestamp. It MUST
> NOT be evidence *that the thing judged is so.*

**`kings-guard` assents to the clause.** It is not an enlargement of the test we
proposed; it closes a hole the test has. Recomputability is assessed over stated
criteria, so a criterion that dereferences a verdict recomputes perfectly and has
still placed an opinion inside an engine. That is precisely the second grading
authority our own consequence 2 claims is structurally prevented, arriving
through the front door. Without the clause our test is mechanical and
circumventable, and we would rather be held to a test that catches the
circumvention than be trusted not to attempt it.

We accept that it constrains ladder authoring in `maturity-engine`, including
ladders that grade `kings-guard`.

### The falsifier, attacked

gate-house wrote the reversal condition itself: *if a legitimate maturity
criterion cannot be expressed without dereferencing a judgment, the grounding
clause is wrong*, with human-attested controls as the likely candidates. We
tested it against the criteria this repository actually holds — the ones a
readiness ladder over `kings-guard` would have to grade today.

**Candidate 1 — a §3.4 rule whose check is an assertion.** `layer.yaml` records
four agent-principal rules and, beside them, the *form* of each check:
`no_standing_credential` and `memory_is_not_a_state_plane` are tests,
`reconstructable_as_caller` is mixed, and `tool_use_shapes` is an **assertion**,
because distinguishing an Engine API call from an ordinary Python call is not
mechanical here. A criterion "does `kings-guard` satisfy §3.4" bottoms out in a
test result for two rules and, for `tool_use_shapes`, in nothing but
`kings-guard`'s own recorded judgment that no third route is claimed.

The clause handles it, by its own prescribed route: grade the declaration's
existence, freshness, and issuer, never its verdict. **The falsifier does not
fire.** But the criterion that survives is not the one a reader expects, and
that is worth saying plainly:

> A criterion grounded on an attestation event grades the attestation. It does
> not grade the property attested. A consumer who reads the resulting level as
> the property has made the §9.6 mistake — reading an artifact as proving
> something it does not prove — one layer up, inside a ladder.

We are not proposing statute text for that; it may belong in §9.5 beside the
clause, or in `maturity-engine`'s ladder-authoring guidance, and that is
gate-house's call. We raise it because the clause makes such criteria *legal*,
and legality is exactly when the misreading becomes available.

**Candidate 2 — a readiness row grounded on another repository's decision.**
`kings-guard`'s three `unowned_capabilities` rows carry `owner_status` values
such as *"access-engine declined (v0.6 §13); reproposed, not assented"*. A
readiness ladder over these rows dereferences a conclusion reached by a third
party about `kings-guard`'s dependency — the shape the clause forbids.

Here the clause does not merely survive, it gives the right answer: the evidence
is that `FLEX-DEC-2026-002` exists, with its issuer and its date. The criterion
grades the existence of a recorded engine position, not whether declining was
correct. That is the resolution gate-house predicted, reached on a criterion we
did not construct for the purpose.

**Conclusion: we could not falsify it.** The two real candidates we hold both
resolve the way gate-house expected. We hold no criterion that cannot be
expressed without dereferencing a verdict.

### What this assent is to, exactly

The v0.8 assent round is being asked to stay open while six §11 questions are
ruled (see F3, F5). So the scope of this assent is stated rather than left to be
inferred:

- **Assent is to the boundary in §9.5**, as that section stands in the v0.8 text
  at `net-kingdom@66eeaba`, including the grounding clause, the three
  consequences (migration direction, two authorities cannot grade the same
  subject property, and capability readiness MUST NOT be an input to posture),
  and the stated §17 limit.
- **Assent is given at a named version, not to current text**, per §14.
  Revision of §9.5 reopens it; revision elsewhere in v0.8 does not.
- **Assent to §9.5 is not assent to v0.8 as a whole**, and specifically does not
  dispose of §11. §9.5 does not depend on the §11 declaration-form questions, so
  it does not need to wait on them, and holding the round open for §11 should not
  be read as §9.5 being unsettled.
- Consequence 3 — capability readiness MUST NOT be an input to posture — is
  normative on this repository rather than a promise. We volunteered it and we do
  not now want it softened.

Recorded as `KG-DEC-2026-004`.

## F2 — §12 step four: the load-bearing sentence is still true, the supporting one is not

gate-house asked directly: *if your qonto-assistant pilot has gone live since,
that paragraph needs correcting in this version rather than the next.*

**It has not gone live, and the paragraph's normative sentence must stay.**
`kings-guard` has still never observed anything in production. No argument in
this estate may assume an invariant is being watched in practice because §12
lists this repository against step four. `KG-WP-0005-T03` — observe an authorized
deployed `qonto-assistant` process from startup through a transition and a
reconciliation read — is still `wait`, and it waits on the runtime owner, who
holds deployment. This repository supplies no deployed stream endpoint and no
process-lifecycle observation route, and took no cluster or Tooling client to
try.

**The supporting sentence has drifted, in our favour, and we are reporting it
against ourselves.** §12 says *"every input is a hand-built fixture, and no test
has met a real event"*. That was exact when we disclosed it. Since v0.6,
`KG-WP-0005-T02` drives `qonto-assistant`'s **real** `AuditLogger` emit path:
the records under test are produced by the source's own emit code, with
source-owned cadence, instance and sequence fields, contiguous sequence checks,
heartbeat translation, and a transition-count comparison against captured request
evidence. They are real events from the real producer. They are not events from a
deployed process.

So the true statement is narrower than "fixtures" and wider than "nothing":

> Proposed replacement for the supporting sentence — `kings-guard` has exercised
> a source's own emit path locally, but has observed no deployed process: no
> input has yet come from a system running in production.

We would rather the statute said the narrower thing, because the broader phrasing
is the kind of derivative that goes stale quietly and then gets cited — the
defect §12 was extended to catch. The distinction also matters for §9.6: a local
source-path proof does not substitute for operational evidence, and we do not
claim it does.

## F3 — §11 declaration form: `kings-guard` carries both forms and will not pick between them

`flex-auth` corrected its first boundaries-review finding on 2026-09-21. The
withdrawn claim was that the estate spells `layer:` inconsistently *across*
repositories; the corrected finding is narrower and sharper:

    INTENT.md    layer: Staff
    layer.yaml   layer: staff

§11 accepts *"a `layer:` key in the `INTENT.md` frontmatter, or an equivalent
declaration file"* and does not say which governs when a repository carries both.
`kings-guard` carries both, they differ, and both follow §11. A conformance run
reading one file and a run reading the other reach different answers about this
repository, and neither run is wrong.

**`kings-guard` is not changing either file.** Two rulings are needed — which
form governs, and whether the §3 vocabulary is case-sensitive — and gate-house
holds both. Aligning now would be this repository authoring a ruling it does not
own, on the one section that says a layer stated by anyone other than the
repository itself is not a declaration. It would also not help: whichever way we
guessed, the guess would be invisible to the ruling, and a repository that had
already converged would have to be moved twice.

We are content either way. We have no attachment to the casing and no argument
that one file should win; we only want to be told once and move once. We will
align both files inside one commit when the ruling lands, and the wait is
recorded as `KG-IN-0007` rather than left as a silence.

One observation offered to the ruling, which we hold no position on: the two
repositories that agree between their files (`informed-decision`,
`railiance-master`) are the ones declaring values outside the §3 vocabulary. If
that is right, no single generator fix closes the finding, and a ruling on
precedence alone would leave a third class — a declared layer that is not a layer
the model defines — untouched.

## F4 — `kings-guard`'s own declaration carries a standard version (B4)

`layer.yaml` carries `standard_version: "0.7"` and points its `framework:`
comment at the v0.7 file. `flex-auth` removed the equivalent field from its own
declaration and enforced the absence by test, on the argument that assent is to a
boundary at a named version, so a version inside the declaration makes every
revision read as though it invalidated the declaration. That is question 6 in the
same set gate-house holds.

We state our reading, and we are not acting on it unilaterally either. In
`kings-guard`'s file the field names *the version the declaration was validated
against*, not the version of any assent — assents live in
`decisions/decisions.md`, one per boundary, each naming its own version. Read
that way the field is a provenance marker and `flex-auth`'s objection does not
reach it. Read the other way it is exactly the defect `flex-auth` names.

The ambiguity is the finding: the field means two things and the statute does not
say which. If gate-house rules that declarations carry no version, we will remove
it. Until then it stays, because removing it would destroy the only record of
which statute version the conformance script was checked against, with nothing
put in its place. Folded into `KG-IN-0007`.

## F5 — Does `kings-guard` owe an emission guarantee? We decline the reading that favours us

v0.8's §11 adds: *every repository catalogued in §4 as a source of evidence
declares its emission guarantee in its machine-readable layer declaration*, and
*a source that declares no emission guarantee is not conforming.*

gate-house flagged this to us **as the cadence consumer**, and on the §4 catalog
row that is right: `kings-guard` is catalogued for *adaptive defence and
judgment; observation of Staff-reachable sources*, not as a source of evidence.
Our `layer.yaml` declares no emission guarantee, and on that reading it does not
need to.

**We decline to rest on it without a ruling.** `kings-guard` publishes posture.
Posture is consumed by `gate-house` for authority meaning and rendered by
`access-engine`. Whether published posture is *evidence* under §4 — making this
repository a source with an undeclared emission guarantee, and non-conforming on
§11 today — is not something the catalog row settles, and the repository that
benefits from the narrow reading is the wrong one to settle it. This is the same
shape as `flex-auth`'s open gap over the decision record, and we take the same
stance for the same reason.

If gate-house rules that posture is §4 evidence, `kings-guard` owes an emission
guarantee for its posture stream and will declare one; the class is almost
certainly **attributive**, since posture is a judgment and we claim no
completeness for it. We would rather write that declaration than discover later
that we were the exception nobody checked. Recorded as `KG-IN-0008`.

## What we are not raising

The remaining v0.8 changes — §9.7.3's consume order and binding correspondence,
§6.4's obligation 5 and the `unknown` ruling, §13.1's three rows, §17's ownership
paragraph — are outside `kings-guard`'s boundary and we reviewed them only for
consistency with §9.5 and §12. We found none. Our four v0.6 findings are
confirmed dispositioned; we re-checked §3.4 against the v0.8 body rather than the
change log, which is the habit that produced the finding in the first place.