# Security layer model — v0.8 §11 declaration amendment set

**Repository:** gate-house (author)
**Publisher:** net-kingdom
**Project family:** NetKingdom security layer
**Status:** drafted — circulating for assent; the v0.8 acceptance flip is held on it (`GH-DEC-2026-019`)
**Version:** 0.2 — A12 revised as A12 r2 (`GH-DEC-2026-020`); re-circulated for assent
**Date:** 2026-09-21
**Workplan:** `GH-WP-0004`
**Base:** `net-kingdom/canon/standards/security-layer-model_v0.8.md` (proposed, not accepted)

## What this document is

The exact normative text for five amendments to the **proposed** v0.8 cut, arising from
`access-engine`'s boundaries review (`FLEX-WP-0030`) and the custodian's estate-wide
sweep. It is the reviewable unit: each amendment can be argued on its own wording here
before anything touches the cut.

These land **in v0.8 before the acceptance flip**, not in a v0.9 set after it. v0.7 stays
`accepted` and in force, unpatched. The reasoning is `GH-DEC-2026-019`: §11 is the section
whose subject is mechanical checkability, and accepting it while its own check cannot make
two conforming runs agree would make the accepted text the defective one.

**Each amendment already governs its implementers** through the decision record named as
its authority. This document moves them into the statute; it does not decide them again.

| # | Section | Authority | Task |
| --- | --- | --- | --- |
| A9 | §3 | `GH-DEC-2026-017` §2, §3 | T01 |
| A10 | §4, §11 | `GH-DEC-2026-018` §5 | T02 |
| A11 | §11 | `GH-DEC-2026-017` §1, §4 | T03 |
| A12 r2 | §11 | `GH-DEC-2026-017` §5, `GH-DEC-2026-020` | T04 |
| A13 | §4 | `access-engine` B5, `FLEX-WP-0020` | T05 |

**A note on A2.** The clause A10 repairs is `gate-house`'s own, added as `A2` of the v0.8
set on 2026-09-06 and again in `A7`. It named a §4 property §4 does not carry, and nobody
on the round caught it — including the two rounds of review it passed through. That is the
closing finding of the v0.8 round arriving against the amendment that closed it, and it is
the reason this set exists rather than a v0.9.

---

## A9 — §3, the layer vocabulary stated once, as tokens (T01)

**Why.** §3 does not state a vocabulary. It states a table whose first column reads
`Taxonomy / Tooling / Engines / Staff` — `Engines` **plural** — while §4's Layer column
reads `Engine`. Every implementer has inferred the token set from two tables that
disagree, and `access-engine`'s validator inferred three tokens rather than four, omitting
`Taxonomy`: the layer this standard itself occupies, catalogued twice in §4. A vocabulary
a checker must infer is not a vocabulary, and the only executable statement of it in the
estate came to stand in for canon.

The divergence is not cosmetic and A11's precedence rule does not reach it: **a run built
from §3 and a run built from §4 disagree about all eight engine rows**, which is B1's shape
inside the standard rather than inside a repository. Raised by `railiance-master`, with the
citations, against the finding that had named it non-conformant.

**Add to §3, immediately after the layer table:**

> **The vocabulary is these four tokens, and it is closed:**
>
> ```
> Taxonomy    Tooling    Engine    Staff
> ```
>
> A layer declaration (§11) carries exactly one of them. **Comparison is ASCII
> case-insensitive** and a conformance run MUST fold case before comparing: two spellings
> of `Engine` do not describe two boundaries, and a check that reports nine findings about
> capital letters has made the one real disagreement unfindable. The spellings above are
> canonical for new and changed declarations; a lowercase declaration is **conforming**,
> not tolerated.
>
> A value outside the four is not conforming and does not name a tier this model has not
> enumerated. A fifth layer arrives by amending this section, argued by a repository that
> bears a cost under the four-layer cut — not by a repository declaring one.
>
> `Engines` appears in the table heading above for its plural reading; the token is
> `Engine`, as §4's Layer column carries it.
>
> A **role** is not a layer. §3.3's Engine roles and §6.4's PEP shape describe what a
> repository does within its layer, are carried in a separate `role:` key, and are not
> governed by this vocabulary. Ruled in `GH-DEC-2026-012` R2 and again in
> `GH-DEC-2026-017` §3.

**Authority.** `GH-DEC-2026-017` §2 and §3. Raised by `access-engine` as a casing finding
against nine repositories; converted by `the-custodian`'s estate-wide sweep into a finding
against the validator that reported it.

---

## A10 — §4 and §11, evidence sources are marked, not inferred (T02)

