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

Rule what A12 reaches, and where the version goes when it leaves the declaration

Browse source 
Thirteen repositories applied GH-DEC-2026-017 and split on what section 5 reaches.
GH-DEC-2026-020 rules the four questions, with counts re-measured from files.

1. A version-bearing standard: path is a standard version. A12 reaches every key
   and value of the declaration, not a key name. audit-core, user-engine and
   whitehat-security change; the nine that de-versioned made a required change
   and nothing reverts. Comments and schema_version are not reached.
2. companion_version counts. approval-engine removes it; informed-decision's
   removal was required.
3. Stance maps, claims maps and evidence classifications are not reached. Nobody
   changes.
4. Section 11 requires no emitted conformance record, and 017 section 5 was wrong
   to say one exists. A re-runnable checker is sufficient if every run prints the
   version or commit checked against and its scope; kings-guard's constant is the
   reference pattern. Six checkers must print a version; all seven, and
   flex-auth's, must widen past the field name.

Citation: GH-DEC-2026-017 section 5 (body numbering) is canonical; the rationale
part numbers are a summary. whitehat-security was never sent 017 by gate-house,
and that omission is recorded as gate-house's.

A12 is revised as A12 r2 in the amendment set and re-circulated for assent under
GH-WP-0004-T09. No net-kingdom canon file is edited.

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 08:29:03 +02:00
parent 760288530d
commit 104f3fc11d
3 changed files with 351 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

297
decisions/decisions.md
View file

