coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rule the six §11 declaration questions, and hold the v0.8 flip on them

Browse source 
access-engine's boundaries review (FLEX-WP-0030, B1 corrected 2026-09-21) and
the custodian's estate-wide sweep put six §11 interpretation questions here.
All six are questions about what §11 means, and gate-house authors §11.

GH-DEC-2026-017 — the layer declaration. INTENT.md governs and a sidecar is a
derived artifact that must agree; a disagreement between the two forms is a
finding in its own right and is reported rather than resolved away. The §3
vocabulary is case-insensitive for comparison and closed, and it has FOUR
tokens: access-engine's validator omits Taxonomy, so railiance-master is
conforming and the validator carries the defect. informed-decision's `surface`
is not a layer; its own file already reasons to Staff. Both off-vocabulary
repositories are outside §4 and §11 does not grade them. A declaration carries
no standard version — and that field is the reference form's, not one
repository's habit. gate-house declares Staff in INTENT.md frontmatter in this
commit; the prose line was never a declaration under the paragraph this
repository wrote.

GH-DEC-2026-018 — access-engine is a source of evidence for the decision
record, against its own interest and as it asked. Custody is never source:
collapse them and §9.6 is incoherent. It owes a declaration, has none, and is
non-conforming on §11 today; the right register is a declared gap with a date.
The class inventory stays access-engine's to publish — §11's prohibition on
inferring class binds a ruling as hard as a runner. Under it, §11 names a §4
property §4 does not carry, which is the finding under the finding, and the
clause is gate-house's own A2 from twelve days ago.

GH-DEC-2026-019 — the v0.8 acceptance flip stays held and these join the
existing hold rather than a follow-on amendment. The round closed by finding
that every substantive finding against v0.8 was a correct rule satisfiable
without doing what it requires; §11 is now that failure pointed at §11.
Bounded by three stated closing conditions. v0.7 stays accepted and in force,
so the hold costs documentation currency and nothing else — stated as the
reason it is affordable, not as an argument that holds are free.

A candidate property is recorded and deliberately not numbered A-18: a
conformance check each repository runs only against its own files cannot
establish an estate property. One instance, and no repository bearing a cost
under it has argued it yet.

Amendments A9–A13 drafted; GH-IN-0003 and GH-WP-0004 carry the round.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
This commit is contained in:
tegwick 2026-09-21 02:14:48 +02:00
parent b7dfb84c0b
commit def0af2ce7
5 changed files with 1206 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

38
INTENT.md
View file

@ -1,3 +1,41 @@
---
# NetKingdom security layer declaration — §11.
#
# This is the declaration. The prose "**Layer:** Staff" below is not, and has not
# been since §11 required a machine-readable form; it is exactly what §11's
# declaration-form paragraph says does not count, written by the repository that
# wrote the paragraph. Raised by access-engine (FLEX-WP-0030, B2) and ruled in
# GH-DEC-2026-017 §6.
#
# No layer.yaml accompanies this file, by GH-DEC-2026-017 §1: INTENT.md governs
# and a sidecar is a derived artifact. No standard version appears here, by
# GH-DEC-2026-017 §5: the declared layer is a standing property and does not
# change when the standard is revised. Version-scoped state belongs in the
# derived conformance record.
layer: Staff
role: —
repository: gate-house
declared_by: INTENT.md
declared_at: "2026-09-21"
ruling: GH-DEC-2026-017
# §5 — Staff MUST NOT hold a direct Tooling client. Empty is a claim, not an
# omission: gate-house holds no OpenBao, key-cape or cluster client. Its
# artifacts are specifications, decisions, workplans and tasks.
tooling_contacts: []
# §11 — non-Tooling clients recorded so the check is total.
non_tooling_clients:
- target: state-hub
layer: not-catalogued
rationale: >-
Work records, intakes, decisions and progress events. Outside §5 by the
v0.5 scope rule — "Tooling-layer system" means a §4 Tooling row, and
state-hub is not one. Recorded, not policed.
declared_shapes:
"5.1": []
"5.2": []
"5.3": []
---
# Gate House — INTENT
**Repository:** `gate-house`

717
decisions/decisions.md
View file

