coulomb/net-kingdom
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Accept security layer v0.8 from confirmed native review
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
This commit is contained in:
tegwick 2026-10-11 01:53:56 +02:00
parent f6b4be384f
commit 0e17d956ab
4 changed files with 287 additions and 53 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -15,7 +15,7 @@ The dynamic, self-optimizing security platform is the long-term direction in
- **[SECURITY-COMPANION.md](SECURITY-COMPANION.md) — start here.** The working
form of the security layer model: what to declare, what binds you, what you may
never claim about evidence, and the two things the estate cannot do yet
- [Security layer model](canon/standards/security-layer-model_v0.7.md) — the
- [Security layer model](canon/standards/security-layer-model_v0.8.md) — the
statute the companion serves (accepted 2026-08-29): how the security estate is
layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own
- [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)

33
SECURITY-COMPANION.md
View file

@ -1,23 +1,26 @@
---
id: netkingdom-security-companion-v0.2
id: netkingdom-security-companion-v0.3
type: standard-companion
title: "NetKingdom Security — Working Companion v0.2"
title: "NetKingdom Security — Working Companion v0.3"
domain: netkingdom
status: accepted
version: "0.2"
companion_to: canon/standards/security-layer-model_v0.7.md
version: "0.3"
companion_to: canon/standards/security-layer-model_v0.8.md
derived: true
derived_from: canon/standards/security-layer-model_v0.8.md
canonical_source_digest: sha256:3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b
owner: gate-house
publication_owner: net-kingdom
created: "2026-08-29"
updated: "2026-08-29"
updated: "2026-10-11"
review_interval: 3m
standard_token: security-companion_v0.2
standard_token: security-companion_v0.3
---
# NetKingdom Security — Working Companion
**Start here.** This is the operative form of
[`canon/standards/security-layer-model_v0.7.md`](canon/standards/security-layer-model_v0.7.md)
[`canon/standards/security-layer-model_v0.8.md`](canon/standards/security-layer-model_v0.8.md)
(accepted): the same rules, without the change log or the review history.
The statute governs where the two disagree. **A disagreement is a finding** —
@ -56,6 +59,13 @@ layer: Staff # Taxonomy | Tooling | Engine | Staff
role: null # Engines only: PDP | PIP | Evidence | Lifecycle
```
The four layer tokens are closed and compared without ASCII case sensitivity.
INTENT frontmatter is authoritative; a sidecar is derived, and disagreement is a
finding. Declaration keys/values must not pin a standard or companion version;
prose citations record provenance. Every checker run names the standard it
validated against and its explicit scope, including a single-repository scope.
Stance maps, claim declarations and emission guarantees are distinct records.
Working references, both offered estate-wide: `ops-warden`'s `layer.yaml`,
`scripts/check_layer_conformance.py`, `tests/test_layer_conformance.py`;
`kings-guard`'s adaptation of the same for a repository with no Tooling
@ -157,6 +167,13 @@ evidence. The mechanically checkable overlay is
it imports the InfoTechCanon contract assigned by `GH-DEC-2026-004` and
remains proposed pending owner-instance validation.
Marked sources publish an inventory per event class with the declared emission
guarantee; evidence-source markings distinguish yes, no and unassessed. Where a
load-bearing guarantee is not itself completeness, explicitly state that
completeness is not claimed. Load-bearing guarantees state controls, not their
sufficiency; neither detection nor the archive proves completeness. A failure-path release
exception is not admitted by this standard.
Otherwise evidence is **attributive**: seek atomicity, and if you trade it away
deliberately, declare the trade and never describe the trail as complete.
@ -219,5 +236,5 @@ Stated so nobody plans around a capability that does not exist:
---
**Statute:** [`canon/standards/security-layer-model_v0.7.md`](canon/standards/security-layer-model_v0.7.md) — accepted 2026-08-29.
**Statute:** [`canon/standards/security-layer-model_v0.8.md`](canon/standards/security-layer-model_v0.8.md) — accepted through memo version 2 at 2026-10-10T23:23:53Z.
**Owner:** `gate-house`. **Guidance on getting things done:** `ops-warden`.

244
canon/standards/security-layer-model_v0.8.md
View file

@ -3,16 +3,23 @@ id: netkingdom-security-layer-model-v0.8
type: standard
title: "NetKingdom Security Layer Model v0.8"
domain: netkingdom
status: proposed
status: accepted
revision: "accepted-1"
accepted_memo: "infd-20261010-security-layer-v08"
accepted_memo_version: 2
accepted_disposition_id: "disp-43e051e9-b12f-4c34-b26e-40b85a96c2e8"
accepted_approval_id: "8432d0dc-adc0-42d0-9a5b-6b71ff492e15"
accepted_at: "2026-10-10T23:23:53Z"
accepted_source_sha256: "103a635f19ab9fe53094d69c3eeebcccd8e87ac9588846167e7e204a7c6de167"
version: "0.8"
supersedes: canon/standards/security-layer-model_v0.7.md
owner: gate-house
publication_owner: net-kingdom
created: "2026-08-28"
updated: "2026-09-09"
last_reviewed: "2026-09-09"
updated: "2026-10-11"
last_reviewed: "2026-10-10"
review_interval: 3m
source_revision: "gate-house@516ed4e"
source_revision: "gate-house@4bd50bfcac850f34e5563ade61fc92103b062f4d; A9-A13 set v0.3 and A2 v1.1"
standard_token: security-layer-model_v0.8
# "assented_by" records assent to a BOUNDARY, given at the version named.
# It is not assent to the current text. Revision reviews are listed in §14.
@ -188,6 +195,31 @@ cannot be lost in a summary.
| **Engines** | interfaces for a modeled concept | APIs, contracts | yes |
| **Staff** | management, operations, change, controlling | specifications, decisions, workplans, tasks | **no** |
**The vocabulary is these four tokens, and it is closed:**
```
Taxonomy Tooling Engine Staff
```
A layer declaration (§11) carries exactly one of them. **Comparison is ASCII
case-insensitive** and a conformance run MUST fold case before comparing: two spellings
of `Engine` do not describe two boundaries, and a check that reports nine findings about
capital letters has made the one real disagreement unfindable. The spellings above are
canonical for new and changed declarations; a lowercase declaration is **conforming**,
not tolerated.
A value outside the four is not conforming and does not name a tier this model has not
enumerated. A fifth layer arrives by amending this section, argued by a repository that
bears a cost under the four-layer cut — not by a repository declaring one.
`Engines` appears in the table heading above for its plural reading; the token is
`Engine`, as §4's Layer column carries it.
A **role** is not a layer. §3.3's Engine roles and §6.4's PEP shape describe what a
repository does within its layer, are carried in a separate `role:` key, and are not
governed by this vocabulary. Ruled in `GH-DEC-2026-012` R2 and again in
`GH-DEC-2026-017` §3.
### 3.1 Taxonomy
Cross-cutting language. Taxonomy repositories define terms and semantic
@ -287,34 +319,49 @@ assent to them sight-unseen.
## 4. Layer catalog
| Repository | Layer | Role | Owns |
| --- | --- | --- | --- |
| `info-tech-canon` | Taxonomy | — | ecosystem-wide semantic contracts and terminology |
| `net-kingdom` | Taxonomy | — | NetKingdom standards of record; publication |
| `key-cape` | Tooling | — | packaged identity tooling; IAM profile; authentication |
| `OpenBao` | Tooling | — | secret storage, leases, PKI, dynamic secret engines |
| `user-engine` | Engine | PIP | users, accounts, memberships |
| `tenant-engine` | Engine | PIP | tenant-as-an-entity facts |
| `zone-engine` | Engine | PIP | zone identity and membership — offline reference conformance per its 2026-08-23 disposition |
| `secrets-engine` | Engine | Lifecycle | credential abstraction, custody, lifecycle |
| `audit-core` | Engine | Evidence | audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6) |
| `access-engine` | Engine | **PDP** | **the policy decision** — the only decision point (§6) |
| `approval-engine` | Engine | PIP | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) |
| `maturity-engine` | Engine | PIP | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) |
| `gate-house` | Staff | — | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** |
| `ops-mason` | Staff | PEP-shaped | building and tearing down access routes and perimeters |
| `ops-warden` | Staff | PEP-shaped | operational access lanes, stewardship, runbooks; SSH certificate issuance — **declared-gap** (§9.1, §13) |
| `kings-guard` | Staff | — | adaptive defence and judgment; observation of Staff-reachable sources — identity and secret observation **pending**; **proposes** containment, which it does not own (§9.2) |
| `whitehat-security` | Staff | — | offensive validation |
| Repository | Layer | Role | Owns | Evidence source |
| --- | --- | --- | --- | --- |
| `info-tech-canon` | Taxonomy | — | ecosystem-wide semantic contracts and terminology | unassessed |
| `net-kingdom` | Taxonomy | — | NetKingdom standards of record; publication | unassessed |
| `key-cape` | Tooling | — | packaged identity tooling; IAM profile; authentication | unassessed |
| `OpenBao` | Tooling | — | secret storage, leases, PKI, dynamic secret engines | unassessed |
| `user-engine` | Engine | PIP | users, accounts, memberships | unassessed |
| `tenant-engine` | Engine | PIP | tenant-as-an-entity facts | unassessed |
| `zone-engine` | Engine | PIP | zone identity and membership — offline reference conformance per its 2026-08-23 disposition | unassessed |
| `secrets-engine` | Engine | Lifecycle | credential abstraction, custody, lifecycle | unassessed |
| `audit-core` | Engine | Evidence | audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6) | no |
| `access-engine` | Engine | **PDP** | **the policy decision** — the only decision point (§6) | yes |
| `approval-engine` | Engine | PIP | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) | unassessed |
| `maturity-engine` | Engine | PIP | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) | unassessed |
| `gate-house` | Staff | — | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** | unassessed |
| `ops-mason` | Staff | PEP-shaped | building and tearing down access routes and perimeters | unassessed |
| `ops-warden` | Staff | PEP-shaped | operational access lanes, stewardship, runbooks; SSH certificate issuance — **declared-gap** (§9.1, §13) | unassessed |
| `kings-guard` | Staff | — | adaptive defence and judgment; observation of Staff-reachable sources — identity and secret observation **pending**; **proposes** containment, which it does not own (§9.2) | unassessed |
| `whitehat-security` | Staff | — | offensive validation | unassessed |
**Evidence source is a marking, not a reading.** A repository is a source of evidence
where it **emits** events into the estate's evidence stream. Custody is disjoint from
emission: holding a record never discharges any emitter's guarantee, and `audit-core`'s
`Evidence` role is custody. The distinction is what `§9.6` rests on — an archive cannot
prove a record was never sent, which has content only because the archive and the
emitter are different parties.
The column carries exactly `yes`, `no`, or `unassessed`: `access-engine` is
`yes`, `audit-core` is `no`, and all other rows remain `unassessed` until
assessed. `—` is not a value. The §11 check reports `unassessed` as
unassessed, never as conforming or as not a source (`GH-DEC-2026-024` §2).
An **actuation surface** — reduce authority, require step-up, isolate a workload
— is catalogued nowhere because it does not exist. See §9.2: it is an Engine
concept held at zero, not a Staff capability.
`access-engine` is the ruled name for the repository currently called
`flex-auth`; both denote the same authority until the governed rename completes.
Execution conditions for that rename are recorded in its migration decision, not
here.
`access-engine` is the ruled repository name formerly carried by `flex-auth`;
both names denote the same authority across the governed rename. A13's
circulated coordinate was pending, not broken. The repository coordinate now
resolves at `access-engine`: `FLEX-WP-0020` records rename operation
`a15af186-6b98-47a4-9b53-79e131747d11` completed on 2026-09-30.
Runtime names remain `flex-auth` under `FLEX-DEC-2026-013`; rename execution
conditions and remaining separate owner gates live in that workplan, not here.
## 5. The binding rule
@ -1182,15 +1229,65 @@ A layer stated *about* a repository by another repository is not a declaration.
Review notes, catalog rows, and correspondence record an intent to adopt; only
the repository's own file conforms.
**Declaration form.** Because prose cannot distinguish a declaration from a
transcribed review, a declaration MUST carry a machine-readable form: a `layer:`
key in the `INTENT.md` frontmatter, or an equivalent declaration file. Without
it this section asserts a property it cannot deliver — the defect this standard
has now corrected three times elsewhere. `ops-warden` has implemented a reference
form (`layer.yaml`, a conformance script, and a test covering the §5.2
no-authority property) and offered it to the repositories that have yet to
declare. Raised by `audit-core`, which noted that `flex-auth`'s conforming
declaration is legible as one only by following its decision trail.
**Declaration form.** Because prose cannot distinguish a declaration from a transcribed review, a declaration
MUST carry a machine-readable form: **a `layer:` key in the repository's own `INTENT.md`
frontmatter.** An equivalent declaration file MAY accompany it and is a **derived
artifact** under this section's derived-artifact rule: it MUST be marked as derived, MUST
name `INTENT.md` as what it derives from, and MUST agree with it. `INTENT.md` governs.
This is not a preference between two files. This section already says a repository
declares its layer in its own `INTENT.md`; the alternative form was added to give the
declaration a machine-readable *form*, and was read as giving it a second *authority*.
**A disagreement between the two forms is a finding in its own right** and MUST be
reported rather than resolved away by precedence. Precedence says which value is the
repository's answer; it does not say the disagreement did not happen. Where one
appearance is reachable by two routes, the record says which route.
**A conformance run MUST state its scope.** This section's obligations attach to
estate-authored repositories **in §4**. A repository outside §4 may declare voluntarily
using this form, and a voluntary declaration is welcome; it is not a §4 obligation and a
run that grades it is over-scoped. A run over §4 and a run over every repository carrying
a declaration answer different questions, and a report that does not say which it did
cannot be acted on. **A run over a single repository is a permitted third scope:** it
names the repository and states whether that repository is in §4, and a run over a
repository outside §4 reports a voluntary result, not §4 conformance.
**A layer declaration MUST NOT carry a standard version.** The declared layer is a
standing property of the repository and does not change when this standard is revised; a
version in the declaration makes every revision read as though it invalidated every
declaration. That is the confusion this standard's own `assented_by` note exists to
prevent: assent records assent to a **boundary**, given at the version named, and is not
assent to the current text.
**The rule reaches content, not a key name.** The declaration, for this purpose, is every
key of the `INTENT.md` frontmatter and every key of a derived declaration file. No key or
value of either carries a version of this standard **or of its companion** — including a
version carried in a path or file name, such as a `standard:` key naming
`…security-layer-model_v0.7.md`. Comments, and the version of a declaration file's own
schema, are not versions of this standard and are not reached. *(r3)* **A version is
reached when it is carried as a pin:** in a key naming a version of this standard or its
companion, in a path or file name, or in the value of a key that identifies this standard
or its companion. A citation of an earlier revision in a record's prose, stating where a
rule came from, is provenance and is not reached.
**The rule reaches the declaration only.** A stance map, claims map, or evidence
classification states a position on clause text, which is version-scoped as a layer is
not, and it SHOULD carry the version of the text it answers; this rule does not apply to
it and a conformance run MUST NOT apply it there.
**Version-scoped state belongs to the conformance run.** Every run MUST state, in its
output, the version or commit of this standard it checked against and its scope. A checker
re-run on demand satisfies this by stating both on every run; no declaring repository is
required to emit a durable conformance record. Where a run's output is **retained or
relied upon**, the retained output is a derived artifact under this section's
derived-artifact rule, and the party retaining it carries the version or commit it was
derived at.
If a future revision changes §3's vocabulary such that a declared token no longer denotes
the same layer, declarations do **not** silently retarget: that revision carries a
re-declaration round, run in this standard's authoring voice. A per-file version pin would
not have caused anyone to re-read anything.
Mechanically checkable:
@ -1203,8 +1300,11 @@ Mechanically checkable:
surface;
- no §4 capability is catalogued without an engine surface, a `pending` mark, or
a `declared-gap` mark;
- every repository catalogued in §4 as a source of evidence declares its
**emission guarantee** in its machine-readable layer declaration: for a
- every repository **marked in §4 as an evidence source** declares its
**emission guarantee** in its machine-readable layer declaration, **per event
class** — a single repository-level guarantee over a stream containing both
a high-volume and a rare class is an average, not a declaration, and will be
satisfied by rate monitoring that cannot see the rare event go missing; for a
**load-bearing** source, a local transactional outbox (§9.4), its declared
cadence, and the detection surface the governing cadence profile requires for
that class — under `net-kingdom`'s
@ -1212,7 +1312,9 @@ Mechanically checkable:
MAY be covered by rate monitoring where the source has classified it as
suitable, with a positive window and a positive minimum; a **rare**
load-bearing class MUST NOT be, and MUST carry a heartbeat **and**
reconciliation, not either alone; for an **attributive** source, the trade it
reconciliation, not either alone, and, where that guarantee is not itself
completeness, an explicit statement that completeness is not claimed; for an
**attributive** source, the trade it
makes and an explicit statement that completeness is not claimed. 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
@ -1230,8 +1332,8 @@ A source that declares no emission guarantee is not conforming, and neither is
one that declares load-bearing emission with rate monitoring alone where its
event class is rare (§9.6). The declaration is what makes §9.6 checkable rather
than reviewable; without it the section states an obligation whose satisfaction
cannot be observed, which is the §9.1 defect this standard has now corrected four
times. Drafted in `gate-house/docs/contracts/approval-emission-detection.md`,
cannot be observed, which is the §9.1 defect this standard has repeatedly
corrected; the instances are listed in §15. Drafted in `gate-house/docs/contracts/approval-emission-detection.md`,
which `approval-engine`'s `cadence.yaml` implements as the reference instance.
The check states no MUST/SHOULD split of its own: which evidence classes must
declare cadence, and in which form, is the governing profile's to say (§17), and
@ -1239,6 +1341,21 @@ this item follows it rather than restating it.
Raised by `audit-core` as the general form of `GH-IN-0001`, so the finding that
produced `GH-WP-0002` cannot recur unnoticed.
**The completeness non-claim binds both arms.** Where the declared guarantee is
not itself completeness, the declaration carries an explicit statement that
completeness is not claimed. A load-bearing guarantee states the controls, not
their sufficiency. The outbox is atomicity at the source against crash and partial
failure. Heartbeat and reconciliation detect loss after the fact. Neither is a
proof that a record was never sent, and neither covers a compromised source
suppressing an event and its own count together. Completeness, where this standard
actually requires it, is emission atomic with the state change; the declaration
may say that, and it MUST NOT describe the detection surface or the archive as
that completeness. Ruled in `GH-DEC-2026-024` §1, from the bound on rule 13 and
from §9.6.
No detectable or direction-limited failure-path release exception is added to
§9.6 or this check (`GH-DEC-2026-024` §3).
The example-validation check is the mechanical half of §12's derived-artifact
rule; `approval-engine` reports it at fifteen lines. Its second clause is the
non-obvious one: an example set that silently omits an optional field teaches
@ -1411,8 +1528,33 @@ follow-up. Settled in `GH-DEC-2026-006`.
## 14. Adoption
Status is **proposed**. v0.7 remains **accepted** and in force until this version
is accepted in its place; it is not patched.
Status is **accepted**. The confirmed human acceptance of memo
`infd-20261010-security-layer-v08`, version 2, approval
`8432d0dc-adc0-42d0-9a5b-6b71ff492e15`, at 2026-10-10T23:23:53Z adopts the exact
proposed source SHA256
`103a635f19ab9fe53094d69c3eeebcccd8e87ac9588846167e7e204a7c6de167`.
This version now governs; v0.7 remains unchanged as historical accepted text.
The acceptance metadata and this adoption notice are publication annotations,
not changes to the approved normative provisions. The bounded publication
receipt is `docs/security-layer-v0.8-acceptance.md`. Checker convergence remains
the separate post-flip GH-WP-0004-T11 obligation.
**Publication preparation history, 2026-10-10.** A9–A13 (A11 r2, A12 r3) and
`GH-DEC-2026-024`'s A2/A10 corrections are assembled into this proposed
cut. This source preparation neither ratifies the standard nor closes
`GH-DEC-2026-019`'s hold by itself. Condition 2 is satisfied by audit-core's
returned 2026-09-23 §11 review (GH-WP-0004-T07); condition 3 by the four
declarations/dated gaps (T08). Condition 1 is source-complete: GateHouse T09 records and dispositions the
applied fresh A11 r2/A12 r3 technical returns from kings-guard,
approval-engine and railiance-master on 2026-10-10, all against amendment-set
SHA256 9b454b83c9aeed08ba13dba4d812f5ae6b4293ced9e43088d64cc3cc00b1459d.
Prior-revision assent was not carried over. Those receipts are technical
returns to the exact amendments, not founder acceptance or a review of
every final-cut adaptation. Gate-house retains authoring
disposition and net-kingdom publication; the named founder acceptance act
was separately supplied by the confirmed human memo acceptance above. T11 checker
convergence is now due after this flip, rather than being inferred complete.
Two things that acceptance does and does not mean, kept apart because
`ops-warden` asked for the distinction:
@ -1422,7 +1564,7 @@ Two things that acceptance does and does not mean, kept apart because
| **Boundary assent** | given by the four repositories below, at the version named in each record, and undisturbed since |
| **Revision review** | v0.7's changes were each the adopted remedy of a v0.6 finding. All fifteen v0.6 findings were subsequently audited against the v0.7 body — not against its change log — and confirmed dispositioned (`gate-house/docs/conformance/2026-09-06-v06-findings-audit.md`) |
| **Reviewed as text** | v0.8's circulated round returned findings from `access-engine`, `approval-engine`, `ops-warden`, and `net-kingdom`, and every finding is dispositioned in `gate-house/docs/conformance/2026-09-06-v08-assent-round.md`. Nine corrections landed in this text during circulation (§15 items 12–20) and one request was declined with its reasons in §6.4 |
| **Not claimed** | `kings-guard` and `audit-core` have not returned a text review; the sections each was asked to attack — §9.5's criteria-grounding clause and §12's step-four paragraph for the first, §11's emission-guarantee wording for the second — carry no assent from the repository best placed to test them. `approval-engine` named the sections it did **not** read (§1–§4, §7, §8, §9.1–§9.2, §9.5–§9.6, §9.8, §10, §18, §20) rather than let a three-finding review read as a clean bill |
| **Not claimed** | No clean-bill review of every section is claimed. `kings-guard`'s §9.5 criteria-grounding and §12 step-four review is not claimed here. `audit-core` returned its §11 review on 2026-09-23; its findings are dispositioned by GH-DEC-2026-024 and incorporated in this proposed cut. `approval-engine` named the sections it did not read in the earlier circulation; A11 r2/A12 r3 returns concern those exact amendments, not all sections. |
**Ten of this version's twelve changes as cut were requested by another
@ -1470,6 +1612,20 @@ basis. Declaration requests are open as intakes in each.
## 15. Change log
**2026-10-10 source finalization of the held proposed cut:** A9 closes the
layer tokens and ASCII case comparison (§3); A10 adds assessed evidence-source
marking (§4) and per-class emission inventory (§11); A11 r2 makes INTENT
frontmatter authoritative, sidecars derived and disagreements findings, and
admits the explicit single-repository scope (§11); A12 r3 bans declaration
pins while preserving prose provenance and requires version/scope in each run
(§11). A13's coordinate note follows the governed completed rename while
preserving `flex-auth` runtime names (§4). GH-DEC-2026-024 adds the explicit
load-bearing completeness non-claim and preserves the rejection of a
failure-path exception; no other section's authority is expanded.
Sources: gate-house/docs/amendments/v0.8-section-11-declaration-amendments.md
v0.3; gate-house/docs/amendments/v0.8-amendment-set.md v1.1; GH-DEC-2026-019,
020, 021 and 024. The older numbered change list below remains history.
v0.7 → v0.8:
1. **§9.7.3 corrected** — the PEP MUST consume before the protected side effect.

61
docs/security-layer-v0.8-acceptance.md Normal file
View file

@ -0,0 +1,61 @@
# Security-layer v0.8 publication acceptance — 2026-10-11
NetKingdom, the publication owner, accepts and publishes the exact finalized
cut adopted by confirmed native human memo `infd-20261010-security-layer-v08`,
version 2, approval `8432d0dc-adc0-42d0-9a5b-6b71ff492e15`, accepted at
2026-10-10T23:23:53Z. The approved proposed source SHA256 is
`103a635f19ab9fe53094d69c3eeebcccd8e87ac9588846167e7e204a7c6de167`.
The final accepted artifact adds acceptance frontmatter and §14 notice only;
its approved normative provisions are unchanged. Native disposition `disp-43e051e9-b12f-4c34-b26e-40b85a96c2e8` is confirmed, non-stale and accepts
the exact source above. The native disposition receipt remains in `the-custodian/docs/evidence/2026-10-10-security-consolidation/human-acceptance-receipts.json`, rather than being
replaced by a fabricated owner approval. This source acceptance approves no
live workload, credential, privilege, MFA journey or SecurityCase execution.
## Gates verified
GH-DEC-2026-019's three closing conditions are evidenced in the current
GateHouse owner record: T09 exact A11 r2/A12 r3 returns dispositioned, T07/T12
AuditCore findings returned and ruled, and T08 four declarations or dated gaps
supplied. Publication-readiness sources pin each receipt and amendment. The
human memo expressly adopts the bounded A13 completed-rename adaptation. No
prior-revision assent is promoted into blanket review of the final cut.
NetKingdom flips v0.8 to accepted and README to the governing source. Historical
v0.7 canon is unchanged. Policy-nexus registers v0.8 at
`standards/security-layer-model/v0.8/` with immutable `accepted-1` revision;
the old v0.7 current route gains a superseded notice pointing to v0.8, leaving
its historical immutable revision untouched. The derived working companion
moves to v0.3, with the statute continuing to govern any discrepancy.
Registration/build verification is source publication preparation; serving the
new site is a separate PolicyNexus release, never inferred from a local build.
## Post-flip owner migration handoff
GateHouse GH-WP-0004-T10 may record this exact publisher acceptance. T11 remains
open until all eight implementers re-point VALIDATED_AGAINST and converge on the
OpsWarden reference detector, or retain a dated reason. These are executable
checker changes, not declaration-version pins. Preserve old versions in detector
negative fixtures: they prove rejection of pins and must not be mechanically
replaced just because the normative version changed.
| Owner | Checker implementation | Verification |
| --- | --- | --- |
| kings-guard | `scripts/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| user-engine | `scripts/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| zone-engine | `tools/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| secrets-engine | `scripts/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| maturity-engine | `scripts/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| ops-warden | `scripts/check_layer_conformance.py` (reference) | `tests/test_layer_conformance.py` |
| tenant-engine | `scripts/check_layer_conformance.py` | `tests/test_layer_conformance.py` |
| access-engine (historical flex-auth) | `internal/layer/conformance.go`, `tools/check_layer_conformance.go` | `internal/layer/conformance_test.go` |
Each run must report accepted v0.8 plus its explicit declared scope. Different
source detectors remain owner-specific; convergence means the same declaration
pin/provenance semantics, authoritative INTENT and derived-sidecar disagreement
findings. It does not require replacing meaningful local detectors by a generic
copy. WhitehatSecurity's remaining `conformance_state` declaration removal is
also GH T11 and is not closed by these eight migrations.
GateHouse retains the separate §3.4 doctrine row question (GH T06) and KingsGuard
§9.5 review nonclaim. This acceptance waives neither. Existing runtime capabilities,
zero-capability gaps and native security acceptance stay in their owner plans.