**Why.** §11 requires *"every repository catalogued in §4 as a source of evidence"* to
declare an emission guarantee. **§4 catalogues no such thing.** It has three columns —
repository, layer, role — and the `Evidence` role means custody, which is the opposite of
source. So the check requires a conformance run to decide for itself who is a source, two
paragraphs before it forbids a run to infer an event's class *"or the check becomes
circular"*. `access-engine` could not answer whether it is a source because the text does
not contain the answer.

**Add a column to the §4 catalog table**, `Evidence source`, carrying `yes` or `—`, and
mark `access-engine` `yes` per `GH-DEC-2026-018` §2. Other rows are marked as each
repository is assessed; an unassessed row carries `—` and **§11's check reports it as
unassessed rather than as conforming.**

**Add under the §4 table:**

> **Evidence source is a marking, not a reading.** A repository is a source of evidence
> where it **emits** events into the estate's evidence stream. Custody is disjoint from
> emission: holding a record never discharges any emitter's guarantee, and `audit-core`'s
> `Evidence` role is custody. The distinction is what `§9.6` rests on — an archive cannot
> prove a record was never sent, which has content only because the archive and the
> emitter are different parties.

**Replace §11's evidence-source check opening clause:**

> - every repository **marked in §4 as an evidence source** declares its **emission
>   guarantee** in its machine-readable layer declaration, **per event class** — a single
>   repository-level guarantee over a stream containing both a high-volume and a rare class
>   is an average, not a declaration, and will be satisfied by rate monitoring that cannot
>   see the rare event go missing; …

*(the remainder of the check — the load-bearing/attributive split, the volume/rare
detection rules, and the published-classification prohibition — is unchanged.)*

**Correct the count.** §11's closing sentence reads *"the §9.1 defect this standard has now
corrected four times."* With this amendment it is five, and §11 is the site of it twice. A
derived count inside a normative body is a derived artifact naming no source, which §11
itself forbids: **replace the count with** *"the §9.1 defect this standard has repeatedly
corrected; the instances are listed in §15."*

**Authority.** `GH-DEC-2026-018` §1 and §5. Raised by `access-engine`, which declined the
reading that favoured it and held the gap open as `G2` rather than closing it for itself.

---

## A11 — §11, which form governs, and what a run's scope is (T03)

**Why.** §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. Nine do,
and all nine disagree. Two conformance runs reading different files reach different answers
for nine repositories and both follow §11.

**Replace §11's "Declaration form" paragraph's second sentence and add after it:**

> Because prose cannot distinguish a declaration from a transcribed review, a declaration
> MUST carry a machine-readable form: **a `layer:` key in the repository's own `INTENT.md`
> frontmatter.** An equivalent declaration file MAY accompany it and is a **derived
> artifact** under this section's derived-artifact rule: it MUST be marked as derived, MUST
> name `INTENT.md` as what it derives from, and MUST agree with it. `INTENT.md` governs.
>
> This is not a preference between two files. This section already says a repository
> declares its layer in its own `INTENT.md`; the alternative form was added to give the
> declaration a machine-readable *form*, and was read as giving it a second *authority*.
>
> **A disagreement between the two forms is a finding in its own right** and MUST be
> reported rather than resolved away by precedence. Precedence says which value is the
> repository's answer; it does not say the disagreement did not happen. Where one
> appearance is reachable by two routes, the record says which route.
>
> **A conformance run MUST state its scope.** This section's obligations attach to
> estate-authored repositories **in §4**. A repository outside §4 may declare voluntarily
> using this form, and a voluntary declaration is welcome; it is not a §4 obligation and a
> run that grades it is over-scoped. A run over §4 and a run over every repository carrying
> a declaration answer different questions, and a report that does not say which it did
> cannot be acted on.

**Authority.** `GH-DEC-2026-017` §1 and §4. Raised by `access-engine` (`B1` as corrected,
2026-09-21), which mechanised a finding it had published unmechanically and thereby
falsified it; extended by `the-custodian`, whose sweep found the two declaring repositories
outside §4.

---

## A12 r2 — §11, a declaration carries no standard version, and a run states the version it checks against (T04)

**Revision note (r2, 2026-09-21).** A12 as first circulated said *"MUST NOT carry a
standard version"*, and every checker in the estate implemented it as *"no key named
`standard_version`"*. Thirteen repositories applied it and split on what it reached: a
version-bearing `standard:` path, a `companion_version`, and `standard_version` in stance
and claims maps. Its second paragraph also sent version-scoped state to a *"derived
conformance record"* that §11 obliges nobody to produce. `GH-DEC-2026-020` rules all four;
r2 states them in the statute. **Assent given to A12 as first circulated is to that text and
is asked again for r2**, not carried over.

**Why.** `access-engine` removed `0.7` from its own declaration, enforced the absence by test,
and asked that §11 say so generally rather than leave each repository to work it out. Every
sidecar in the estate carried `standard_version: "0.7"`, including `ops-warden`'s reference
form and the repositories that adopted it — so this was the reference form's field, not one
repository's habit. The r2 additions exist because a rule stated as a key name was satisfied
by key-name checkers that could not see the same pin under another name.

**Add to §11's "Declaration form" paragraph:**

> **A layer declaration MUST NOT carry a standard version.** The declared layer is a
> standing property of the repository and does not change when this standard is revised; a
> version in the declaration makes every revision read as though it invalidated every
> declaration. That is the confusion this standard's own `assented_by` note exists to
> prevent: assent records assent to a **boundary**, given at the version named, and is not
> assent to the current text.
>
> **The rule reaches content, not a key name.** The declaration, for this purpose, is every
> key of the `INTENT.md` frontmatter and every key of a derived declaration file. No key or
> value of either carries a version of this standard **or of its companion** — including a
> version carried in a path or file name, such as a `standard:` key naming
> `…security-layer-model_v0.7.md`. Comments, and the version of a declaration file's own
> schema, are not versions of this standard and are not reached.
>
> **The rule reaches the declaration only.** A stance map, claims map, or evidence
> classification states a position on clause text, which is version-scoped as a layer is
> not, and it SHOULD carry the version of the text it answers; this rule does not apply to
> it and a conformance run MUST NOT apply it there.
>
> **Version-scoped state belongs to the conformance run.** Every run MUST state, in its
> output, the version or commit of this standard it checked against and its scope. A checker
> re-run on demand satisfies this by stating both on every run; no declaring repository is
> required to emit a durable conformance record. Where a run's output is **retained or
> relied upon**, the retained output is a derived artifact under this section's
> derived-artifact rule, and the party retaining it carries the version or commit it was
> derived at.
>
> If a future revision changes §3's vocabulary such that a declared token no longer denotes
> the same layer, declarations do **not** silently retarget: that revision carries a
> re-declaration round, run in this standard's authoring voice. A per-file version pin would
> not have caused anyone to re-read anything.

**Authority.** `GH-DEC-2026-017` §5 — cited by its body section; the decision's
`rationale:` part numbering is a summary and is not cited (`GH-DEC-2026-020` §5) — and
`GH-DEC-2026-020` §1–§4. Raised by `access-engine` against its own file, which is where this
whole review started; the reach questions raised by `approval-engine`, `ops-warden` and
`informed-decision` in applying it, and collected with measured counts by `the-custodian`.

---

## A13 — §4, the `access-engine` coordinate is pending, not broken (T05)

**Why.** v0.8 names `access-engine` in §4, §13.1 and §17. The repository, runtime,
namespace, images and API vocabulary are still `flex-auth` per `FLEX-DEC-2026-013`; the
rename is ruled and sequenced under `FLEX-WP-0020` and has not landed. Neither side is
wrong — canon named the end state — but a reader of v0.8 cannot resolve the repository it
keeps naming, and `reuse-surface` hit the 404 independently. `access-engine` asked for one
line and offered to ping when the rename lands.

**Replace the existing §4 note:**

> `access-engine` is the ruled name for the repository currently called `flex-auth`; both
> denote the same authority until the governed rename completes. **The coordinate is
> pending, not broken:** the repository resolves at `flex-auth` today, the rename is ruled
> and sequenced under `FLEX-WP-0020`, and runtime names remain `flex-auth` by
> `FLEX-DEC-2026-013` after it lands. Execution conditions are recorded in that workplan,
> not here.

**Authority.** `access-engine` `B5`; no gate-house ruling required — this is a resolvability
note, and the substance is already ruled in the owning repository.

---

## Not in this set

- **The `role:` vocabulary**, its case-sensitivity, and whether it is closed. Raised by the
  same survey and deferred: §3.3 and §6.4 state roles in two places, and the token set needs
  the same repair A9 makes for layers before a ruling would mean anything.
- **Whether `informed-decision` becomes a §4 catalog row.** It holds a ruled boundary
  (`GH-DEC-2026-012`), is PEP-shaped, and sits on the approval path. Adding a row is a canon
  change and a repository is *asked*, not enrolled — §11's own rule that a layer stated about
  a repository by another is not a declaration applies to catalogue membership at least as
  strongly. Raised with them; carried as `GH-WP-0004-T06`.
- **Which other §4 rows are evidence sources.** A10 creates the column; the per-repository
  assessment is `GH-WP-0004-T02` and is not pre-empted by listing names here.
- **Any §9.5 change.** `kings-guard` has not returned its review and no finding has landed
  against §9.5. Its absence is recorded in §14 as *not claimed* and is not a condition on the
  flip (`GH-DEC-2026-019` §4).