From 0e17d956ab45f8c4a0163b70749490c414e54e67 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 11 Oct 2026 01:53:56 +0200 Subject: [PATCH] Accept security layer v0.8 from confirmed native review Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade --- README.md | 2 +- SECURITY-COMPANION.md | 33 ++- canon/standards/security-layer-model_v0.8.md | 244 +++++++++++++++---- docs/security-layer-v0.8-acceptance.md | 61 +++++ 4 files changed, 287 insertions(+), 53 deletions(-) create mode 100644 docs/security-layer-v0.8-acceptance.md diff --git a/README.md b/README.md index 5926182..ae1ab5c 100644 --- a/README.md +++ b/README.md @@ -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) diff --git a/SECURITY-COMPANION.md b/SECURITY-COMPANION.md index 2a2240d..1d27d88 100644 --- a/SECURITY-COMPANION.md +++ b/SECURITY-COMPANION.md @@ -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`. diff --git a/canon/standards/security-layer-model_v0.8.md b/canon/standards/security-layer-model_v0.8.md index 392b11c..e92eb22 100644 --- a/canon/standards/security-layer-model_v0.8.md +++ b/canon/standards/security-layer-model_v0.8.md @@ -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. diff --git a/docs/security-layer-v0.8-acceptance.md b/docs/security-layer-v0.8-acceptance.md new file mode 100644 index 0000000..dd28ac0 --- /dev/null +++ b/docs/security-layer-v0.8-acceptance.md @@ -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.