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

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.