@ -2668,3 +2668,720 @@ to invent the rule. Carried by `informed-decision`, which enforces the property
does not need the ruling for itself, and asked anyway because a property held by one
component is not a property of the object. Neither repository asked for anything that
benefits it.
## GH-DEC-2026-017 — The layer declaration: `INTENT.md` governs, the §3 vocabulary is closed and case-insensitive, and a declaration carries no standard version
```yaml
id: GH-DEC-2026-017
kind: decision
title: The layer declaration — INTENT.md governs, the section 3 vocabulary is closed
and case-insensitive, and a declaration carries no standard version
status: resolved
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source_note: access-engine (flex-auth) docs/conformance/boundaries-review.md, FLEX-WP-0030,
B1 as corrected 2026-09-21, plus B2 and B4; the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md
for the three repositories outside the surveyed set; GH-IN-0003
requested_dispositions:
- approved
- revised
- rejected
affects:
- gate-house
- net-kingdom
- access-engine
- audit-core
- approval-engine
- maturity-engine
- secrets-engine
- user-engine
- tenant-engine
- zone-engine
- ops-warden
- ops-mason
- kings-guard
- key-cape
- whitehat-security
- informed-decision
- railiance-master
decided_by: Bernd Worsch
rationale: 'Section 11 permits a layer: key in INTENT.md frontmatter OR an equivalent
declaration file and does not say which governs when a repository carries both.
Nine repositories carry both and disagree in all nine, by casing only. Ruled in
four parts. (1) INTENT.md governs. Section 11 already says a repository declares
its layer in its own INTENT.md; the file alternative was added to give the declaration
a machine-readable form, not a second authority. A sidecar is therefore a derived
artifact under section 11 own derived-artifact rule and does not govern. (2) The
section 3 vocabulary is case-insensitive for comparison and a conformance run MUST
ASCII case-fold before comparing; the canonical spelling is the section 4 column
form. A check that fails eight of ten on orthography detects nothing about boundaries
and buries the one disagreement it exists to find. (3) The vocabulary is closed
and has FOUR tokens: Taxonomy, Tooling, Engine, Staff. access-engine validator admits
only three, omitting Taxonomy, so railiance-master Taxonomy is conforming and the
validator carries the defect. informed-decision surface is not a layer and is corrected
to Staff with role pep-shaped, which its own file already reasons from. Both repositories
are outside the section 4 catalog, so neither is a section 11 non-conformance; a
conformance run that grades non-catalogued repositories is over-scoped. (4) A layer
declaration MUST NOT carry a standard version. The declared layer is a standing
property that does not change when the standard is revised, and a version in the
declaration makes every revision read as invalidating it; version-scoped state belongs
in the derived conformance record, which already MUST carry the version it was derived
at. gate-house own INTENT.md gains frontmatter with layer: Staff in the same commit
as the ruling, because a doctrine owner ruling on an obligation it has not discharged
is the section 9.1 defect pointed at itself.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
state_hub_decision_id: ""
```
## Context
`access-engine` set out to remove a version pin from its own `INTENT.md`, read what the
declaration asserts, and found four repositories that had never declared one. It then
published a §11 finding produced by a shell pipeline that could not say which file a
value came from — inside a review whose thesis is that a mechanical check nobody can
re-run is an assertion. It rebuilt the finding as a command with a receipt, ran it, and
the run **falsified the finding it was built to reproduce**.
That sequence is the reason this ruling exists at all, and it is worth saying before the
ruling rather than after. The corrected B1 is a stronger finding in a different class,
and it was reachable only because the repository that published the weak one went back
and mechanised it against itself.
The custodian then swept every repository in the estate carrying a declaration rather
than the twelve `access-engine` holds boundaries with, and found two more values —
`surface` and `Taxonomy` — that `access-engine`'s validator rejects. That sweep changes
one of this ruling's four parts and is credited where it does.
The declarations were re-verified here before ruling, from the repositories' own files,
rather than taken from either report.
## Decision
### 1. `INTENT.md` governs. A declaration file is derived and does not govern
**Where a repository carries both forms, the `layer:` key in its `INTENT.md` frontmatter
is the declaration.** A `layer.yaml` or equivalent is a **derived artifact**: it MUST be
marked as derived, MUST name `INTENT.md` as the artifact it derives from, and MUST agree
with it.
The ground is not a preference between two files. §11 already states the rule in its own
first paragraph — *"a repository the estate authors declares its layer in its own
`INTENT.md`"* — and the declaration-form paragraph was added for a different reason: that
**prose cannot distinguish a declaration from a transcribed review**, so the declaration
needs a machine-readable form. That paragraph gave the declaration a *form*; it was read
as giving it a second *authority*. Those are different things, and the second is what
produced nine disagreements nobody noticed.
This also settles what a conformance run does. It reads `INTENT.md`. Where a sidecar
exists it reads that too — not to choose between them, but because **a disagreement
between the two is itself a finding** 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.
That second clause is A-16 in its plainest form. *"This repository is an Engine"* is an
appearance reachable by two routes, and until now the record could not say which route a
given checker took. Precedence alone would make the estate agree by making eight of the
nine disagreements invisible, which is the same shape as the check that cannot disagree
with anyone.
Eight repositories already declare `declared_by:` in their sidecar. Six of the eight name
`INTENT.md` or an ADR rather than the file itself, so most of the estate has been
treating the sidecar as derived in substance without the rule saying so.
### 2. The §3 vocabulary is case-insensitive; a conformance run MUST fold case
**Comparison is ASCII case-insensitive.** The canonical spelling for new and changed
declarations is the §4 catalog column form — `Taxonomy`, `Tooling`, `Engine`, `Staff` —
and a lowercase declaration is **conforming**, not tolerated.
`access-engine` offered to accept exactly this outcome and to change its own validator,
which is the disposition it argued for when its finding was still about casing and did
not withdraw when the finding changed shape. The offer is taken.
The reason is what §11 is for. Two spellings of `Engine` do not describe two boundaries.
A check that reports nine findings about capital letters and one about a real layer
disagreement has made the real one unfindable, and finding-fatigue is not a stylistic
cost — it is the failure mode of a mechanical check, which is the thing §11 claims to be.
**No repository is asked to re-spell anything.** The nine disagreements do not become
conformances by being forgiven; under §1 they were never disagreements about a layer.
**Related defect, recorded because it caused this.** §3 does not state a vocabulary. It
states a table whose header column reads `Taxonomy / Tooling / Engines / Staff` — with
**`Engines` plural** — while §4's column reads `Engine`. Every implementer has had to
infer the token set from two tables that disagree, and one of them inferred three tokens.
A vocabulary a checker must infer is not a vocabulary. §3 gains an explicit normative
token list (A9).
### 3. The vocabulary is closed, and it has four tokens — not three
**Closed.** A declaration whose value is outside `{Taxonomy, Tooling, Engine, Staff}` is
not conforming, and does not name a tier the model has not enumerated. The four layers
are the model's whole claim about how the estate is cut; a fifth arrives by amending §3,
in this repository's voice, not by a repository declaring one.
**But `Taxonomy` is in it.** `access-engine`'s validator admits `{Staff, Engine, Tooling}`
and rejects `Taxonomy`, which §3.1 defines, §4 catalogues twice (`info-tech-canon`,
`net-kingdom`), and this standard is itself an instance of. **`railiance-master` is
conforming and the validator carries the defect.**
This is the part of the finding that inverted on inspection, and how it inverted is worth
recording. The custodian's sweep reported `Taxonomy` as outside the vocabulary. It is not
— it was outside *a validator*, and the validator was read as the vocabulary because it
was the only executable statement of one. That is §11's derived-artifact rule inverted:
an artifact derived from canon came to stand in for canon, precisely because canon left
the token set to be inferred (§2's related defect). The custodian was right to raise it;
one of the two instances it raises is a finding against the checker.
**Found twice, independently, and the second finder is the repository it was a finding
against.** `railiance-master` corrected the custodian's record with the citations — §3.1,
§4, §7, §17 — and the custodian recorded its first reading as wrong in the circulated
document rather than quietly amending it. This ruling was drafted from the first version
and re-verified against §3.1 before it was issued, so it reached the same place by the
other route; the correction is credited because it arrived first and because it was made
by the party the finding accused.
**The §3-versus-§4 divergence is a second defect, and precedence does not reach it.**
`railiance-master` also observes that its `Taxonomy` matches §3's table spelling exactly,
so measured against §3 the nine lower-casing sidecars are the divergent ones, while
measured against §4 the disagreement is `Engines` versus `Engine` for every engine
repository in the estate. A run built from §3 and a run built from §4 disagree about eight
rows. That is B1's shape one level further in — two faithful readings of one standard —
and §1's precedence rule does not touch it, because it is a disagreement *inside the
standard* rather than inside a repository. §2 and A9 close it by stating the vocabulary
once, as a token list, rather than by choosing between two tables.
**The two off-vocabulary cases are ruled apart, as the custodian asked.** They do not
behave alike: `Taxonomy` is a conforming value reported by a defective checker, and
`surface` is a repository naming a tier the model does not have. Nothing in the disposition
of one carries to the other.
`access-engine` is asked to add `Taxonomy` to its validator. That is not a §4 scope
change — a NetKingdom checker run estate-wide will meet Taxonomy repositories, and
rejecting the layer this standard occupies is not a defensible default.
**`surface` is not a layer.** `informed-decision` declares `layer: surface, role:
pep-shaped`. Its correct declaration is **`layer: Staff`, `role: pep-shaped`**, which its
own file already reasons from two ways: it writes *"§5 applies to Staff. This is a
browser-facing surface with no Tooling contact,"* and `GH-DEC-2026-012` R1 ruled it is
PEP-shaped and **not** an Engine, which under §3's determinism cut leaves Staff.
`ops-mason` and `ops-warden` are the precedent: `Staff` in the layer column,
`PEP-shaped` in the role column. The correction is `informed-decision`'s to make.
`role:` is not part of this vocabulary and is not closed by this ruling. §3.3 enumerates
the Engine roles; `PEP-shaped` is a §6.4 shape; `GH-DEC-2026-012` R2 already holds that
shapes are not layers. The layer field takes a layer.
### 4. Both off-vocabulary repositories are outside §4, and §11 does not grade them
`informed-decision` and `railiance-master` are **not §4 catalog rows**. §11's obligation
attaches to *"every estate-authored repository in §4"*, so neither can be a §11
non-conformance, and an estate-wide run that grades them is over-scoped. `railiance-master`
says so in its own file — *"not a NetKingdom §4 catalog row… Railiance operations
Taxonomy"* — and declared anyway.
**A voluntary declaration is welcome and is not thereby enrolled.** The correct report for
both is *declared voluntarily, outside catalog scope*, and for `informed-decision`
additionally *value not in the vocabulary, correction identified*. Treating a volunteer's
declaration as a non-conformance is the fastest way to stop getting volunteers, and it is
also just wrong about who §11 binds.
**A conformance run MUST state its scope.** 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 — the same defect as a survey that does not record which file a
value came from, one level up.
**Not ruled: whether `informed-decision` should become a §4 row.** It holds a ruled
boundary, is PEP-shaped, and sits on the approval path, which is a real argument. Adding a
catalog 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 an open item of
the amendment round (A11).
### 5. A layer declaration MUST NOT carry a standard version
`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. **Ruled
as asked, and the general form is stated here.**
A layer declaration asserts a **standing property**: which layer this repository is. That
property does not change when the standard is revised. A version in the declaration makes
every revision read as though it invalidated every declaration, which is the same
confusion this standard's own frontmatter note exists to prevent — *assent records assent
to a boundary, given at the version named, and is not assent to the current text*.
`access-engine` is Engine/PDP at v0.6, v0.7, v0.8 and after.
**Version-scoped state belongs in the derived conformance record**, which under §11's
derived-artifact rule already MUST name what it derives from and carry the version or
commit it was derived at. That artifact exists; the version has a home.
**This is not one repository's habit — it is the reference form.** Every sidecar in the
estate carries `standard_version: "0.7"`, including `ops-warden`'s reference form and the
seven repositories that adopted it. So removing the field is a change to the reference
form, and `ops-warden` is asked to make it there rather than each adopter deciding.
`access-engine` found this in its own file and did not look at anyone else's; the field's
real distribution only appears from the sweep.
**Declined: keeping the field "for information".** A field that is present will be
branched on. The reason to remove it is that it is *readable as* a validity condition,
and a version kept as decoration is still readable as one.
**What happens when §3 changes.** If a future version changed the vocabulary so a declared
token no longer denoted the same layer, declarations do **not** silently retarget. That is
a re-declaration round, run by this repository in the standard's own voice — an explicit
canon obligation, not a per-file pin that would have made nobody re-read anything anyway.
### 6. `gate-house` declares `Staff`, in this commit
`access-engine` raised it plainly rather than politely: *"a doctrine owner that has not
discharged its own §11 obligation is the §9.1 defect pointed at itself, which is the
argument you accepted from us four times at v0.8."*
That is correct, it needs no ruling, and the appropriate response to it is the file rather
than a paragraph about the file. `gate-house/INTENT.md` gains frontmatter carrying
`layer: Staff` in the same commit as this record. Under §1 it writes **no** sidecar: the
governing form is the one §11 names first, and the repository ruling that the sidecar is
derived should not need a derived copy to be legible.
The prose line `**Layer:** Staff` has stood in `INTENT.md` since v0.1 and was believed to
be the declaration. It is exactly what §11's declaration-form paragraph says does not
count, written by the repository that wrote the paragraph.
`key-cape`, `ops-mason` and `net-kingdom` remain undeclared and each owes its own. Each is
told; none is declared for. `net-kingdom`'s is the odd one — it is the publisher of the
standard requiring it, and `Taxonomy` is its §4 row.
## What this does not rule
- **Not ruled: the `role:` vocabulary**, its case-sensitivity, or whether it is closed.
Raised by the same survey; deferred because §3.3 and §6.4 state roles in two places and
the token set needs the same repair §3's does before a ruling would mean anything.
- **Not ruled: what a conformance run does with a repository outside §4 that declares.**
§4 reports it as out of scope; whether a second, estate-wide report exists is
`maturity-engine`'s and the runner's, not doctrine's.
- **Not ruled: the sidecar's schema** beyond the derived marking and the absence of a
version. `ops-warden`'s form is the estate's and stays `ops-warden`'s.
## Reversal condition
§1 reverses if a repository is found for which `INTENT.md` cannot carry frontmatter — the
§9.1 shape, an obligation the holder cannot discharge. No such repository is known; the
three checked without frontmatter are three that can trivially gain it.
§2 reverses if two layer tokens are ever introduced that differ only in case, which would
be a defect in §3 rather than a reason to restore case-sensitivity.
§3's closure reverses on an argued amendment to §3, from a repository that bears a cost
under the four-layer cut. `informed-decision`'s `surface` is not that argument — it is an
undeclared fifth tier, and the repository's own file gives the Staff reasoning.
## Provenance
Raised by `access-engine` (`FLEX-WP-0030`), which found its own version pin, generalised
the question rather than fixing its file, published a finding it then mechanised and
falsified, corrected it inside a day, and put the correction to everyone who received the
original — including the three repositories the original had not reached. It also raised
`gate-house`'s own omission against `gate-house`, which is the finding it had least reason
to raise and the one this ruling is most improved by.
Extended by `the-custodian`, whose estate-wide sweep supplied both off-vocabulary values,
the observation that the two-generators reading does not hold estate-wide, and therefore §3
— including the half of §3 that is a finding against the reporting validator rather than
the reported repositories, and which it then corrected against itself on
`railiance-master`'s citation, in the circulated document, before this ruling issued.
`railiance-master` supplied that correction with the citations and asked for nothing. It is
the only repository in this record that was reported as non-conformant, was not, and said so
with the sections rather than with an objection.
`ops-warden` supplied the reference form eight repositories adopted, which is why §5 is a
single change rather than eight.
## GH-DEC-2026-018 — `access-engine` is a source of evidence for the decision record; custody is never source, and §4 must mark sources rather than leave the class to be inferred
```yaml
id: GH-DEC-2026-018
kind: decision
title: access-engine is a source of evidence for the decision record; custody is never
source, and section 4 must mark sources rather than leave the class to be inferred
status: resolved
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source_note: access-engine docs/conformance/boundaries-review.md B3, held open as its
declared gap G2; audit-core holds the other half; GH-IN-0003
requested_dispositions:
- approved
- revised
- rejected
affects:
- gate-house
- net-kingdom
- access-engine
- audit-core
- approval-engine
- kings-guard
- informed-decision
decided_by: Bernd Worsch
rationale: 'Section 11 requires every repository catalogued in section 4 AS A SOURCE
OF EVIDENCE to declare class, cadence and detection surface, and says a source declaring
none is not conforming. access-engine produces the decision record, declares no emission
guarantee, and asked whether it is a section 4 source or only the producer of an artifact
audit-core is the source of. Ruled against access-engine on the substance and against
the check on the form. (1) A custodian is never the source of what it holds. audit-core
role is Evidence, which is custody; reading it as the source of records it did not emit
would make section 9.6 incoherent, because the archive that cannot prove a record was
never sent would be the same party as the one that would have sent it. (2) access-engine
is therefore a source, and the decision record is the clearest case in the estate: a
denial is the paradigm load-bearing event section 9.6 names, and a denial is exactly the
event an adversary most wants missing. It owes a declaration and does not have one, so it
is non-conforming on section 11 today. The correct state is a declared gap with owner,
blocker and review date, promptly; gate-house is not grading, it is naming which register
the fact belongs in. (3) The classification is per event class and is access-engine own to
publish. Section 11 forbids a conformance run to infer class from event name, payload or
observed rate, and that prohibition binds this ruling as much as a runner. (4) Section 11
names a section 4 property that does not exist: section 4 catalogues layers and roles and
marks no repository as a source of evidence, so the check requires a run to decide for
itself who is a source, which is the circularity section 11 forbids one level down.
Section 4 gains an evidence-source marking.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
state_hub_decision_id: ""
```
## Context
`access-engine` put the question and declined the answer that favours it:
> The unclear boundary: are we a §4 source of evidence, or only the producer of an
> artifact `audit-core` is the source of? We are not answering that alone and we are not
> taking the flattering reading.
It recorded the gap as `G2` in its own conformance record and holds it open until this
repository rules *and* `audit-core` confirms its half. That is the second time this month
a repository has referred up a question whose convenient answer was available to it, and
it is the reason the question is answerable rather than settled by whoever moved first.
## Decision
### 1. A custodian is never the source of what it holds
**`audit-core` is not the source of the decision record.** Its §4 role is `Evidence`, and
§4 spells that role as *custody, retention, integrity verification, export*. Custody is
what you do with a record that arrived; a source is what makes one arrive.
The fork `access-engine` offered — *only the producer of an artifact `audit-core` is the
source of* — is not available, and the reason is §9.6's own load-bearing sentence. The
whole section rests on the fact that **an append-only archive cannot prove a record was
never sent**. That statement has content only because the archive and the emitter are
different parties. Collapse them and §9.6 is incoherent: the custodian would be the source
of records it never received, a suppressed record would have no one to attribute the
suppression to, and the residual the section exists to state — *adversarial omission at a
compromised source, prevented by nothing in this model* — would have no source to be
compromised.
So the rule generalises past this pair: **evidence custody and evidence emission are
disjoint obligations, and holding one never discharges the other.** No repository's
emission guarantee is satisfied by `audit-core` holding what it sent.
### 2. `access-engine` is a source of evidence, and the decision record is the clearest case in the estate
§17 moved the decision-record schema to `access-engine` on the ground that it is *"the one
thing in the estate only `access-engine` produces"* — an argument `access-engine` made
against its own interest, to take work on. The same fact answers this question, and this
time it costs rather than pays.
The decision record is not marginal evidence. **A denial is one of the three events §9.6
names as the paradigm load-bearing kind** — *"an approval revocation, a containment
action, a denial"* — and the section's own reasoning is that the negative event is exactly
what an adversary most wants missing, and that it is rare by nature, which is where rate
monitoring is the wrong instrument and the stakes are highest.
The estate has controls that read decision evidence. `GH-DEC-2026-010` requires a PEP to
be able to attribute a decision to `access-engine`. `kings-guard` evaluates streams and
raises silence findings. `informed-decision` declares its inherited gap against the
decision path. Every one of those reads a record `access-engine` emits, and none of them
can tell a quiet period from a suppressed one without a declared cadence.
**`access-engine` owes an emission guarantee, declares none, and is therefore not
conforming on §11 today.** Recorded in those words because it asked for the unflattering
reading and because softening it would make the register useless for the next repository.
### 3. The right register for that fact is a declared gap, and that is not a courtesy
§11's four states exist for this. An undeclared violation is *"anything else"* — the state
you are in when nobody has said. `access-engine` has said, publicly, in its own conformance
record, before anyone asked it to, and named the review that found it. **That is a declared
gap the moment it carries owner, blocker and review date**, and a declared gap is tracked
non-conformance, not a clean bill.
`G2` currently says *unruled*. It is now ruled, so `G2` closes as a question and reopens as
a gap of the ordinary kind, with a date. The distinction matters under A-17: this gap fails
closed on its distinguishing case — a stream with no declared cadence produces no silence
finding, so the failure is a **missed detection**, never a manufactured permission, which
is §9.6's §8-asymmetry payoff and the reason this is a gap a register can hold rather than
a permission.
### 4. The class inventory is `access-engine`'s to publish, and this ruling does not supply it
§11 is explicit: *"which class an event falls in, and whether it is rare, is the source's
published classification: a conformance run is supplied that inventory and MUST NOT infer
it from an event name, payload, or observed rate, or the check becomes circular."*
**That prohibition binds a ruling at least as hard as it binds a runner.** So this record
does not classify the decision record, and specifically does not rule that denials are rare
and allows are volume, however obvious that looks from here. What it rules is:
- the declaration is **per event class**, not per repository — a single repository-level
guarantee over a stream containing both a high-volume allow and a rare denial is not a
declaration, it is an average, and it will be satisfied by rate monitoring that cannot
see the denial go missing;
- `access-engine` publishes the inventory and the classification, under
`net-kingdom`'s `emission-cadence-security-profile_v0.1.md`;
- §11's consequences then follow mechanically: a **rare** load-bearing class MUST carry
heartbeat **and** reconciliation, not either alone, and MUST NOT be covered by rate
monitoring.
`approval-engine`'s `cadence.yaml` is the reference instance and the form is already
drafted in `gate-house/docs/contracts/approval-emission-detection.md`. `access-engine` is
not asked to invent a shape.
### 5. §11 names a §4 property that does not exist, and that is the finding under the finding
The check reads *"every repository catalogued in §4 as a source of evidence."* **§4
catalogues no such thing.** It has three columns — repository, layer, role — and the
`Evidence` role means custody, which §1 has just ruled is the opposite of source. So the
check, as written, requires a conformance run to decide for itself which repositories are
sources.
That is the same circularity §11 forbids two paragraphs later for event classes. §11 tells
a runner it MUST NOT infer an event's class, and in the same breath requires it to infer
the far larger fact of who is a source at all. `access-engine` could not answer the
question from the text because **the text does not contain the answer** — which is a
better account of B3 than *"the boundary is unclear."*
**§4 gains an evidence-source marking**, and each marked repository owns its class
inventory (A10). The alternative — restating the check in terms of *"any repository that
emits"* — was considered and refused: it moves the inference into the runner instead of
removing it, and it would make the source set something each runner computes rather than
something canon states. §11's own principle is that the classification is published, not
derived.
**This is the fifth time this standard has corrected the §9.1 defect in its own text**, and
§11 has now been the site of it twice. The count in §11 says four. It is wrong by one as of
this ruling, and A10 corrects it rather than leaving the number to drift — a derived count
inside a normative body is a derived artifact that names no source, which §11 also forbids.
## What this does not rule
- **Not ruled: `audit-core`'s half.** `access-engine` holds `G2` open until `audit-core`
confirms, and that is right. §1 tells `audit-core` what it is being asked to confirm — that
it is custodian and not source, and that it does not read its own custody as discharging any
emitter's guarantee — but a confirmation this repository writes on `audit-core`'s behalf is
exactly the §11 defect of a layer stated about a repository by another. Asked, not assumed.
- **Not ruled: which other §4 rows are sources.** `approval-engine` has declared;
`secrets-engine`, `user-engine`, `tenant-engine`, `zone-engine`, `maturity-engine`,
`ops-warden` and `ops-mason` have not been assessed here. The A10 marking is where that is
settled, repository by repository, and this ruling deliberately does not pre-empt it by
listing names — `access-engine` was ruled because it asked.
- **Not ruled: whether the decision record's emission must be atomic** with the decision.
§9.4 attaches that to load-bearing evidence and the class inventory is not published yet, so
the obligation is pending its own input rather than waived.
## Reversal condition
§2 reverses if a control is found that reads the decision record and would be unaffected by
its total absence — which would mean the record is attributive throughout, not that
`access-engine` is not a source. §1 does not reverse on that; it is structural.
§5's marking reverses if a §4 row turns out to be a source in one capacity and not another,
which a column cannot express. The repair would be a per-class marking, not a return to
inference.
## Provenance
Raised by `access-engine`, which produced the only artifact in the estate it is the sole
producer of, noticed that it had declared no guarantee for it, and refused the reading that
would have closed the question in its favour — then held the gap open in its own conformance
record rather than waiting to be asked. Every part of this ruling costs it something and none
of it was found by anyone else.
`audit-core` is the repository the §11 emission check exists because of, and is the one that
raised the general form so `GH-IN-0001` could not recur unnoticed. It is asked for its half
and has not yet been heard from on §11 at v0.8.
## GH-DEC-2026-019 — The v0.8 acceptance flip stays held, and the §11 declaration defects join the existing hold rather than a follow-on amendment
```yaml
id: GH-DEC-2026-019
kind: decision
title: The v0.8 acceptance flip stays held, and the section 11 declaration defects join
the existing hold rather than a follow-on amendment
status: resolved
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source_note: the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md,
reading offered and not pressed; gate-house docs/conformance/2026-09-06-v08-assent-round.md
round close; GH-DEC-2026-017, GH-DEC-2026-018
requested_dispositions:
- approved
- revised
- rejected
affects:
- gate-house
- net-kingdom
- audit-core
- kings-guard
- access-engine
- approval-engine
- ops-warden
- key-cape
- ops-mason
decided_by: Bernd Worsch
rationale: 'The v0.8 round closed with two circulated repositories not returning a text
review, and the section each was asked to attack therefore carrying no assent: kings-guard
on section 9.5, audit-core on whether section 11 emission wording lets a source imply
completeness. Publication and the acceptance flip were handed to net-kingdom on round
close and have not happened. Five section 11 defects have now been found from outside,
all of them in the text audit-core was asked to attack and did not. Held. The round own
closing finding was that every substantive finding against v0.8 was a correct rule a
careful implementer could satisfy without doing the thing it exists to require, and that
this repository is structurally prone to that failure. Section 11 is now that failure
pointed at section 11: a check calling itself mechanical that cannot make two conforming
runs agree, that names a section 4 property section 4 does not carry, and whose vocabulary
must be inferred from two tables that disagree. Accepting the version and amending it
immediately would make the accepted text the defective one, and would spend the one thing
the round produced. The hold is cheap because v0.7 is accepted and in force unpatched, so
nothing operational waits on it; that is stated as the reason it is affordable rather than
as an argument that holds are free. Bounded by three stated closing conditions so the hold
cannot become indefinite by inattention, and the conditions turn on returns and dated gaps
rather than on every repository being conformant, because a hold that waits for conformance
waits forever.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
state_hub_decision_id: ""
```
## Context
The custodian offered a reading and said it was not pressing it:
> The round should not close while §11's own mechanical check is ambiguous. A standard that
> cannot make two conforming conformance runs agree is not yet mechanically checkable in the
> sense §11 claims for itself.
The restraint is noted and the reading is adopted, with reasons of this repository's own —
because a hold adopted on someone else's reasoning is a hold nobody can argue about later.
## Decision
### 1. Held, and these join the existing hold
`GH-DEC-2026-017` and `GH-DEC-2026-018` produce five amendments to §11, §4 and §3. They land
**in v0.8 before the acceptance flip**, not in a v0.9 amendment after it. v0.7 stays
`accepted` and in force, unpatched, as it has since the round closed.
### 2. The reason is the round's own closing finding, arriving again
The v0.8 round closed by saying something narrower and worse than it opened with:
> **Every substantive finding was about a rule that read as satisfied by a check that did not
> satisfy it.** … That is a failure mode this repository is structurally prone to, because
> doctrine is graded on whether it is *right* and consumed on whether it is *checkable*.
§11 is now the sixth instance, and the first one where the rule that reads as satisfied is
the rule *about checking*. Its declaration-form paragraph reads as making the layer question
mechanical; nine repositories satisfy it while giving two answers. Its emission check reads
as scoped by §4; §4 carries no such scope. Its vocabulary reads as closed; it is stated in
two tables that disagree, and the estate's only executable statement of it omits a layer.
**Accepting the version and amending it afterwards would make the accepted text the defective
one** — and would do it in the section whose subject is that defect. The round's finding was
that only implementers can tell *right* from *checkable*. Three of them just did, from
outside, after the round closed. Flipping now would spend that.
### 3. The hold's cost is the reason it is affordable, and the reason is stated rather than assumed
v0.7 is accepted and in force. Nothing in the estate waits on v0.8's status: every ruling
since has been issued against v0.8 as proposed and implemented by repositories that did not
wait, and the four undeclared repositories owe their declarations under v0.7's §11 as much as
v0.8's.
**So the hold costs documentation currency and nothing else.** That is said plainly because
the opposite case is the one to guard against — if a hold blocked implementation, the
calculus would change and the right answer might be to accept and amend. It does not, so it
does not.
### 4. Three closing conditions, because an unbounded hold is not a decision
The flip proceeds when all three are met:
1. **The five amendments are drafted, circulated, and dispositioned** —
`docs/amendments/v0.8-section-11-declaration-amendments.md`, A9–A13, carried by `GH-WP-0004`.
2. **`audit-core` returns its §11 review, or declines in writing.** It was asked to attack
whether §11's emission wording lets a source imply completeness; five §11 defects have since
been found by others in that text. A written decline closes this condition — §14 records
*not claimed* rather than counting silence as assent, and the point is that the record says
which, not that assent is extracted. `kings-guard`'s §9.5 review is wanted on the same terms
and is **not** a condition here, because no finding has landed against §9.5.
3. **The four undeclared §4 repositories have each either declared or recorded a dated gap** —
`gate-house` (done in `GH-DEC-2026-017` §6), `key-cape`, `ops-mason`, `net-kingdom`.
**Condition 3 asks for a declaration or a dated gap, not for conformance.** A hold that waits
for every repository to be conforming waits forever and hands any one repository a veto. What
the flip needs is that the §11 check, once amended, has been *run* and its results are in a
register — which a declared gap satisfies exactly as well as a declaration does. That is §11's
own position on blocked-clean, applied to the standard's own acceptance.
### 5. What is not held
- **The rulings are in force now.** `GH-DEC-2026-017` and `GH-DEC-2026-018` bind from today
and do not wait on the flip. Repositories correcting declarations, adding `Taxonomy` to a
validator, or opening a dated gap should do it now; nothing here is a reason to wait.
- **`net-kingdom` keeps publication and the flip.** They were handed over at round close and
are not taken back. This record states a condition on the flip, in the standard's authoring
voice, and `net-kingdom` executes it.
- **The v0.8 text stands** except in §3, §4 and §11 as amended. No finding has landed against
anything else.
## A candidate property, deliberately not numbered
B1 as corrected is an instance of something more general: **a conformance check that each
repository runs only against its own files cannot establish an estate property.** It
establishes self-consistency, and self-consistency is compatible with the estate disagreeing
with itself in every repository at once — which is precisely what nine of nine turned out to
be. §11 said as much in `access-engine`'s words — *"a mechanical check that cannot disagree
with anyone is not yet mechanical"* — but said it about a symptom.
It is **not** recorded as `A-18`. One instance is not a rule; `A-16` and `A-17` were derived
from shapes that kept arriving, and `INTENT.md` holds that neither has graduated to canon
because the bar is that a repository **bearing a cost under it** has argued it. This has one
instance and no such argument. `informed-decision`'s observation applies — the repository that
bears a rule at its weakest point sees the unstated precondition — and the repository that
would bear this one is whoever has to build the estate-wide runner. Recorded here so a second
instance is recognised rather than met fresh.
## Reversal condition
The hold reverses if v0.8 acquires operational load — if a ruling, a contract, or an engine's
implementation comes to depend on v0.8 being `accepted` rather than proposed. §3's whole
argument is that it does not today.
Condition 2 reverses to *waived* if `audit-core` is unable to return a review for reasons of
capacity rather than disagreement, and says so. The condition is for the record to say which,
not to compel a review.
## Provenance
Raised by `the-custodian`, which held the only view from which the six questions were visible
as one set, offered its reading explicitly as not pressed, and stated that none of it was its
to rule. The estate-wide sweep it volunteered is what turned a nine-repository finding into a
fourteen-repository one and produced two of the five amendments.
The hold itself rests on `access-engine`'s and `audit-core`'s work rather than on the
custodian's reading: the first found the defects, and the second is the repository whose
unreturned review is the reason the defects were still there to find.

243
docs/amendments/v0.8-section-11-declaration-amendments.md Normal file
View file

@ -0,0 +1,243 @@
# 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).

51
intakes/intakes.md
View file

@ -163,3 +163,54 @@ created: '2026-09-05T23:28:11.977565Z'
updated: '2026-09-05T23:28:11.977565Z'
state_hub_intake_id: "01a08762-ab47-7163-8eeb-92c3cb909db3"
```
## GH-IN-0003 — Six §11 interpretation questions from the access-engine boundaries review
```yaml
id: GH-IN-0003
kind: intake
title: Six section 11 interpretation questions from the access-engine boundaries review
status: closed
origin: cross-repo
origin_ref: access-engine FLEX-WP-0030 docs/conformance/boundaries-review.md (published
2026-09-20, B1 corrected 2026-09-21); the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md
priority: high
owner: gate-house
requested_by: access-engine, the-custodian
lane: red
description: 'access-engine surveyed twelve security-relevant counterparts against section
11 and published five findings. the-custodian swept the whole estate, found fourteen
declarations rather than ten, and recorded that six of the nine resulting open questions
are gate-house''s because every one of them asks what section 11 means and gate-house
authors section 11.
The six: (1) which section 11 declaration form governs when a repository carries both an
INTENT.md layer key and a layer.yaml, and they disagree — nine repositories do, in all
nine; (2) whether the section 3 vocabulary is case-sensitive; (3) whether the section 3
vocabulary is closed, given informed-decision declares surface and railiance-master
declares Taxonomy; (4) gate-house''s own missing layer declaration (B2), alongside
key-cape, ops-mason and net-kingdom; (5) whether access-engine is a section 4 source of
evidence for the decision record (B3), held open as its declared gap G2 with audit-core
holding the other half; (6) whether a layer declaration may carry a standard version (B4).
Also carried: the custodian''s reading, offered and not pressed, that the v0.8 acceptance
flip should not proceed while section 11''s own mechanical check is ambiguous.
Declarations re-verified here from the repositories'' own files before ruling, rather than
taken from either report. Resolved as GH-DEC-2026-017 (declaration form, vocabulary,
version, and gate-house''s own declaration), GH-DEC-2026-018 (source of evidence), and
GH-DEC-2026-019 (the v0.8 hold). Amendments A9-A13 drafted at
docs/amendments/v0.8-section-11-declaration-amendments.md and carried by GH-WP-0004.
B5 (canon names access-engine; the repository still answers to flex-auth) is not one of
the six and is not ruled here — it is a coordinate note against section 4, already
sequenced under FLEX-WP-0020, and is carried as GH-WP-0004-T05.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
outcome: ruled
state_hub_intake_id: ""
```

157
workplans/GH-WP-0004-section-11-layer-declarations.md Normal file
View file

@ -0,0 +1,157 @@
---
id: GH-WP-0004
type: workplan
title: "§11 layer declarations — amendment set and estate closure"
domain: infotech
repo: gate-house
status: active
flavor: implementation
origin: GH-IN-0003
owner: codex
topic_slug: infotech
created: "2026-09-21"
updated: "2026-09-21"
---
# §11 layer declarations — amendment set and estate closure
## Goal
Land the five §11/§4/§3 amendments that `GH-DEC-2026-017` and `GH-DEC-2026-018`
produce, into the **proposed** v0.8 cut before the acceptance flip, and close the
estate-side items the two rulings create. `GH-DEC-2026-019` holds the flip on this
workplan and states three closing conditions.
**Normative text for A9–A13 is drafted at
`docs/amendments/v0.8-section-11-declaration-amendments.md`.** That file is the
reviewable unit: each amendment carries its own wording, defect statement, and
authority, so it can be argued before anything touches the cut.
## Why now
`access-engine`'s boundaries review (`FLEX-WP-0030`) found five §11 defects from
outside, after the v0.8 round closed, in the section `audit-core` was asked to attack
and did not return a review on. One of them — A10's — is `gate-house`'s own amendment
`A2`, written twelve days ago and reviewed twice without anyone noticing it named a §4
property §4 does not carry.
v0.7 stays `accepted` and in force, unpatched. Nothing operational waits on this; the
cost of the hold is documentation currency, which is what makes it affordable
(`GH-DEC-2026-019` §3).
## Tasks
### T01 — A9: state the §3 vocabulary once, as tokens
Four tokens, closed, case-insensitive comparison, `Engine` not `Engines`, role is not
layer. Resolves the §3-versus-§4 divergence that makes two faithful runs disagree about
eight rows.
```task
id: GH-WP-0004-T01
status: todo
priority: high
```
### T02 — A10: §4 gains an evidence-source marking; §11's check reads the marking
Includes the per-event-class clause and the count repair. Then assess the remaining §4
rows repository by repository — `access-engine` is marked by `GH-DEC-2026-018` §2; the
others are asked, not assigned.
```task
id: GH-WP-0004-T02
status: todo
priority: high
```
### T03 — A11: `INTENT.md` governs, the sidecar is derived, a run states its scope
```task
id: GH-WP-0004-T03
status: todo
priority: high
```
### T04 — A12: a declaration carries no standard version
Includes asking `ops-warden` to drop `standard_version` from the reference form rather
than each of the seven adopters deciding separately.
```task
id: GH-WP-0004-T04
status: todo
priority: medium
```
### T05 — A13: the `access-engine` coordinate is pending, not broken
One line in §4. No gate-house ruling required; substance already ruled in the owning
repository under `FLEX-WP-0020`.
```task
id: GH-WP-0004-T05
status: todo
priority: low
```
### T06 — Ask `informed-decision` whether it should become a §4 catalog row
Asked, not enrolled. Its correction from `surface` to `Staff`/`pep-shaped` is its own and
is not a condition of this task.
```task
id: GH-WP-0004-T06
status: todo
priority: medium
```
### T07 — Closing condition 2: `audit-core` returns its §11 review or declines in writing
A written decline closes it. §14 records *not claimed* rather than counting silence as
assent, and the point is that the record says which.
```task
id: GH-WP-0004-T07
status: wait
priority: high
```
### T08 — Closing condition 3: `key-cape`, `ops-mason`, `net-kingdom` declare or record a dated gap
`gate-house`'s own is discharged (`GH-DEC-2026-017` §6, this commit). A declaration or a
dated gap satisfies this equally; conformance is not the condition.
```task
id: GH-WP-0004-T08
status: wait
priority: high
```
### T09 — Circulate A9–A13 for assent and disposition the returns
Round list: `net-kingdom` (publisher), `access-engine`, `audit-core`, `approval-engine`,
`ops-warden`, `kings-guard`, plus `informed-decision` and `railiance-master` as the two
repositories the vocabulary ruling touches from outside §4.
```task
id: GH-WP-0004-T09
status: progress
priority: high
```
### T10 — `net-kingdom` assembles the amendments into the v0.8 cut and flips acceptance
Publication and the flip are `net-kingdom`'s and were handed over at v0.8 round close.
This task tracks the handoff, not the execution.
```task
id: GH-WP-0004-T10
status: wait
priority: medium
```
## Done when
All five amendments are in the v0.8 cut, the three `GH-DEC-2026-019` closing conditions
are met, and `net-kingdom` has flipped v0.8 to `accepted`.