Rule what A12 reaches, and where the version goes when it leaves the declaration
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:
parent
760288530d
commit
104f3fc11d
3 changed files with 351 additions and 13 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
**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
|
||||
**Version:** 0.2 — A12 revised as A12 r2 (`GH-DEC-2026-020`); re-circulated for assent
|
||||
**Date:** 2026-09-21
|
||||
**Workplan:** `GH-WP-0004`
|
||||
**Base:** `net-kingdom/canon/standards/security-layer-model_v0.8.md` (proposed, not accepted)
|
||||
|
|
@ -29,7 +29,7 @@ its authority. This document moves them into the statute; it does not decide the
|
|||
| 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 |
|
||||
| A12 r2 | §11 | `GH-DEC-2026-017` §5, `GH-DEC-2026-020` | 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
|
||||
|
|
@ -172,13 +172,23 @@ outside §4.
|
|||
|
||||
---
|
||||
|
||||
## A12 — §11, a declaration carries no standard version (T04)
|
||||
## A12 r2 — §11, a declaration carries no standard version, and a run states the version it checks against (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.
|
||||
**Revision note (r2, 2026-09-21).** A12 as first circulated said *"MUST NOT carry a
|
||||
standard version"*, and every checker in the estate implemented it as *"no key named
|
||||
`standard_version`"*. Thirteen repositories applied it and split on what it reached: a
|
||||
version-bearing `standard:` path, a `companion_version`, and `standard_version` in stance
|
||||
and claims maps. Its second paragraph also sent version-scoped state to a *"derived
|
||||
conformance record"* that §11 obliges nobody to produce. `GH-DEC-2026-020` rules all four;
|
||||
r2 states them in the statute. **Assent given to A12 as first circulated is to that text and
|
||||
is asked again for r2**, not carried over.
|
||||
|
||||
**Why.** `access-engine` removed `0.7` from its own declaration, enforced the absence by test,
|
||||
and asked that §11 say so generally rather than leave each repository to work it out. Every
|
||||
sidecar in the estate carried `standard_version: "0.7"`, including `ops-warden`'s reference
|
||||
form and the repositories that adopted it — so this was the reference form's field, not one
|
||||
repository's habit. The r2 additions exist because a rule stated as a key name was satisfied
|
||||
by key-name checkers that could not see the same pin under another name.
|
||||
|
||||
**Add to §11's "Declaration form" paragraph:**
|
||||
|
||||
|
|
@ -189,17 +199,36 @@ field, not one repository's habit.
|
|||
> 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.
|
||||
> **The rule reaches content, not a key name.** The declaration, for this purpose, is every
|
||||
> key of the `INTENT.md` frontmatter and every key of a derived declaration file. No key or
|
||||
> value of either carries a version of this standard **or of its companion** — including a
|
||||
> version carried in a path or file name, such as a `standard:` key naming
|
||||
> `…security-layer-model_v0.7.md`. Comments, and the version of a declaration file's own
|
||||
> schema, are not versions of this standard and are not reached.
|
||||
>
|
||||
> **The rule reaches the declaration only.** A stance map, claims map, or evidence
|
||||
> classification states a position on clause text, which is version-scoped as a layer is
|
||||
> not, and it SHOULD carry the version of the text it answers; this rule does not apply to
|
||||
> it and a conformance run MUST NOT apply it there.
|
||||
>
|
||||
> **Version-scoped state belongs to the conformance run.** Every run MUST state, in its
|
||||
> output, the version or commit of this standard it checked against and its scope. A checker
|
||||
> re-run on demand satisfies this by stating both on every run; no declaring repository is
|
||||
> required to emit a durable conformance record. Where a run's output is **retained or
|
||||
> relied upon**, the retained output is a derived artifact under this section's
|
||||
> derived-artifact rule, and the party retaining it carries the version or commit it was
|
||||
> derived at.
|
||||
>
|
||||
> If a future revision changes §3's vocabulary such that a declared token no longer denotes
|
||||
> the same layer, declarations do **not** silently retarget: that revision carries a
|
||||
> re-declaration round, run in this standard's authoring voice. A per-file version pin would
|
||||
> not have caused anyone to re-read anything.
|
||||
|
||||
**Authority.** `GH-DEC-2026-017` §5. Raised by `access-engine` against its own file, which
|
||||
is where this whole review started.
|
||||
**Authority.** `GH-DEC-2026-017` §5 — cited by its body section; the decision's
|
||||
`rationale:` part numbering is a summary and is not cited (`GH-DEC-2026-020` §5) — and
|
||||
`GH-DEC-2026-020` §1–§4. Raised by `access-engine` against its own file, which is where this
|
||||
whole review started; the reach questions raised by `approval-engine`, `ops-warden` and
|
||||
`informed-decision` in applying it, and collected with measured counts by `the-custodian`.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -82,6 +82,14 @@ state_hub_task_id: "7735233f-864f-5a73-9b60-7399995b5b97"
|
|||
Includes asking `ops-warden` to drop `standard_version` from the reference form rather
|
||||
than each of the seven adopters deciding separately.
|
||||
|
||||
**Revised as A12 r2 (2026-09-21, `GH-DEC-2026-020`).** Applying A12 split thirteen
|
||||
repositories on its reach. r2 states that it reaches every key and value of the declaration
|
||||
(a version-bearing `standard:` path and `companion_version` included), does not reach stance,
|
||||
claims or classification maps, and puts the version in the run's output rather than in a
|
||||
record every repository must emit. Required per-repository changes are listed in
|
||||
`GH-DEC-2026-020` §1, §2 and §4. r2 is re-circulated under T09; assent to A12 as first
|
||||
circulated does not carry over.
|
||||
|
||||
```task
|
||||
id: GH-WP-0004-T04
|
||||
status: todo
|
||||
|
|
@ -143,6 +151,10 @@ Round list: `net-kingdom` (publisher), `access-engine`, `audit-core`, `approval-
|
|||
`ops-warden`, `kings-guard`, plus `informed-decision` and `railiance-master` as the two
|
||||
repositories the vocabulary ruling touches from outside §4.
|
||||
|
||||
Returns so far: `approval-engine` assents to A9–A13 as first circulated (98d337c4). A12 r2
|
||||
re-circulated 2026-09-21 to the round list with `GH-DEC-2026-020`; assent to r2 is asked
|
||||
afresh from every round member, including `approval-engine`.
|
||||
|
||||
```task
|
||||
id: GH-WP-0004-T09
|
||||
status: progress
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue