gate-house/docs/amendments/v0.8-section-11-declaration-amendments.md

# 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.1
**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 | §11 | `GH-DEC-2026-017` §5 | 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 — §11, a declaration carries no standard version (T04)

**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 carries `standard_version: "0.7"`, including `ops-warden`'s
reference form and the seven repositories that adopted it — so this is the reference form's
field, not one repository's habit.

**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.
>
> Version-scoped state belongs in the **derived conformance record**, which under this
> section's derived-artifact rule already MUST name what it derives from and carry 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. Raised by `access-engine` against its own file, which
is where this whole review started.

---

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