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.3 — A11 r2 and A12 r3 (GH-DEC-2026-021); both re-circulated for assent. 0.2 revised A12 as A12 r2 (GH-DEC-2026-020) 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 r2	§11	GH-DEC-2026-017 §1, §4, GH-DEC-2026-021 §5	T03
A12 r3	§11	GH-DEC-2026-017 §5, GH-DEC-2026-020, GH-DEC-2026-021 §1	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 r2 — §11, which form governs, and what a run's scope is (T03)

Revision note (r2, 2026-09-21). kings-guard (KG-DEC-2026-005) found that the scope paragraph names two estate scopes and is silent on the scope most copied checkers actually run: one repository grading itself. r2 adds one sentence admitting it (GH-DEC-2026-021 §5). Nothing else changes. Assent given to A11 as first circulated is to that text and is asked again for r2.

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. A run over a single repository is a permitted third scope: it names the repository and states whether that repository is in §4, and a run over a repository outside §4 reports a voluntary result, not §4 conformance.

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 r3 — §11, a declaration carries no standard version, and a run states the version it checks against (T04)

Revision note (r3, 2026-09-21). r2's "no key or value … carries a version" literally reached a revision cited in prose, such as "Outside §5 by the v0.5 scope rule". Eight declarations carry such a citation, gate-house's own among them. approval-engine and kings-guard raised it, and kings-guard proposed the wording adopted here. GH-DEC-2026-021 §1 rules the narrow reading. r3 adds one sentence (marked below) and changes nothing else. The narrow reading benefits gate-house, which is disclosed in the ruling, and it is therefore not self-approved. Assent to r2 is asked again for r3.

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. (r3) A version is reached when it is carried as a pin: in a key naming a version of this standard or its companion, in a path or file name, or in the value of a key that identifies this standard or its companion. A citation of an earlier revision in a record's prose, stating where a rule came from, is provenance and is 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, and GH-DEC-2026-021 §1 for r3. 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).