@ -3385,3 +3385,300 @@ 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.
## GH-DEC-2026-020 — What A12 reaches: every key of the declaration including a version-bearing path and the companion version, not stance or claims maps; and the version lives in the run, not in a record every repository must emit
```yaml
id: GH-DEC-2026-020
kind: decision
title: 'What A12 reaches: every key of the declaration including a version-bearing
path and the companion version, not stance or claims maps; and the version lives
in the run, not in a record every repository must emit'
status: resolved
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source_note: the-custodian c19866c0 (three A12-reach questions, counts re-measured
here); approval-engine 98d337c4 (questions 1 and 2, with assent to A9-A13); ops-warden
4220413a (the conformance-record question); the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md
requested_dispositions:
- approved
- revised
- rejected
affects:
- gate-house
- net-kingdom
- access-engine
- audit-core
- approval-engine
- user-engine
- whitehat-security
- ops-warden
- kings-guard
- secrets-engine
- tenant-engine
- maturity-engine
- zone-engine
- informed-decision
- railiance-master
- railiance-platform
created: '2026-09-21T06:27:08.536630Z'
updated: '2026-09-21T06:27:18.741684Z'
rationale: 'Four questions about the reach of GH-DEC-2026-017 section 5 (amendment
A12), raised independently by repositories applying it, plus a citation correction.
Ruled on the ground section 5 already gives: a version in a declaration is readable
as a validity condition, and that is a property of the content, not of a key name.
(1) A version-bearing standard: path counts. A12 reaches every key of the declaration,
which is the INTENT.md frontmatter and every key of a derived declaration file,
and forbids a standard version in any key or value. audit-core and user-engine de-version
the path; whitehat-security, never sent the ruling by gate-house, removes standard_version
and de-versions its path; the nine repositories that de-versioned made a required
change, not a voluntary one. Comments and schema_version are not reached. (2) companion_version
counts: the companion is a gate-house-owned standard-companion and its version in
a declaration is the same pin. approval-engine removes it; informed-decision removal
was required. (3) A12 does not reach stance maps, claims maps or evidence classifications:
they state positions on version-scoped clause text and their version is what makes
them re-readable when the text changes; nobody changes. (4) Section 11 does not
require every declaring repository to emit a durable conformance record, and section
5 was wrong to say that artifact exists. The version belongs to the run: a re-runnable
checker is sufficient, not merely for now, if every run states the version or commit
of the standard it checks against and its scope; kings-guard constant-and-print
pattern satisfies this. A run output that is retained or relied upon is a derived
artifact and the retaining party owes the record. Six copied checkers print no version
and must; all seven checkers key on field names and must widen to what (1) and (2)
rule. Citation: the body section numbering is canonical, GH-DEC-2026-017 section
5, statute A12; the rationale part numbers are a summary and are not cited. A12
is refined as A12 r2 and circulated for assent; nothing in net-kingdom canon is
edited here.'
decided_by: Bernd Worsch
decided_at: '2026-09-21T06:27:18.741684Z'
```
## Context
Thirteen repositories applied `GH-DEC-2026-017` within a day of it issuing: `ops-warden`,
`approval-engine`, `kings-guard`, `secrets-engine`, `audit-core`, `user-engine`,
`railiance-platform`, `tenant-engine`, `maturity-engine`, `zone-engine`,
`railiance-master`, `informed-decision`, `flex-auth`. In doing so, five of them hit the same
three questions about what §5 reaches, and split on two of them. `ops-warden` asked a fourth,
before applying anything, about where §5 had sent the version. The custodian collected the
three with counts; `approval-engine` raised the first two while assenting to A9–A13.
The split is the finding. §5 said *"a layer declaration MUST NOT carry a standard
version"*, and every checker in the estate implemented that as *"no key named
`standard_version`"*. Two careful implementers reading the same sentence reached different
files. That is a correct rule a careful implementer can satisfy without doing the thing it
exists to require — the v0.8 round's closing finding, again, and again in §11.
**The counts were re-measured here from the repositories' files**, not taken from the
custodian's message or this record's own request. They agree with the custodian's on every
row but one, and they add a repository the custodian's set did not contain:
| `standard:` in `INTENT.md` frontmatter | Repositories |
| --- | --- |
| versioned path (`…_v0.7.md`) | `audit-core`, `user-engine`, **`whitehat-security`** |
| unversioned name or path | `ops-warden`, `approval-engine`, `kings-guard`, `secrets-engine`, `tenant-engine`, `maturity-engine`, `zone-engine`, `railiance-master`, `informed-decision` |
| absent | `railiance-platform`, `flex-auth` (and `gate-house`, which carries `layer:` only) |
- **`informed-decision` is not absent.** Its key is present and points at the standards
directory, unversioned on purpose. Nine repositories are unversioned, not eight.
- **`whitehat-security` has not applied `GH-DEC-2026-017` at all.** Its `INTENT.md`
frontmatter still carries `standard_version: "0.7"` beside a versioned path. It is a §4
row (`Staff`) and is in `GH-DEC-2026-017`'s `affects` list, and **`gate-house` never sent
it the ruling**: the 2026-09-21 notices went to eleven recipients and it was not one of
them. The gap is `gate-house`'s, not `whitehat-security`'s, and is recorded as such.
- **`companion_version`** is carried only by `approval-engine`'s `layer.yaml` (`"0.2"`).
- **`standard_version` outside a declaration** is carried by `pep-stance.yaml` in
`ops-warden`, `secrets-engine`, `user-engine`, `tenant-engine` and `informed-decision`,
by `tenant-engine`'s `pip-claims.yaml`, and by `secrets-engine`'s
`evidence-classification.yaml` — seven files, not the two the question named.
- **Seven checkers, not six.** The custodian counts six copies of `ops-warden`'s
`check_layer_conformance.py` plus the original: `ops-warden`, `kings-guard`,
`tenant-engine`, `secrets-engine`, `user-engine`, `maturity-engine`, `zone-engine`
(`tools/`). `flex-auth` enforces absence in `internal/layer/conformance.go` by its own
code. **Only `kings-guard`'s prints the version it checks against.** Every one of them
detects a version by the key name `standard_version` and nothing else.
## Decision
### 1. A version in the `standard:` path is a standard version. A12 reaches the content, not a key name
**Counts.** §5's ground was never about a field. It was that a version in a declaration is
*readable as* a validity condition, and that a field kept "for information" will be branched
on. `standard: …/security-layer-model_v0.7.md` is read exactly that way — it is the more
likely of the two to be branched on, because a path is what a tool opens.
**What the declaration is, for A12's purpose:** every key of the `INTENT.md` frontmatter,
and every key of a derived declaration file. A12 forbids a standard version **in any key or
value** of either, including a version-bearing path or file name.
**Not reached,** stated so they do not later read as drift in either direction:
- **Comments.** Six sidecars keep a `# Framework: …_v0.7.md` header comment (`audit-core`,
`railiance-platform`, `tenant-engine`, `maturity-engine`, `zone-engine`,
`railiance-master`). A comment is not machine-readable and cannot be branched on. Leaving
it is conforming; removing it is harmless. Neither is required.
- **`schema_version`.** The version of the sidecar's own schema is not a version of the
standard. `ops-warden` bumped its schema to `0.2` for the removed key; `approval-engine`
left `0.1`. Both are fine: the sidecar schema is `ops-warden`'s (`GH-DEC-2026-017`, *What
this does not rule*), not doctrine's.
**Required changes:**
- **`audit-core`** — de-version `standard:` in `INTENT.md` frontmatter.
- **`user-engine`** — de-version `standard:` in `INTENT.md` frontmatter.
- **`whitehat-security`** — remove `standard_version: "0.7"` from `INTENT.md` frontmatter
(this is `GH-DEC-2026-017` §5 itself, owed since it issued) and de-version `standard:`.
De-versioning means pointing at the standard without a version — the name
`netkingdom-security-layer-model`, the unversioned path
`net-kingdom/canon/standards/security-layer-model`, or the directory, as the nine already
do — or removing the key. Which is the repository's.
**The nine that de-versioned made a required change, not an optional one.** `ops-warden`,
`approval-engine`, `kings-guard`, `secrets-engine`, `tenant-engine`, `maturity-engine`,
`zone-engine`, `railiance-master` and `informed-decision` acted on their own reading
of §5 before it was ruled, and the reading was right. **Nothing reverts.**
### 2. `companion_version` is a standard version
**Counts.** `SECURITY-COMPANION.md` is `type: standard-companion`, owned by `gate-house`,
`accepted`, and itself pinned `companion_to: …_v0.7.md`. A companion version in a declaration
makes every companion revision read as invalidating the declaration, which is §5's reason
without change. Nothing about the companion makes the layer less of a standing property.
- **`approval-engine`** — remove `companion_version: "0.2"` from `layer.yaml`. The
unversioned `companion:` path in `INTENT.md` may stay.
- **`informed-decision`** — its removal was **required**, not merely harmless. Nothing
reverts. Its question whether `ops-warden`'s reference form draws the line differently is
answered: the reference form carries no `companion_version` and does not need to.
### 3. A12 does not reach stance maps, claims maps, or evidence classifications
**Does not count.** `pep-stance.yaml`, `pip-claims.yaml` and `evidence-classification.yaml`
are not layer declarations. They state a repository's position on **clause text** — §6.4's
unreachable-engine stance, §9.3 and §9.7's freshness terms, §9.6's classes — and clause text
is version-scoped in a way a layer is not. A stance on §6.4 at v0.7 can be wrong at v0.8; a
layer cannot. The version in these files is what lets a reader know which text the position
answers, and therefore what to re-read when the text moves. It is the version-scoped state
§5 said belongs somewhere other than the declaration; these files are such a place.
`ops-warden`'s `standard_version` / `standard_version_reviewed` pair sits in the file
this repository already named as the shape to follow (`GH-DEC-2026-006`), and it is the right shape
for exactly this reason: it says what binds and what has been read.
**Nobody changes.** Every repository read A12 this way and left these files alone; the
reading is confirmed. A checker MUST NOT apply A12 to them.
### 4. §11 does not require every declaring repository to emit a conformance record. The version belongs to the run
**First, a correction to `GH-DEC-2026-017` §5.** It said 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… That artifact exists; the version has a home."*
The second half was wrong. §11's derived-artifact rule governs derived artifacts **where they
exist**; nothing in §11 obliges a declaring repository to produce one, and none of the seven
checkers writes anything durable. `ops-warden` saw that removing the field removed the only
place it stated what it conformed against, and asked rather than picked. §5 named a home that
was not built — the same shape as A10's §4 column, in the same decision family.
**Ruled: a re-runnable checker is sufficient — not "sufficient for now" — on one
condition.** Every run MUST state, in its output:
1. the **version or commit of the standard it checks against**, and
2. its **scope** (A11: §4, or every repository carrying a declaration).
The version is an input to the run, not a property of the repository, and a run is the
thing that has it. A durable record every repository emits would be a second copy of the
checker's answer that goes stale between runs — a derived artifact whose only property is
the ability to disagree with a re-run.
**Where durability is owed, the relying party owes it.** A run's output that is **retained
or relied upon** — by an assessment, a conformance report under
`docs/contracts/conformance-reporting.md`, a `maturity-engine` finding, or the v0.8
acceptance flip — is a derived artifact under §11's rule and MUST carry the version or
commit and scope. The party that retains it owes that, not the repository that was checked.
**`kings-guard`'s pattern is sufficient.** `VALIDATED_AGAINST`, a constant in the checker,
printed on every run, is condition 1 exactly. It also has a property the field never had:
when the canon moves, the constant goes visibly stale in every run's output, where the field
would have stayed quietly true of the file. It is adopted as the reference pattern. The
constant lives in the checker, which is not a declaration, and A12 does not reach it.
**Required changes to checkers:**
- **`ops-warden`, `secrets-engine`, `tenant-engine`, `user-engine`, `maturity-engine`,
`zone-engine`** — print the standard version or commit checked against, and the run's
scope, on every run. `kings-guard`'s constant is one way; the property is what is required.
- **`kings-guard`** — print the run's scope; its checker states the version and does not
yet state scope.
- **All seven checkers, and `flex-auth`'s `internal/layer/conformance.go`** — widen A12
enforcement from the key name `standard_version` to what §1 and §2 rule: no standard or
companion version in any key or value of the declaration, including a version-bearing
`standard:` or `companion:` path; comments and `schema_version` excluded; stance, claims
and classification files excluded. A checker that says it enforces A12 and enforces the
key name only is a derived artifact that does not agree with its source — §11's own
derived-artifact defect.
- **`ops-warden`** — as holder of the reference checker, the widened check is best landed
there first; the copies follow it. Sequencing is `ops-warden`'s.
**`ops-warden`'s held session.** `4220413a` held its change set for a session mandated to
verify the ruling in this repository rather than from a message. That bar is right, and this
record is written to be verified that way: the counts above are re-measured from files, and
each required change names its file.
### 5. The citation: `GH-DEC-2026-017` §5 is canonical, and after the flip, §11 as amended by A12
The **body's section numbering is canonical**. A decision is cited by its `### N.` sections.
The `rationale:` field summarises the ruling in parts `(1)`–`(4)` that do not map one-to-one
onto the six sections — rationale part (3) spans body §3 and §4 — and **is not cited**.
`ops-warden`'s playbook citation, *"§5"*, is correct. The two repositories that cited A12
instead were also correct: A12 is the statute text that carries §5. Before the v0.8 flip,
cite `GH-DEC-2026-017 §5`; after it, cite v0.8 `§11` (A12). Citing both is fine.
The rationale is left as written. It is a resolved record's summary, not its text, and
rewriting it would make the citation question harder to reconstruct, not easier.
### 6. A12 is refined as `A12 r2`, and circulated
The refinement is drafted in `docs/amendments/v0.8-section-11-declaration-amendments.md`
and goes to the `GH-WP-0004-T09` round list for assent. `A12` as first circulated already
had `approval-engine`'s assent; that assent is to the text it saw and is asked again for the
revision rather than carried over. Until the flip, this record governs implementers; the
amendment moves it into the statute and does not decide it again.
## What this does not rule
- **Not ruled: `whitehat-security`'s `conformance_state` and `declared_at` frontmatter
keys.** `conformance_state: blocked-clean` is state, in a declaration, and may be the same
shape as a version. It is not raised by any repository and is not ruled on inspection
alone; it goes to `whitehat-security` as a question.
- **Not ruled: `informed-decision`'s `INFD-IN-0007`** — how §3.4's definition of Staff
applies to a deterministic, agent-free repository holding evidence another layer depends
on. It is a real question and is carried separately; it is not an A12 question.
- **Not ruled: the sidecar schema's version policy.** `ops-warden`'s.
## Reversal condition
§1 and §2 reverse if a declaration is found whose layer genuinely depends on the version of
a document it names — which would mean the layer is not a standing property, and §5 itself
would fall with it.
§3 reverses if a stance or claims map is found being read as a layer declaration by a
conformance run; the remedy then is to fix the run, and only if that is impossible to extend
A12.
§4's sufficiency reverses if a conformance claim is found relied upon, at a version nobody
can recover, because nobody retained the run — which would show the relying-party duty does
not hold in practice.
## Provenance
Raised by `approval-engine`, which de-versioned its own path on a reading, left
`companion_version` in place on the same reading's uncertainty, and asked rather than
guessed on both — assenting to the amendments in the same message. Collected with counts by
`the-custodian`, which measured on disk rather than from reports and corrected its own
checker count before sending. `ops-warden` asked the conformance-record question while
holding its own change on a bar it set for itself, and the question turned out to be a defect
in `GH-DEC-2026-017` §5. `kings-guard` answered it for itself before it was asked, and that
answer is the ruling. `informed-decision` removed `companion_version` and said so, which is
the only reason question 2 had a split to report.