diff --git a/canon/standards/security-layer-model_v0.9.md b/canon/standards/security-layer-model_v0.9.md new file mode 100644 index 0000000..d526497 --- /dev/null +++ b/canon/standards/security-layer-model_v0.9.md @@ -0,0 +1,2237 @@ +--- +id: netkingdom-security-layer-model-v0.9 +type: standard +title: "NetKingdom Security Layer Model v0.9" +domain: netkingdom +status: proposed +revision: "proposed-1" +version: "0.9" +supersedes: canon/standards/security-layer-model_v0.8.md +owner: gate-house +publication_owner: net-kingdom +created: "2026-08-28" +updated: "2026-10-11" +last_reviewed: "2026-10-10" +review_interval: 3m +source_revision: "GH-DEC-2026-025; GH-WP-0004-T06-r1" +accepted_predecessor_sha256: "3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b" +bounded_doctrine_approval_id: "d90c899b-f25c-4e66-a003-808ee5b1324f" +bounded_doctrine_proposal_sha256: "08bc78a29c2b67cec0aafba993fb2d25312b629ecccb81458980baafe38e566a" +standard_token: security-layer-model_v0.9 +# "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. +assented_by: + - "flex-auth FLEX-DEC-2026-001" + - "kings-guard KG-DEC-2026-001" + - "ops-warden ADR-0010" + - "audit-core AUDIT-IN-0001, and v0.4 review with three findings" + - "flex-auth FLEX-DEC-2026-002 (v0.4, §9.3 contested)" + - "kings-guard v0.4 review, four findings" + - "ops-warden 2026-08-29 v0.4 review, three findings" + - "kings-guard v0.6 review, four findings; KG-DEC-2026-002 (§9.5 boundary)" + - "ops-warden v0.6 review, two findings" + - "access-engine FLEX-DEC-2026-003 (v0.6), five findings and two answers" + - "audit-core v0.6 review, three findings" +related: + - canon/standards/security-zones_v0.1.md + - canon/standards/tenancy-posture_v0.1.md + - canon/standards/credential-management_v0.2.md + - gate-house/decisions/decisions.md + - net-kingdom/history/2026-08-29-layering-standard-assessment.md + - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md +--- + +# NetKingdom Security Layer Model v0.9 + +## 1. Purpose + +This standard states how NetKingdom's IT-security estate is layered, and what +each layer may and may not do. It answers one question: + +> **Given a repository, which layer is it in, and what does that permit it to +> own?** + +The layers are distinguished by **determinism** and by **the kind of artifact +the layer produces**, not by technical tier, deployment topology, or team. + +It is not an org chart, not a network model, not a deployment topology, and not +a dependency graph. It does not assign work, and it does not replace any +repository's boundary contract; it constrains what such a contract may claim. + +**What changed in v0.8.** v0.7 was accepted, and eight rulings were made against +it in the eight days that followed. Each was correctly kept out of the accepted +text; together they are a version. + +Three correct a rule that was unsafe or unfalsifiable as written. §9.7.3 stated +that the action precedes consumption, which leaves the compare-and-swap able to +prevent only the second *record* and never the second *side effect* — single +consumption was theatre. §9.5's boundary with posture rested on volatility, which +describes the two categories without partitioning them. §6.4 let `unknown` +resolve permissively, which makes being unclassifiable a privilege escalation +requiring no credential. + +Three close a gap between rules already made. §6.4 gains validation by owning +layer and the rule that correspondence between two artifacts is established by +identity rather than translation. §11 gains an emission-guarantee declaration, so +`GH-IN-0001` cannot recur unnoticed. §13.1 gains three rows, a scoping axis, a +coverage figure, and an honest statement of what it cannot answer. + +Nine more corrections landed during circulation, listed as §15 items 12–20 and +dispositioned in `gate-house/docs/conformance/2026-09-06-v08-assent-round.md`. The +load-bearing one is §6.4 obligation 1: a PEP must be able to *attribute* a +decision to `access-engine`, and no digest comparison does that. Fail-closed +protects against a decision point that is absent, not against one that lies. + +One is a defect of the same kind this standard has now corrected repeatedly: §17 +stated that emission-cadence ownership was unassigned and unassented after it had +been assigned and both owners had accepted. And §11 and §12 gain the general form +of the failure that produced it — six instances in one week, across four +repositories, of a repository acting on a derived summary rather than the +authoritative body. Four were self-reported and one was committed by the +repository proposing the rule, which is the argument that the publishing shape +makes the error the default rather than that four repositories were careless. + +§15 records the change list. Section numbers are unchanged: the estate cites them. + +**What changed in v0.7.** v0.6 announced a rule it never wrote: §1 and §15 said +the standard separates human and agent principals inside Staff, and §3.4 was +byte-identical to v0.5. `kings-guard` found it and put it correctly — *a rule +stated about a standard in its own change log is not a rule*, which is §11's own +principle turned on the standard. §3.4 is now written. + +The rest are collisions between rules written for the clean case: §6.4's first +obligation forbade what its third obligation blesses, and its second forbade the +session-bound allow §9.7.1 permits. §9.4's atomicity was described as closing a +threat it does not close. §19 graded the document it lived in. And §20 records +the interaction boundary with Railiance operations, on definitions from +`railiance-master` rather than inference. §15 records the change list. + +**What changed in v0.6.** An independent assessment against industry practice +(`net-kingdom/history/2026-08-29-layering-standard-assessment.md`) found the model +sound as a layering constitution and incomplete as a *self-healing* one: cognition, +authority, and execution are specified, but the two verbs that close a healing +loop — observe in production and actuate through a deterministic surface — are +pending, and one is unstaffed. It also found the Engine layer untyped, so that +"we need an engine for X" drifts toward "X now decides", and the enforcement +point unnamed. + +v0.6 types the engines (§3.3), names the enforcement point (§6.4), replaces the +containment assignment with an actuation surface held at zero (§9.2), separates +human and agent principals inside Staff (§3.4), puts time into the model (§9.7), +requires the Taxonomy artifacts that make §6.2 compileable rather than +reviewable (§17), and composes the sibling standards it had only cited (§18). +Section numbers below §14 are unchanged: the estate cites them. + +**What changed in v0.5.** All four reviewing repositories returned findings on +v0.4, and one contested a rule. §9.3 was wrong: it collapsed *engine reachable +but degraded* with *engine not reachable at all*, and the second case has no +evaluator in the path to express anything. §9.1 collapsed *no route exists* with +*route exists under a declared gap*, which would have forced a false "pending" +onto a production capability. §11 claimed mechanical checkability for a rule +that cannot be checked in prose. §13 filed two opposite conformance states in one +table and recorded proposed owners as owners. §9.6 needed the load-bearing +distinction it implied but never drew. §15 records the change list. + +**What changed in v0.4.** `audit-core` assented to the approval evidence half +and corrected the rationale twice. v0.3 rested §9.4 on that repository's INTENT +principle 6, which is an aspiration; the shipped bound in its `docs/integrity.md` +is weaker and conditional. More consequentially, no append-only archive can prove +**omission at source** — a suppressed revocation leaves the chain intact — which +is now stated as an estate-wide doctrine constraint (§9.6) rather than left +implicit. `audit-core` was also referenced as an owner in v0.3 without appearing +in the §4 catalog at all; it is catalogued here, as an Engine, on its own +declaration. §15 records the change list. + +**What changed in v0.3.** Two engines were seeded to own concepts v0.2 recorded +as unowned: `approval-engine` takes the approval object that §13 left homeless, +and `maturity-engine` takes graded progression — closing a §9.1 defect in +gate-house's own catalog claim, which asserted conformance review with no engine +to act through. §15 records the change list. v0.3 is **proposed**: the two new +engines are seeded by owner direction and have no other side to assent yet, and +the evidence half of the approval split needs `audit-core`'s assent. + +**What changed in v0.2.** v0.1 was assented to by all three repositories whose +boundaries moved, and each returned a finding. v0.1 had one lane for a Staff +repository that legitimately touches Tooling — read-only diagnostics — which is +narrower than the estate as it actually stands, and a rule with no lane for a +real sanctioned case is satisfied by relabelling rather than by closing the gap. +v0.1 also catalogued a capability (§4, containment) that §5 forbade discharging, +and applied its reconstructability test to engines but not to the doctrine +gate-house feeds them. §15 records the full change list. + +## 2. Authority and conformance + +| Fact or rule | Authority | +| --- | --- | +| The layers, their definitions, and the rules between them | This standard, owned by gate-house | +| Which layer a given repository is in | This standard, §4 catalog | +| What a repository owns within its layer | That repository's `INTENT.md` and boundary contract | +| Whether a specific request is permitted | `access-engine` — never this standard | +| Whether a Tooling contact is sanctioned | The declaring repository, under the shapes in §5, reviewable by gate-house | +| Security doctrine and invariants | gate-house | +| Publication | net-kingdom canon | +| Whether an invariant is *watched in practice* | the observing repository's own report — never this standard, and never §12's diagram | + +A repository conforms when its `INTENT.md` declares its layer, its claims fall +within that layer's permissions (§3), and its Tooling contacts take one of the +sanctioned shapes in §5 or are declared as gaps under §5.3. + +**No estate argument may cite observation that has not happened.** §12 lists +`kings-guard` against the loop's fourth step, and that repository has reported +that it has never observed a real event. Until it reports otherwise, no +assessment, review, or decision in this estate may treat an invariant as being +watched in practice on the strength of the diagram. Lifted here from §12 so it +cannot be lost in a summary. + +## 3. The layers + +| Layer | Character | Produces | Deterministic | +| --- | --- | --- | --- | +| **Taxonomy** | cross-cutting language | terms, semantic contracts, standards | n/a — describes | +| **Tooling** | infrastructure and state | data structures, persistence | yes | +| **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 +contracts so the other layers interoperate without integration by +interpretation. They own no runtime position and no state any layer depends on. + +`info-tech-canon` holds ecosystem-wide semantic contracts. NetKingdom-specific +security architecture — including this standard — is net-kingdom canon's. + +### 3.2 Tooling + +Deterministic infrastructure: data structures, persistence, and the consistent, +performant, scalable keeping of state. Much of it is third-party. + +### 3.3 Engines + +Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret, +an access rule. An engine's defining property is that **the same authoritative +input state yields the same result**. Engines are where the estate's +deterministic guarantees live, and therefore where every enforcement boundary +MUST sit. + +A repository whose core function is inference or judgment fails this test by +construction and is Staff, however much of its work happens at runtime. + +**Engines are typed.** "Engine" is one layer but four roles, and collapsing them +hides different failure modes. Every §4 Engine row carries a role: + +| Role | Meaning | Outage means | +| --- | --- | --- | +| **PDP** | renders the authorization decision — `access-engine`, and only it (§6) | consumer residue (§9.3) | +| **PIP** | supplies facts a decision consumes as claims — user, tenant, zone, approval, maturity | input degradation, engine's own fallback (§9.3) | +| **Evidence** | records what happened and proves integrity of what it holds — `audit-core` | MUST NOT block the operation being recorded — a default, not a property; see below | +| **Lifecycle** | a deterministic API over Tooling it owns — `secrets-engine` | the owning engine's failure semantics | + +The roles are why *"we need an engine for X"* does not mean *"X now decides"*. +A new engine is a PIP unless this standard is amended to say otherwise, and §6 +means it can never be a second PDP. + +The Evidence row's outage rule is an estate **trade**, not a property of +evidence engines. Choosing availability there means accepting that a compromised +source can suppress a record and that detection is the answer (§9.6). The +opposite shape — *do not proceed unless an independent custodian already holds +the record* — is the only one that puts evidence outside the actor's blast +radius **before** the act. The estate has not needed it, so it is not ruled out +by a table cell: an operation whose control genuinely requires independent +recording before effect is a declared exception, raised when needed. Raised by +`audit-core` against its own row. + +The industry vocabulary is deliberately mirrored here — PDP, PIP, PEP as in +NIST ZTA and XACML — because it is how the estate talks to the outside and how a +PEP is stopped from quietly becoming a PDP. The determinism cut in §3 stays +primary where the two disagree. + +### 3.4 Staff + +Interactive and non-deterministic. Staff is the management layer: operations, +change, innovation, and controlling. It works through agentic capability — +assistants and autonomous agents — and its artifacts are specifications, +decisions, workplans, and tasks. + +Staff repositories MUST NOT hold state that another layer depends on at +runtime, and MUST NOT render or cache any decision an Engine is responsible for. + +Acting at runtime does not make a repository an Engine. Being agentic makes it +Staff, and §5 governs how it acts. + +**Carried tension — deterministic presentation evidence.** `informed-decision` +retains its ruled `Staff` / `PEP-shaped` classification (`GH-DEC-2026-012` R1, +`GH-DEC-2026-017` §3). Its deterministic presentation and retention of evidence +for `audit-core` do not fit this section's non-determinism description and +prohibition on runtime-dependent state. This standard records that tension +explicitly; it does not reinterpret those requirements as already satisfied. +Its §4 row admits it to the conformance scope, not to a claim of conformance. + +A conformance report concerning this repository MUST state the §3.4 tension +as unresolved and MUST NOT report the repository as wholly conforming solely +because its layer declaration agrees or its pin detector passes. This is a +repository-specific disposition, not a fifth layer or an exemption allowing +other Staff repositories to hold Engine decision state. + +The existing boundaries remain binding: `informed-decision` MUST NOT render +or cache an authorization verdict, hold approval current-state, decide +approval validity or consume approvals. Its presentation claim MUST NOT be +an input to the authorization decision it presents for; `view_hash` MUST NOT +replace the approval-engine binding digest. The evidence copy MUST have the +independent path required by `GH-DEC-2026-012` R2 limit 3. Emission guarantees +remain owed under §9.6 and §11, per declared event class. This carried tension +grants no permission to omit or downgrade load-bearing evidence, bypass an +Engine, or continue an operation where a mandatory local evidence record +cannot be made. The §3.4 tension remains visible until a later argued model +revision resolves it; recording the tension is the answer to `INFD-IN-0007`, +not a claim that the tension has disappeared. + +**Two principals, one layer.** Humans and agents are both non-deterministic and +both Staff, so they share the layer's permissions. They do not share blast +radius. Four rules bind the agent principal specifically: + +1. **No standing credential.** An agent holds no long-lived credential of its + own. Authority is issued per task, time-bounded under §9.7, and attributable + to the principal on whose behalf it acts. +2. **Tool use is a conduit or an Engine API.** An agent acts through §5.2 — the + owner's tool under the caller's identity, presenting no authority of its own + — or through an engine. There is no third route. Tool availability is not + permission: a callable tool means the operation exists, not that this actor + may invoke it. +3. **Agent memory is not a state plane.** Agent memory, tool-call traces, and + prompt caches are the agent's own. They MUST NOT become state another layer + depends on at runtime unless catalogued as Tooling in §4, which subjects them + to §5 like anything else, and to §5's sunset. +4. **Every agent action is reconstructable as the caller's action**, bounded by + §9.6 — the archive shows the actions it received, not that it received all of + them. + +Session semantics — session loops, tool policy, harness routing, model +selection — are **not** governed here. They belong to `glas-harness` and its +`rein-*` backends (§20). This standard governs what an agent may be authorized +to do; `glas-harness` governs how an agent session is conducted. Rule 2 is the +seam between them, and neither side may treat its own half as sufficient. + +v0.6 claimed these rules in its change log and did not write them. Found by +`kings-guard`, which is the repository they bind hardest and which offered to +assent to them sight-unseen. + +## 4. Layer catalog + +| 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 | +| `informed-decision` | Staff | PEP-shaped | human presentation and binding surface; presentation evidence emission; §3.4 carried tension; approval state remains approval-engine's | yes | +| `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` and +`informed-decision` are `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). Catalog membership and an evidence-source marking +identify the obligations to check; neither certifies that they are met. + +`informed-decision` publishes three load-bearing event classes: +`presentation` (volume), `disposition` (rare), and `stance-application` (rare). +The volume class permits rate monitoring with positive window and minimum, +together with reconciliation; the rare classes require heartbeat and +reconciliation, not rate monitoring alone. Its source declaration currently +records the emission guarantee as owed and not yet declarable. Until an +actual guarantee and its verification are returned by the source, a §11 run +MUST report it as owed/not declared, not as conforming or complete. Completing +those guarantees does not by itself resolve the separate §3.4 tension. + +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 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 + +> **Staff never touches Tooling directly. It acts only through Engine APIs.** + +A Staff repository MUST NOT hold a direct client for a Tooling-layer system — +no direct database connection, no direct OpenBao client, no direct cluster +mutation — outside the shapes below. This is the architectural form of *no +privilege from cognition*, and it is deliberately mechanically checkable. + +**Scope.** "Tooling-layer system" means a system catalogued as Tooling in §4. +Infrastructure the estate runs but has not catalogued — the State Hub, +`llm-connect`, and similar — is outside this rule, because a rule that silently +covered them would put every Staff repository in undeclared violation on +adoption day: they all write progress events. Such clients SHOULD be recorded +in the repository's declaration as non-Tooling for completeness of the check, +and the way to bring one under §5 is to catalogue it in §4, deliberately. + +Raised by `ops-warden`, which held clients for both and declined to resolve the +scope question on gate-house's behalf. + +**The carve-out sunsets.** It is a pressure valve, and a valve left open becomes +a second persistence plane under the Staff layer — which §3.4 forbids in spirit. +Three rules bound it: every non-Tooling client MUST be listed in the +repository's declaration; an uncatalogued store that another layer **reads** +MUST, within two review intervals, either be catalogued as Tooling in §4 or be +declared a gap under §5.3; and a Staff-owned event bus or memory store MUST NOT +become the estate's de facto state plane. Today's instances are the State Hub +and `llm-connect`; tomorrow's are agent memory, tool-call traces, and prompt +caches (§3.4). + +Three shapes are sanctioned. Everything else is a violation. + +### 5.1 Read-only diagnostic observation + +A Staff repository MAY read Tooling state for diagnostics where the owning +engine exposes no equivalent. It MUST be declared in the repository's +`INTENT.md`. It grants no write, and it is an engine gap to close, not a +standing arrangement. + +### 5.2 Conduit + +A Staff repository MAY run the **owner's** tool under the **caller's** identity, +supplying no authority of its own. The test is the supplied-authority property: +the conduit MUST NOT present its own credential, MUST NOT widen what the caller +could already do, and MUST be reconstructable as the caller's action in audit. + +A conduit that presents its own token is not a conduit; it is §5.3 or a +violation. This shape MUST be declared, and the no-authority property SHOULD be +covered by a test. + +The reconstructability requirement is an audit-dependent claim and is therefore +bounded by §9.6: the archive shows the conduit actions it received, not that it +received all of them. + +### 5.3 Declared engine gap + +Where a Staff repository must contact Tooling directly and no engine exposes the +capability, it MUST declare the contact rather than take an exemption. A +declared gap carries, machine-readably: + +| Field | Meaning | +| --- | --- | +| `capability` | what the contact does | +| `intended_owner` | the engine that should own it | +| `blocked_on` | why it cannot move today | +| `review` | a date, not "when convenient" | + +A declared gap is **tracked non-conformance**, not conformance. It does not +expire on its own and it is not a licence to add more. It exists because a rule +offering no lane for a real sanctioned case gets satisfied by relabelling rather +than by closing the gap — and a tracked gap is visible, whereas a relabelled one +is not. + +Prior art: `ops-warden` runs equivalent machinery for delegated lanes (27 +catalog entries carrying `delegation:`, queryable via `warden route gaps`), and +has offered it as reusable. + +**No fourth "operator of third-party Tooling" shape.** It has been proposed, on +the argument that someone must operate `OpenBao` and every operational necessity +otherwise looks like a gap. Declined: §5.3 already sanctions the operation while +keeping it visible, and a clean "operator" shape would convert a tracked gap +into a permanent allowance — the relabelling failure this standard exists to +prevent. A permanent operational necessity is a declared gap whose review +interval keeps returning, which is the correct amount of friction. If the review +becomes ceremonial, that is an argument for closing the gap, not for renaming +it. + +## 6. One decision point + +`access-engine` is the only policy decision point in NetKingdom. No other +repository, in any layer, may render or cache authorization decisions. + +First ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy decision +point. It stays the only one."* The failure mode, from the same source: *"It +becomes a second decision point… it would arrive as a small convenience."* + +### 6.1 Compiled data that determines an outcome is still deciding + +A registry, cache, or schema that resolves a result before the engine runs has +decided early. Provenance MUST remain reconstructable from the engine's decision +record. + +### 6.2 Doctrine reaches the decision as an input, or it is not applied + +This rule binds gate-house on the same terms. **An authority ceiling, mandate +constraint, or operating-mode restriction that determines an outcome MUST reach +the decision either as an input claim on the request or as a rule in the +versioned policy package**, so that its application is reconstructable from the +decision record. + +Doctrine that influences outcomes by any other route is a second decision point +wearing an author's hat. This is not a limit on gate-house's authorship; it is +what keeps that authorship auditable at decision time. + +### 6.3 No Staff repository may host a decision point + +A deterministic authority boundary inside a non-deterministic layer contradicts +the invariant the estate is built on. gate-house was re-cut on this ground. + +### 6.4 The enforcement point + +The standard has been precise about the decision and silent about the gate. A +decision that nothing refuses to proceed without is advice. + +A **PEP** is any runtime that causes a protected side effect. It is a *shape*, +not a repository: `ops-warden` issuing a certificate, `ops-mason` opening a +route, and any protected system acting on a verdict are all PEP-shaped. Being +PEP-shaped does not move a repository out of its layer. + +Five obligations, and they are normative: + +1. **No side effect without a decision record, or a recorded stance.** A PEP + MUST NOT perform the protected action unless it holds a decision from + `access-engine` identifying the request it was rendered for, **or** its + declared §9.3 stance for the applicable scope permits proceeding without one + **and the application of that stance is recorded in place of the decision**. + The second limb is stricter than silence, not looser: a fail-open result is + metadata, never an absent record. `ops-warden` `ca.py` writes the zone, the + failure mode, and a decision id present only where a decision was rendered. + + **Held is not attributed, and this obligation requires both.** The decision a + PEP holds MUST be *attributable to* `access-engine`, not merely present and + well-formed. Obligation 2's digest test establishes **which request** a + decision was rendered for; it establishes nothing about **who rendered it**, + and it cannot. Every input to that comparison is either sent by the caller or + published: the request material is what the PEP transmitted, and the policy + and registry digests are computable from a public repository. A responder + knowing a published package id and version reproduces all of it and returns a + well-formed allow, and each further digest published makes a forged envelope + look more authenticated rather than less. + + **Fail-closed protects against a decision point that is absent, not against + one that lies.** §9.3's whole apparatus — two failure cases, two owners, + published stance maps — addresses absence. An unreachable PDP denies; a + responder impersonating one allows. The asymmetry with obligation 5 is the + sharp form: §9.4 requires the approval object to have durable, authenticated + entries, so a PEP can validate the approval artifact's authenticity and + cannot yet validate the decision artifact's. Obligation 5 is written over + both halves of that pair and is today satisfiable for only one of them. + + This obligation is therefore **not discharged by a digest comparison**, and an + implementer MUST NOT read obligation 2's mechanical test as discharging it. + The channel is unauthenticated today — `flex-auth.decision-record.v1` carries + no signature and pins serve plain HTTP — so the obligation stands with a + declared gap in §13 rather than with a shipped mechanism, owner + `access-engine` (`FLEX-DEC-2026-010`, `FLEX-WP-0024`). The signature scheme is + the owner's under §17; the standard names the property, not the mechanism. A + declared gap is honest; an unstated assumption inside a test called mechanical + is not. Raised by `access-engine` against its own artifact, having recorded it + as its own defect before reviewing this text; put the same way independently by + `secrets-engine`, whose posture *"silently assumes the PDP is the PDP"*, and + carried forward by `approval-engine`, which observed that an approval whose + `pdp_digest` matches a **forged** decision matches perfectly. + + §16 had already recorded this observation one layer up, against this + standard's own publication path having no digest, freeze, or rollback + discipline. Applied to the artifact the standard regulates rather than to the + standard, it is this paragraph: the gap was visible from inside and was + recorded against the wrong artifact. + + v0.6's unqualified form made the shipped stance §9.3 sanctions into a + violation — the same defect as v0.5's §9.1, a rule written for the clean case + producing a false result on the adjacent case already sanctioned elsewhere. + Raised by `ops-warden`, which is the reference shape for limb two. + +2. **No recaching of the verdict beyond its own binding.** A stored verdict + replayed **outside the decision's stated binding and lifetime** is a second + decision point deciding early (§6.1). Within them it is the decision being + used as issued — a session-bound allow under §9.7.1 is used across later + requests by construction, and v0.6 forbade what §9.7.1 permits. + + The test is mechanical, not a matter of implementer judgement: replay is + permitted **iff the canonical request digest matches and the decision's + lifetime holds**. `access-engine` computes that digest over normalised + subject, action, resource, and context, and it is already in every decision + binding. A retry after a transport failure is therefore the same request; a + different resource is not. + + **Negative caching is permitted, narrowly.** A cached DENY cannot manufacture + authority — §8's asymmetry holds — and protects against retry storms. It is + permitted where the refusal is itself recorded against the request that was + refused (obligation 4), and where the cache lifetime is declared alongside + the stance map. A stale deny is an availability failure and will be + misdiagnosed as a policy one, so it must be visible as what it is. Ruled + explicitly because it is the first thing an implementer under load reaches + for. Raised by `access-engine`. + +3. **A declared unreachable-engine stance** (§9.3): total, per zone or + equivalent scope, no implicit default, no per-call discretion, published + rather than held in code comments or in a dataclass default. `ops-warden` + `ADR-0009` and its `pep-stance.yaml` are the reference shape. + + The published map MUST equal the shipped behaviour, and that equality MUST be + asserted by a test. A published map free to drift from the code is worse than + none, because it invites reliance it cannot support. Raised by `ops-warden`, + which found its own map unpublished while being cited as the reference for + this obligation. + + The test was a `SHOULD` through v0.8's circulation, which left the strongest + obligation in this section with the weakest verification: a paragraph arguing + that drift is worse than no publication, whose only detector of drift was + optional, sanctioning the failure exactly where the argument says it is worst. + Promotion costs nothing — §13.1's `Shape` column already records such a test + for four of five rows. Raised by `access-engine`. + + **`unknown` is not a zone and MUST resolve to `fail_closed`.** §9.3 permits + trading availability for openness *per zone* — knowingly, for a named scope, + at a declared cost. That trade requires knowing the zone. Where the scope is + unknown it cannot have been made for this request, so resolving `unknown` + permissively does not extend a considered decision; it invents the most + permissive one available. + + An unreachable engine and an unclassified subject are different failure + cases. The first is a known request in a degraded system, and the trade is + genuinely available for it. The second is not: `unknown` is the cheapest + state for an attacker to induce — an unregistered workload, a malformed + label, a resource created before classification, a race against registry + propagation — and a permissive `unknown` makes being unclassifiable a + privilege escalation requiring no credential. §8's asymmetry forbids that + wherever it appears. Zone stances are untouched by this rule. + + **A map MUST enumerate its axis, and an `unknown` cell MUST NOT be what makes + it total.** Totality satisfied by a catch-all is satisfied *vacuously*: every + scope the author never enumerated lands in `unknown`, fails closed, and nobody + ever learns which those were. The map is then total by having a default rather + than by covering its axis, and the drift test above passes by exercising the + catch-all instead of the axis. `access-engine` recognised the shape because it + published it — a policy package shipped with no tenant rule at all while 29 + fixtures passed, because every fixture carried the same tenant + (`FLEX-DEC-2026-008`). A suite that never varies an input cannot report on it, + however many assertions pass; a stance map with a catch-all cannot report which + scopes were never enumerated, however green its test. + + **`unknown` and `absent` are one runtime behaviour and two meanings, and the + record MUST distinguish them.** A scope value the map classifies as `unknown` + and a scope value the map does not enumerate at all both fail closed — + `absent` for a stronger reason than `unknown`, since it is the branch reached + by discovering that the author's model of their own axis was wrong, and §8's + asymmetry forbids being more permissive on surprise. But an `unknown` hit is + normal operation under a considered stance, while an `absent` hit is evidence + that this obligation is violated. An `absent` hit MUST therefore be + distinguishable in the record from an `unknown` hit, and MUST surface as a + conformance failure rather than be absorbed by the catch-all. This answers the + question §16 opened at the v0.8 cut, and closes it. Raised by `access-engine`. + + **Classification coverage is published alongside the stance, and does not + soften it.** A row reading `unknown` → `fail_closed` while most of that + consumer's targets resolve to no scope at all is conformant and materially + misleading: a reader cannot distinguish a strict consumer from an unclassified + one, and the map becomes accurate about itself while inaccurate about its + effect — §11's published-map-equals-shipped-behaviour rule one level up. + §13.1 therefore records a dated coverage figure beside each stance. + + Coverage is disclosure, **not** a transitional licence. `ops-warden` asked + whether this obligation could name a dated, published transitional + `unknown: fail_open` converting on coverage rather than on calendar, having + measured zero of three signing targets and three of twenty-one routing lanes + resolved to a zone: adopting the cell today would fail closed on essentially + every certificate it issues whenever `access-engine` is unreachable, including + the continuity path an operator needs in order to repair that unreachability. + **Declined.** A sanctioned transitional `fail_open` is indistinguishable at + runtime from the stance this rule forbids, and would make the rule optional at + exactly the moment of adoption — the only moment it costs anything. §11's + declared-gap mark already expresses *"correct rule, adoption not yet + affordable"* without inverting the rule's effect, and `ops-warden` proposed + that outcome as its own second preference. The deadlock it names is real, and + is closed by classifying continuity paths into a scope whose stance is open: + that is classification work, not a reason to hold the axis open. A stricter + stance is equally not a licence to manufacture the membership that makes it + survivable — where a scope is unknown because another repository has published + no workload-identity declaration, the consumer MUST NOT infer one. + + **A published map MUST name the axis it scopes over**, and state its + relationship to security zone: either a mapping, or an explicit declaration + that none exists yet and why. *"Per zone or equivalent scope"* permits axes + that cannot be aggregated, and the register cannot then answer *"what is the + estate's stance for a `z2`-protected workload"* — the question an inventory + exists to answer. Forcing every consumer onto zones is the wrong repair where + zone membership is not yet available as a claim: asserting a zone one cannot + know is a fiction, and a fiction in a runtime-read, test-pinned file is worse + than an honest incommensurability. §13.1 therefore records the axes and + states that cross-axis aggregation is unavailable. + + Raised by `access-engine` on the first occasion §13.1 held enough rows to + diverge, and explicitly not as a request that either consumer change its + stance — a PDP does not set a consumer's stance. Settled in + `GH-DEC-2026-009`. + +4. **Reconstructability**, bounded by §9.6. + +5. **Validation by owning layer.** Where a PEP's decision to act rests on more + than one artifact, each artifact MUST be validated against the layer that + owns its data, and a PIP MUST NOT republish the PDP's decision. A PEP MUST + NOT accept the approval fact from the decision artifact, nor the decision + from the approval artifact. + + A composed object bundling both is not forbidden as an artifact, but it is + post-decision by construction: it cannot be served from a pre-decision call, + and it needs a named issuer and lifecycle owner before anyone may rely on it. + + The live instance is the `GH-DEC-2026-003` consumption path: the + approval-claim carries the approval fact (binding digest, validity window, + consumption state, freshness, issuer) and the `DecisionEnvelope` carries the + decision (exact `CheckRequest` match, policy package and version pin). Two + digests may cover the same proposed action without being compared to each + other; they answer different questions at different layers, and collapsing + them is a layer violation in the shape of a refactor. + + **Correspondence is established by identity, not by translation.** Where two + artifacts use different vocabularies for the same request, the consumer + compares a digest one layer computed and the other recorded. It MUST NOT + recompute one layer's binding from the other's vocabulary, and no + cross-engine mapping is published for it to use: a mapping can be wrong in a + way that still produces a confident answer, it fails open, and it would be a + third authority on what a request *is*. + + **An evidence-bearing input may be excluded from a correspondence digest, but + never from the replay identity.** These are two digests over one request and + they are deliberately different. A correspondence digest answers *"is this the + action the approval was granted for"* and must exclude the evidence, or it + cannot be computed before the evidence exists. A replay identity answers *"is + this the same request"* and MUST cover every input the decision depends on, + evidence included — two requests differing only in which approval was + presented decide differently, one allowing and one denying, so collapsing them + would let an allow obtained with a valid claim be replayed against a request + carrying none. That is a fail-open hole reached by a refactor that looks like + simplification, which is why the property is stated rather than left to be + rediscovered. The shape recurs wherever evidence travels inside a hashed + request. Raised by `access-engine`, which nearly took the unsafe simplification + and reported the near miss. + + **A consumer of a summary predicate trusts the issuer's evaluation of + everything folded into it.** Where the split reduces what a PEP verifies + independently — as `valid_now` does for an approver threshold the claim + deliberately does not expose — the compensating property is + reconstructability at the issuer under §9.6, not a second check at the + consumer. That is detection, not prevention, and it belongs in the same + register as §9.6's other residual. + + Raised by `approval-engine`, and by `access-engine` twice against its own + interest — once on its proposed artifact and once on a gap it declined to + close locally. Settled in `GH-DEC-2026-005` and `GH-DEC-2026-008`. + +Every PEP-shaped consumer MUST publish its stance map at a path named in its +layer declaration, and those maps MUST be inventoried in the §13.1 register +until `maturity-engine` can hold them. §9.3 is otherwise a ruling with no +register behind it, and *"`z0`–`z2` and unknown fail open"* becomes the estate's +real policy without anyone having compiled it into a versioned package. + +v0.6 named a register that did not exist — a requirement whose register is +missing is a capability catalogued without a surface, by §9.1's own logic. +Raised independently by `ops-warden` and `access-engine`; §13.1 now exists, and +its first inventory has one row, which is itself the finding. + +Raised by the 2026-08-29 independent assessment: NIST ZTA splits decide from +enforce, and this standard had only the first half. + +## 7. Relationship to the Active Secrets Management Canon + +```text +Staff interactive, non-deterministic ≈ Cognitive Plane +Engines deterministic APIs ≈ Authority Plane +Tooling deterministic state ≈ Execution Plane +Taxonomy cross-cutting language +``` + +*Cognition proposes. Authority disposes. Infrastructure executes.* is therefore +NetKingdom's layering rule, not only its security maxim. §5 and §6 are that +principle applied to repositories rather than to requests. + +## 8. Vocabulary demarcations + +| Term | Belongs to | Not | +| --- | --- | --- | +| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision whether they may | +| **access rule** | access-engine (Engine) — whether an actor may act | the route by which they arrive | +| **control plane** | Engine layer | a Staff repository's self-description | +| **doctrine** | gate-house | a lane owner's runbook | +| **runbook** | the Staff repository stewarding the lane | a substitute for doctrine | +| **posture** | kings-guard publishes; gate-house defines its authority meaning; access-engine renders it | a privilege source | +| **validating a fact** | the consumer checking an artifact against its issuer | **re-issuing it** — serving another layer's conclusion as your own output is deciding early (§6.1), whatever the field is named | + +Posture carries an asymmetry that MUST hold: adaptive systems may reduce +authority, require step-up, or request containment. They MUST NOT +probabilistically manufacture additional authority. + +The asymmetry is what bounds the damage when observation is incomplete (§9.6): +suppressed evidence can only prevent a tightening that should have happened, never +engineer a loosening. That is an argument for keeping it absolute rather than +situational. + +## 9. Capability assignment + +### 9.1 The catalog may not assign what the rules forbid discharging + +A Staff repository MUST NOT be catalogued in §4 as owning a capability it cannot +discharge under these rules. Two marks distinguish the two ways that happens, and +they are not interchangeable: + +| Mark | Meaning | +| --- | --- | +| **pending** | No route exists. No engine exposes the capability, the repository makes no Tooling contact, and the capability is **zero** — not degraded. | +| **declared-gap** | A route exists through a §5.3 declared gap. The capability **works** and is tracked, with an intended owner and a review date in §13. | + +v0.4 had only `pending`, which forced a false choice. `ops-warden` holds +production-verified SSH certificate issuance through a declared OpenBao contact; +marking it `pending` would have told readers the repository does not do the one +thing it demonstrably does daily, while leaving it unmarked left §4 disagreeing +with §13. Neither is acceptable, and the defect was in this section rather than +in the catalog. + +`pending` was written for `kings-guard`'s containment — no route, capability +zero — and remains correct there. `declared-gap` is the case §5.3 was added to +sanction. Raised by `ops-warden`. + +Both marks apply per capability, not per repository. A repository may hold one +capability outright, another under a declared gap, and a third pending. + +### 9.2 Actuation does not exist, and containment is not Staff's to own + +Self-healing needs four verbs: observe, evaluate, decide, actuate. Observation is +`kings-guard` and is unstaffed (§12). Evaluation is `maturity-engine` and is +seeded. Decision is `access-engine` and works. **Actuation has no surface at +all**, and a model with no actuation surface describes a diagnosis machine +rather than a healing one. + +v0.5 marked containment `pending` against `kings-guard`, which was the right +mark on the wrong repository. Containment is not a Staff capability that happens +to lack a route: **reduce authority, require step-up, isolate a workload** are +authority-changing operations, and under §6 an authority-changing operation is +rendered by an Engine and enforced by a PEP (§6.4). A Staff repository proposes +containment; it never performs it. + +The **actuation surface** is therefore an Engine concept — likely a small +surface on `access-engine` together with runtime PEPs — carrying the same +reconstructability rules as any other decision: a containment action is a +decision record, not a side channel. + +It is **unowned and held at zero**. `access-engine` is recorded in §13 as a +*proposed* owner and has explicitly not reviewed it (`FLEX-DEC-2026-002`). No +repository may be catalogued as owning containment until the surface exists — +§9.1 applied to the estate's most operationally tempting gap, and the standard's +own medicine. + +Until then `kings-guard` proposes and judges, its containment claim stays at +zero rather than degraded, and no argument may assume the estate can contain +anything automatically. + +### 9.3 Degraded mode: two failure cases, two owners + +v0.4 collapsed two failures into one rule. They have different owners because +one has an evaluator in the path and the other does not. + +**Input degradation — the engine's.** Where `access-engine` is reachable but +cannot reach its own inputs, the deterministic *fail to reduced authority* +default belongs to the engine. This keeps the decision at the decision point and +keeps the fallback deterministic, which a Staff-layer fallback could never be. + +**Engine unreachable — necessarily the consumer's.** Where `access-engine` is +not reachable at all, it applies nothing, because it is not running. Whatever +happens next is the consumer's behaviour by construction: fail-open is not +expressible by a policy decision point, since there is no evaluator in the path +to express it. A standard that assigns this to the engine assigns it to nobody. + +The consumer's residue is bounded rather than free. A protected system MUST +declare its unreachable-engine stance ahead of time, per zone or equivalent +scope, and that stance MUST be auditable and total — no implicit default, no +per-call discretion. `ops-warden` `ADR-0009` already satisfies this: a total +per-zone map, open for `z0`–`z2` and unknown, closed for `z3-critical`, +replacing the global `policy.enabled` / `policy.fail_closed` switches it +superseded. + +**Unchanged: engine-unavailable is not grounds for a Staff break-glass path.** +The distinction is whether an engine is there to ask. A bypass around a +*reachable* engine is a second decision point, and an incident is when an +attacker most wants that shortcut. A consumer choosing its declared behaviour +when there is no engine to ask is not a bypass; it is the only thing left. + +Contested by `flex-auth` (`FLEX-DEC-2026-002`), which has held since 2026-08-19 +that fail-open is not expressible by a PDP, and which noted v0.4 collided with +shipped behaviour in a repository that had assented to this standard. + +### 9.4 Approvals are an engine concept, not a Staff or audit concern + +The approval object — durable, authenticated entries, distinct-approver +counting, atomic supersession, single consumption, revocation without holder +cooperation — is owned by `approval-engine`. + +It is not Staff's: §3.4 forbids Staff holding state another layer depends on at +runtime. It is not the decision point's: an evaluator that owns the object it +evaluates is self-dealing. It is not the audit fabric's: an approval needs +mutable, in-path, current-state semantics, and an append-only archive is built +for the opposite property. + +`access-engine` consumes approvals as **input claims** under §6.2 and never +mutates them. Every issuance, use, supersession, and revocation is emitted to +`audit-core`: the operative state and the evidence record are different +artifacts with different owners. + +The evidence guarantee is bounded, and the bound is `audit-core`'s +`docs/integrity.md`, not its INTENT principle 6. An in-database hash chain +detects a rewritten payload only if the attacker does not also recompute the +suffix — which a database owner can. Detection against that class requires the +external chain-head attestation, and even with it the store is not WORM, object +lock, or archival custody. `tamper_evidence` is therefore conditional on live +preconditions, not a property of the store at rest, and approval events receive +exactly the guarantee every other source receives. + +**Emission atomicity is `approval-engine`'s obligation.** An approval MUST NOT be +issued, consumed, superseded, or revoked without the corresponding event being +durably queued in the same transaction. + +**The queue MUST be local.** The durable queue MUST live in `approval-engine`'s +own transactional store, and **no synchronous dependency on `audit-core` may sit +inside the state-change transaction**. With a genuine local outbox, fail-closed +triggers only when `approval-engine`'s own store is unavailable — where the +change could not have been recorded anyway — and an `audit-core` outage does not +block a revocation. Satisfying the requirement by emitting synchronously to +`audit-core` inside the transaction is also atomic, and turns an audit outage +into an inability to revoke: the operation least tolerable to block during an +incident, and the same coupling this section rejects for reads. Raised by +`audit-core`. +`audit-core` reports what it received and does not imply it is everything that +happened; without atomic emission the evidence half is silently incomplete and +nothing detects the gap. This is a condition of `audit-core`'s assent +(`AUDIT-IN-0001`) and belongs in `approval-engine`'s contract before the evidence +half is treated as load-bearing. + +`audit-core` MUST NOT expose an approval-validity query. Records, yes; a verdict +on whether an approval is still valid, never — a consumer branching on that +answer would route an authorization decision through the audit fabric, which is +what this section exists to prevent. Callers needing current state ask +`approval-engine`. + +### 9.5 Graded progression is an engine concept + +Maturity — how far a subject has progressed against declared criteria and +submitted evidence — is owned by `maturity-engine`. Given the same criteria and +the same evidence it MUST return the same level; that determinism is what makes +it an Engine rather than an opinion. + +The division with Staff: **gate-house judges and proposes; maturity-engine +computes and remembers.** Interpretation is inference and stays Staff. A +criterion that cannot be evaluated by rule is not yet a criterion. + +This closes a defect in v0.2's own catalog: `gate-house` was assigned +conformance review with no engine to act through, which is exactly the §9.1 +problem raised against the containment claim. Staff acts only through Engine +APIs, including gate-house. + +**A maturity level MUST NOT be compiled into registry content.** Until +`access-engine`'s decision provenance carries a registry-snapshot digest — a gap +it self-declared in §13 — a level reaching a decision through the registry is not +reconstructable from the decision record. Levels arrive as request claims or as +versioned policy rules. Same constraint, and same reason, as zone stance. + +**A maturity level MUST NOT gate a decision directly.** Under §6.1, compiled +data that determines an outcome is still deciding. If a level determines whether +an action is permitted, it MUST reach `access-engine` as an input claim or a +versioned policy rule under §6.2, never by a consumer branching on a fetched +level. + +**The boundary with posture is recomputability, not volatility.** Given the same +criteria and the same evidence, recompute. If you MUST get the same answer, it is +maturity and it belongs in an engine. If you CANNOT promise the same answer, it is +posture and it belongs in Staff. + +This is not a new rule — it is the determinism clause above, pointed at the one +boundary where it had not been pointed. This section already states the maturity +half: a criterion that cannot be evaluated by rule is not yet a criterion. The +posture half is its mirror and completes the pair: **a judgment that CAN be +evaluated by rule is not posture — it is a criterion sitting in the wrong +repository.** Together they partition rather than describe, which a "fast-moving +versus slow-moving" line cannot: volatility is an observation about how a value +has behaved, and every case it does not obviously cover becomes an argument at +exactly the boundary §6 exists to keep out of argument. + +**A criterion MUST bottom out in evidence about the subject, not in another +party's conclusion about the subject.** A recorded judgment may be evidence *that +the judgment was made* — a fact with an issuer and a timestamp. It MUST NOT be +evidence *that the thing judged is so*. Without this the test is satisfiable by +the inference it exists to exclude: *"level 2 iff the reviewer marked the control +adequate"* recomputes identically every time and has placed an opinion inside an +engine wearing a rule's clothes. For human-attested controls, grade on the +attestation event's existence, freshness, and issuer — never on its verdict. + +Three consequences follow. **The migration direction is permanent**: anything +called posture that proves recomputable becomes a criterion in `maturity-engine`; +anything in `maturity-engine` that needs judgment is not yet a criterion and +returns to Staff. **Two authorities cannot grade the same subject property**, +because a property is either recomputable or it is not, and that does not depend +on which repository claims it. **Capability readiness MUST NOT be an input to +posture** — readiness is deterministic and posture is not, so feeding one into the +other would make posture partly recomputable and blur the boundary from the Staff +side. + +**A limit, stated rather than implied.** *"The same evidence"* is not yet well +defined in this estate. Until §17's request-claim and gap-record schemas exist, +two parties can disagree about whether they hold the same evidence, and +recomputability is a thought experiment rather than a check. This makes §17 +load-bearing for this rule. A boundary that is correct but not yet mechanically +checkable is better than one that is checkable and wrong; a reader is entitled to +know which they are holding. + +Raised by `kings-guard` against the volatility line `gate-house` had proposed, and +against its own convenience — the readiness constraint is one it volunteered. +Settled in `GH-DEC-2026-007`. + +Approvals and maturity are deliberate opposites — a closed binary state machine +against an open graded ladder — and neither engine may drift toward the other. + +### 9.6 Evidence proves alteration and truncation, not omission at source + +An append-only archive with a verified hash chain proves that records were not +**altered or truncated after arrival**. It cannot prove that a record was never +sent. Against a compromised or buggy source, a suppressed event leaves the chain +perfectly intact and verification reports intact. + +This bound is estate-wide. Statements of the form *"the audit record proves it +happened"* are unsound; the sound form is *"the archive proves the records it +holds were not altered or truncated after arrival"*. Its mirror is equally +unsound: **absence of a record is not evidence of non-occurrence**, and no +control may read it as such. + +**Load-bearing versus attributive evidence.** The atomicity obligation attaches +to the first, not to both: + +| Kind | Test | Obligation | +| --- | --- | --- | +| **Load-bearing** | a control's soundness depends on the event being present or absent — an approval revocation, a containment action, a denial | emission MUST be atomic with the state change (§9.4) | +| **Attributive** | the event supports forensic reconstruction and attribution, and no control branches on its presence | atomicity SHOULD be sought; where it is deliberately traded away, the trade MUST be declared and completeness MUST NOT be claimed | + +Where a repository deliberately makes emission non-atomic — `ops-warden`'s +`# audit must not block signing` is the estate's live example, chosen so that an +audit-store failure cannot remove production host access — the trade is +legitimate for attributive evidence, MUST be declared where the trail is +documented, and MUST NOT be described in terms that imply completeness. The +availability argument is real in both directions: making it atomic gives the +estate's operational access lane a new dependency on its own evidence store. + +**Consequence for adaptive systems.** Suppression does not degrade observation +neutrally, it biases it optimistic, and silently: an event never emitted is never +evaluated, so no finding is raised and the last posture stands. A confidence +score computed from the richness of the record in hand cannot express doubt about +the completeness of the stream — a well-formed observation from a 90%-suppressed +stream scores high. That is this section's failure reproduced one layer up, in +the consumer. + +Two things follow. + +**Which control covers which threat.** v0.6 read as though emission atomicity +closed this section's opening sentence. It does not, and the decomposition is +owed to the reader: + +| Threat | Covered by | When | +| --- | --- | --- | +| **Accidental omission** — process dies between mutation and emit | emission atomicity, local outbox (§9.4) | prevented | +| **Adversarial omission** — a compromised source declines to insert, deletes before drain, or drains to nowhere | cadence and reconciliation | **detected, after the fact** | +| Adversarial omission at a compromised source | — | **nothing in this model prevents it** | + +The outbox sits inside the blast radius of the component whose compromise this +section posits, so it makes emission atomic against crash and partial failure +and nothing more. That residual is real and is stated rather than implied. +Raised by `audit-core`, correcting a remedy it had itself proposed. + +1. **The §8 asymmetry bounds the damage, and this is its clearest payoff.** + Because an adaptive system may only reduce authority and never manufacture it, + suppression can only prevent a tightening that should have happened. It cannot + be used to engineer a loosening. The harm is a missed reduction, not an + invented privilege — which is an argument for keeping the asymmetry absolute. +2. **Silence is a signal, and for load-bearing evidence it is the only control + in its class.** A source of **attributive** evidence SHOULD declare an + expected emission cadence; a source of **load-bearing** evidence **MUST**. + A drop below the declared rate is a finding in its own right — the stream + observed, not only its contents — and needs no Tooling contact, because the + source publishes its own stream. + + **Rate monitoring is the wrong form for rare events**, and rare is exactly + where the stakes are highest: the most valuable event to suppress is the + negative one, and revocations, denials, and containment actions are + infrequent by nature. A source emitting a handful of revocations a month has + no rate to drop below, and suppression is indistinguishable from a quiet + month. For **low-volume load-bearing classes** the required form is therefore + **positive reconciliation or a heartbeat**: compare the source's own state + transitions against the evidence engine's event count per class and treat + divergence as a finding, or assert *nothing to report* as a signed positive + claim that can itself go missing. Rate monitoring never produces a claim that + can be missing; a heartbeat does. `GH-WP-0002-T04` is the reference instance. + Raised by `audit-core`. + +Raised by `audit-core` against its own principle; extended by `kings-guard` from +its own evaluator and confidence model. + +### 9.7 Decisions have a lifetime + +A single decision point deciding on stale claims is a single decision point +deciding wrongly. The model has had no temporal law, and the approval race in +§16 was its first symptom. + +1. **Every allow has an explicit lifetime** — a TTL, or a binding to a session + or obligation that ends. An allow with no stated end is a standing grant, and + standing grants are what this estate exists to remove. +2. **Revocation and supersession have a visibility deadline**, and its shape + differs by role. A **PEP** has one boundary and MUST state one deadline. A + **PDP** MUST state a deadline **per input class**, because a decision is a + join over sources with unrelated refresh behaviour — approval-claim freshness, + registry snapshot cadence, policy package activation, directory ETag. A single + number at a PDP is either a fiction or the worst case, and the worst case is + the slowest and least visible input. "Eventually" is not a stance; an unstated + deadline is an unbounded replay window. + + A consequence worth naming: a stated deadline for a fact carried by a + registry snapshot is unfalsifiable while decision provenance holds no snapshot + digest, since nobody can determine afterwards which snapshot a decision read. + The deadline and the digest are one gap seen from two sides, which promotes + `access-engine`'s self-declared provenance gap (§13) from housekeeping to a + conformance prerequisite. Raised by `access-engine` against its own backlog. +3. **Consumption is a state change, never an inference.** An approval is + consumed by a mutation in `approval-engine` (§9.4). It MUST NOT be inferred + from the existence of a decision record: a decision record proves an intent + to act, not an act. + + **The PEP MUST obtain a successful consume before the protected side + effect.** Holding a claim with `valid_now: true`, or an ALLOW rendered + against that claim, is not authority to act; the consume is. In-flight + duplicate ALLOWs are expected and the CAS serializes use — a later + `CheckRequest` sees `valid_now: false` and cannot mint a new ALLOW against + the same object. + + v0.7 stated the opposite order. Acting first leaves the CAS able to prevent + only the second *record*, never the second *side effect*, which makes single + consumption theatre. This is a protocol correction and not a retraction of + the forensic claim: consumption is still never inferred from a decision. + + An approval authorizes one **attempt**, not one success. There is no + unconsume and no reserve/release; a consumed approval spent on a failed + action is spent. Reversibility would reopen replay, which is the failure the + mutation exists to close. + + **The correspondence is a digest, and it is the PDP's to define.** A consumer + on this path MUST verify that the approval's recorded PDP digest equals the + digest the PDP publishes **for the request with the approval evidence + excluded** — `binding.approval_binding_digest` in `access-engine` — and MUST + NOT use a claim that carries no such digest. Recomputing the approval engine's + native binding from a `CheckRequest` is not a permitted fallback: it requires + translating between two vocabularies, no mapping is published, and a wrong + translation fails open by silently accepting a claim approved for something + else. Without this, `valid_now: true` plus an ALLOW establishes *approved* and + *permitted* but never *approved for this request*. + + **The comparison cannot be against the full request digest.** Where a claim + travels inside the hashed request — the dual-control pattern — embedding it + changes the digest of the request carrying it, so a digest recorded at issue + can never equal the final one. That is a hash cycle and the resolution is + forced, not chosen: the recorded digest is necessarily of the underlying + action before any claim was embedded. A standard that mandates the naive + comparison mandates a check that can never pass, and a fail-closed consumer + then denies the action permanently. + + **The exclusion rule is the PDP's to publish, and until it does the path is + incomplete rather than complete.** A consumer MUST NOT guess which fields are + excluded: a digest computed under an assumed rule produces a confident wrong + answer, and comparing two digests derived under different rules fails open + toward accepting a claim bound to a different request — the same failure + direction as an invented vocabulary mapping, reached by another road. + + Settled in `GH-DEC-2026-008`, amended on an implementability defect found by + `secrets-engine` and reported independently by `access-engine` and + `approval-engine` within hours of the ruling. + + Settled in `GH-DEC-2026-003`; the protocol is + `gate-house/docs/contracts/approval-consumption.md`. +4. **Three failure modes are named, and each needs an owner**: an allow rendered + then never consumed; a double consumption by racing callers; consumption + after the authorized action has already failed. Neither engine closes these + alone. Recorded in §16 and `GH-WP-0002-T06`. + +### 9.8 Partition is not one-dimensional + +§9.3 handles *engine unreachable*. A real estate spends most of its incident +time in the band between reachable and gone: partial PIP reachability, clock +skew across a decision and its enforcement, and two consumers with different +declared stances seeing different worlds at the same moment. + +Two rules hold today, and the rest is open (§16). A PEP MUST resolve its own +stance from its declared map without consulting another consumer — divergent +views are expected and are not a coordination problem to be solved at enforcement +time. And where clock skew could extend a lifetime under §9.7, the shorter +reading governs. + +## 10. Changing layer + +A repository's layer is not permanent. `zone-engine` changed layer in practice +when its runtime hypothesis was falsified. + +A layer change MUST be recorded as a decision, MUST update the repository's +`INTENT.md`, and MUST obtain assent from the repositories whose boundaries move. +A repository MUST NOT acquire a new layer's permissions by gradual practice. + +"No gradual practice" needs a check rather than a sentence. A layer change MUST +carry six artifacts, written from the `zone-engine` case that the procedure +should have been derived from in the first place: + +| Artifact | Why | +| --- | --- | +| before/after `INTENT.md` | the declaration is the conformance surface (§11) | +| client inventory | what the repository holds against Tooling, before and after | +| gap inventory | which §5.3 gaps close, open, or transfer | +| assent list | every repository whose boundary moves | +| state-migration decision | what happens to live state and to consumers reading it | +| permission freeze | no new permissions of the target layer are exercised until the cut completes | + +The freeze is the one that makes the rule checkable: a repository mid-change +holds its old permissions, not the union of both. + +## 11. Conformance + +Conformance has four states, and the distinction between the last two is the +point: + +| State | Meaning | +| --- | --- | +| **Conforming** | no Tooling contact, or only §5.1/§5.2 shapes, declared | +| **Blocked-clean** | the capability does not exist because no engine exposes it, and the repository makes **no** Tooling contact — §9.1 `pending`, and not a non-conformance | +| **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance | +| **Undeclared violation** | anything else — a finding | + +**Blocked-clean is not a lesser state than conforming.** A repository that +declined a break-glass path and left a capability at zero has complied at cost; +a repository that quietly opened a direct client and declared nothing has not. +Any downstream scoring — `maturity-engine` included (§9.5) — MUST NOT rank the +first below the second. Raised by `kings-guard`, whose three gaps are all of +this kind and which would otherwise have been graded down three times for +having taken the standard seriously. + +**Who must declare.** A repository the estate authors declares its layer in its +own `INTENT.md`. For a component the estate catalogues but does not author — +third-party or vendored, such as `OpenBao` — the §4 catalog row **is** the +declaration, and no `INTENT.md` obligation attaches. A rule that assigns an +obligation the holder cannot discharge is the §9.1 defect applied to conformance +rather than capability. + +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 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: + +- every estate-authored repository in §4 carries a machine-readable layer + declaration; +- every direct Tooling client in a Staff repository maps to a declared §5.1, + §5.2, or §5.3 entry, and non-Tooling clients are recorded so the check is + total; +- no repository other than `access-engine` exposes an authorization decision + surface; +- no §4 capability is catalogued without an engine surface, a `pending` mark, or + a `declared-gap` mark; +- 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 + `emission-cadence-security-profile_v0.1.md`, a **volume** load-bearing class + 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, 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 + infer it from an event name, payload, or observed rate, or the check becomes + circular; +- every published example, fixture, or sample document validates against the + schema it exemplifies, and where a field is optional but load-bearing, the + examples cover both its presence and its absence rather than leaving one shape + to be inferred from the other; +- every derived artifact — a summary, example, change log, or review record that + restates a normative body — is marked as derived, names the artifact it + derives from, and carries the version or commit it was derived at. + +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 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 +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 +every reader that the field does not exist. + +Requires review: whether claims stay inside layer permissions; whether compiled +or cached data has become an early decision (§6.1); whether doctrine is reaching +decisions as declared inputs (§6.2); whether the §8 vocabulary is used correctly. + +## 12. The conformance loop + +Doctrine no engine implements is fiction. The loop is normative, not +aspirational: + +```text +gate-house asserts an invariant + → the engines implement it, or declare a gap + → whitehat-security tries to break it + → kings-guard observes it in operation + → findings return to gate-house as doctrine change +``` + +A finding that a rule is unsatisfiable is a **success** of this loop, not a +failure of the reporting repository. Four of this standard's five versions exist +because a reviewing repository used it. + +**A derived artifact is not evidence of what the body says.** A repository acting +on another repository's contract, schema, or standard MUST read the authoritative +artifact. Where a derivative exists — a summary, example, change log, or review +record — it MUST be marked as derived, name the artifact it derives from, and +carry the version or commit it was derived at. A **dated review record** MUST +carry an explicit marker that it states status as of that date and not current +state. Where a derivative is unmarked, treat it as stale. + +This is not a counsel of care. The estate produced six instances in a single +week, across four repositories: a validator built against a fixture rather than +its prose; a revisit trigger sourced from a dated alignment table; a change log +read for section text; a dual-control policy rule written against an assumed +claim shape, under which every live destroy would have denied; a fixture +declaring a contract version while omitting fields published since; and a +published example set contradicting its own schema. Four were self-reported, and +one was committed by the repository arguing for this rule. Diligence prevented +none of them, and a control that depends on repositories volunteering corrections +is not a control. + +The obligation on the publishing side is §11's marking and example-validation +checks. The limit is worth stating: the mechanical half catches example-versus- +schema drift, and the convention half makes prose staleness visible without +detecting it. A marked derivative can still be wrong; claiming otherwise would be +this same defect one layer up. Proposed by `approval-engine`, which asked to own +none of it. + +**Step four is currently aspiration.** `kings-guard` has disclosed that it has +never observed anything in operation: the pilot is specified and scaffolded, every +input is a hand-built fixture, and no test has met a real event. Until it reports +otherwise, no argument in this estate may assume an invariant is being watched in +practice because §12 lists a repository against that step. + +## 13. Open gaps + +Two different things are recorded here, and they are opposite conformance states +(§11). A **declared contact** means the repository touches Tooling because no +engine exposes the capability. An **unowned capability** means no route exists +and the repository makes no contact at all. Reading them as one list would grade +restraint as though it were non-conformance. + +An `intended owner` is a **proposal to** the named repository, not an assignment +**onto** it. §2 keeps ownership in the repository's own `INTENT.md`, so the +register distinguishes proposed from assented. + +| Gap | State | Declared by | Owner | Owner status | +| --- | --- | --- | --- | --- | +| SSH-CA signing write (`VaultCA`, `bao kv put`) | declared-contact | ops-warden | secrets-engine | proposed | +| Authentication / assurance evidence | unowned-capability | kings-guard | identity layer + audit-core | **access-engine declined** | +| Secret-use evidence | unowned-capability | kings-guard | secrets-engine | proposed | +| Actuation / containment surface | unowned-capability | **gate-house (estate-wide)** | access-engine + runtime engines | proposed | +| Identity and secret observation | unowned-capability | kings-guard | as above | proposed | +| Stance-map register had no implementation | declared-contact | ops-warden, access-engine | gate-house | resolved in §13.1 | +| Registry-snapshot digest in decision provenance | declared-contact | flex-auth | flex-auth | self-declared | +| Decision-record authenticity — a PEP cannot attribute a decision to `access-engine` (§6.4 obligation 1); unsigned envelope, plain-HTTP pins | declared-contact | flex-auth | flex-auth | self-declared (`FLEX-DEC-2026-010`, `FLEX-WP-0024`) | +| Human principal's tenant is unresolvable from the directory, so a client registration supplies it (`GH-DEC-2026-013`) | declared-contact | key-cape | directory adapter — unnamed | proposed | +| Approval storage and lifecycle | — | flex-auth | approval-engine | assigned (§9.4) | +| Approval evidence | — | gate-house | audit-core | **assented** (`AUDIT-IN-0001`) | +| Approval evidence custody stronger than the shipped bound — WORM, object lock, transparency log | unowned-capability | audit-core | — | unassigned | +| Emission atomicity for approval state changes | — | audit-core | approval-engine | assigned (§9.4) | +| Non-atomic audit emission on the SSH signing lane | declared-contact | ops-warden | ops-warden | self-declared, attributive (§9.6) | + +The actuation row is no longer attributed to `kings-guard`. §9.2 ruled that +containment is not a Staff capability lacking a route, so `kings-guard` is not +its declarer: the gap is estate-wide and blocks every repository's ability to +act. Raised by `kings-guard`, which asked not to carry a row for a capability +the standard had just ruled was never theirs. + +`access-engine` declined authentication and assurance evidence +(`FLEX-DEC-2026-002`): it consumes assurance claims as input and never redefines +them, so evidence of authentication belongs to the identity layer and +`audit-core`. It owns evidence of the decision, which it already emits. The +containment surface is recorded as proposed and remains `pending` under §9.2. + +Whether approvals warrant custody stronger than every other source is doctrine +work not yet done; until it is, approval evidence carries the same guarantee as +any other source and §9.6 bounds what may be claimed from it. + +**What is normative here, and what is a snapshot.** Three rules are part of this +standard and survive wherever the register lives: + +1. the two marks — `pending` and `declared-gap` (§9.1); +2. the owner-status rule — a proposed owner is not an assigned one (§2); +3. the scoring rule — `blocked-clean` MUST NOT rank below conforming (§11). + +**The table above is a snapshot, not statute.** It moves into `maturity-engine` +as soon as that engine can store state, and the `state` and owner-status columns +MUST survive the migration. A standard that is also a backlog keeps attracting +findings that belong in the register, and its review interval is far slower than +the register's real rate of change. + +### 13.1 PEP stance-map register + +Every PEP-shaped consumer publishes an unreachable-engine stance map (§6.4, +obligation 3). This is the inventory until `maturity-engine` can hold it. + +| Consumer | Stance map | Axis | Coverage | Shape | +| --- | --- | --- | --- | --- | +| `ops-warden` | `ops-warden/pep-stance.yaml` | security zone | signing targets 0/3 resolved; routing lanes 3/21 resolved (2026-09-09, self-measured) | total per zone; open `z0`–`z2`, closed `z3-critical`; test asserts the published map equals the shipped default (`ADR-0009`). **`unknown` → `fail_open` is non-conformant under §6.4 obligation 3 as of this version**; route `WARDEN-WP-0040` | +| `user-engine` | `user-engine/pep-stance.yaml` | security zone | not reported | total per zone; `fail_closed` for `z0`–`z3`, unknown, and not-applicable; test asserts the published map equals `user_engine.pep_stance` | +| `tenant-engine` | `tenant-engine/pep-stance.yaml` | security zone | not reported | total; `fail_closed` for unset, unreachable, non-allow, unknown; test asserts the file equals shipped behaviour | +| `secrets-engine` | `secrets-engine/pep-stance.yaml` | catalog stage — interim, pending zone membership as a claim | not reported | total over stage plus unknown; no implicit default; runtime-read; pinned to `SHIPPED_STANCE` by test | +| `ops-mason` | — | — | — | **not published — non-conformant under §6.4 obligation 3**; catalogued PEP-shaped in §4; no route recorded | + +**Two rows are marked, and the marking is the point.** `ops-warden`'s cell is +wrongly valued in a published map; `ops-mason` has published no map at all, which +is the plainer violation of the same obligation and read as a bare statement of +fact through v0.8's circulation. A reader scanning for the bold marks would have +found one row and concluded the other four were fine. That is §11's marking +obligation applied to this standard's own register, and it was returned to +`gate-house` unchanged by `access-engine`, which had received the same argument +about a stale row of its own. + +**Coverage is reported by the consumer and is not inferred here.** A blank is +"not reported", never "complete": the register does not compute another +repository's classification coverage, and a stance with no coverage figure beside +it says less than it appears to. §6.4 obligation 3 states why the figure belongs +next to the stance, and why it does not soften it. + +**Cross-axis aggregation is unavailable.** Three maps scope by security zone and +one by catalog stage, which §6.4 permits as an equivalent scope. The register +therefore cannot answer *"what is the estate's stance for a `z2`-protected +workload"* for every consumer, and it states that rather than implying it can. +The convergence path is zone membership reaching the decision as a claim, after +which a stage-scoped map converges onto zones without either side inventing a +mapping. + +**The register earned itself at two rows.** `access-engine` said in the v0.6 +round that it was the repository positioned to notice when the aggregate of +consumer stances diverges from the policy packages, and recorded that the claim +was sound while one row could not diverge from anything. The second row produced +two findings on first inspection: two conformant maps taking opposite stances on +`unknown`, and two incommensurable axes. Both are settled in `GH-DEC-2026-009`. + +This register moves to `maturity-engine` when — and not before — that engine +publishes a committed, versioned export of §13 and §13.1 readable without a live +query, generated rather than hand-edited, and regenerable so drift between the +export and its computed state is detectable. A standard of record must stay +legible in git, at a version, to a reader with no cluster access, including one +auditing the estate precisely because they do not trust its running systems; a +pointer to a live engine is an instruction to run software, not a register. +`maturity-engine` holds both registers as queryable data already (`MAT-WP-0001`), +so what remains is publication — the migration's precondition, not its +follow-up. Settled in `GH-DEC-2026-006`. + +## 14. Adoption + +Status is **proposed**. Accepted v0.8 at SHA256 +`3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b` remains +operative and immutable. This successor source assembles only GH-DEC-2026-025's +approved bounded §3.4 and §4 candidate. Confirmed founder acceptance of memo +`infd-20261011-staff-evidence-tension`, version1, approval +`d90c899b-f25c-4e66-a003-808ee5b1324f`, at2026-10-11T01:46:25Z is the bounded +doctrine disposition, not acceptance of this whole revision. Source-owner +reception/assembly completes the Gate House handoff; standard adoption and +subsequent PolicyNexus delivery remain pending under NET-IN-0004. The current +companion and serving/checker pins remain on accepted v0.8. No deployment, +credential or runtime-conformance permission follows from this source. + +The Staff/deterministic-evidence tension stays unresolved; per-event emission +guarantees stay owed until independently returned and verified. INFD-IN-0007 +awaits the accepted standard's voice; finished INFD-WP-0005/0007 retain their +historical receipts. Neither stale layer metadata nor native delivered rows +reopens those plans or proves whole-class completeness. + +### Historical v0.8 adoption and review record + +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`. +v0.8 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: + +| | | +| --- | --- | +| **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** | 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 +repository**, seven of them by a repository arguing against its own interest or +reporting its own error. There are two exceptions, not one: §17's ownership +correction, which `gate-house` found by auditing its own accepted text, and item +2b, which `access-engine` flagged as a near miss it was explicitly *not* asking to +have written down. The count was stated as ten of eleven until `approval-engine` +observed that item 2b's numbering left a reader unable to tell whether it was a +change or a sub-clause — and that the ambiguity moved both halves of a ratio §14 +calls the argument rather than the background. The nine corrections applied during +circulation (items 12–20) were all requested by another repository. That ratio is the reason the standard is +circulated rather than accepted on the owner's decision as v0.7 was: this version +imposes costs on named repositories — `ops-warden` acquires a non-conformant +stance cell, `approval-engine` acquires an issue-time obligation — and a cost +imposed without a review round is the kind of rule §12 exists to catch late. + +Findings against this text are §12's normal business. Two are anticipated and +would be welcome: whether §6.4's `unknown` ruling is too broad for a genuinely +low-consequence unclassified scope, and whether a maturity criterion exists that +cannot be expressed without dereferencing a judgment. Both are written into the +reversal clauses of their decision records as the falsifiers that would revert +them. + +| Repository | Record | Outcome | +| --- | --- | --- | +| flex-auth | `FLEX-DEC-2026-001` | assent to all three items; one self-declared non-conformance; two rename conditions | +| kings-guard | `KG-DEC-2026-001` | assent; declined the offered §5 relaxation; raised §9.1 | +| ops-warden | `ADR-0010` | assent to all three; veto not exercised; offered the §5.3 amendment | +| audit-core | `AUDIT-IN-0001` | assent to the evidence half with conditions; corrected the rationale twice; raised §9.6 | + +Adoption for a repository means its `INTENT.md` declares its layer, its +ownership claims fall inside that layer, its Tooling contacts are declared under +§5, and any shared boundary has been assented to by the other side. + +**Adoption status as of 2026-08-29: seven of sixteen** estate-authored §4 +repositories have declared in their own voice — `gate-house`, `flex-auth`, +`kings-guard`, `ops-warden`, `audit-core`, `approval-engine`, `maturity-engine`. +The remaining nine — `info-tech-canon`, `net-kingdom`, `key-cape`, +`user-engine`, `tenant-engine`, `zone-engine`, `secrets-engine`, `ops-mason`, +`whitehat-security` — carry a layering review note authored by `gate-house` and +have not answered it. Those notes state a layer but do not constitute a +declaration, and this standard does not claim estate-wide adoption on their +basis. Declaration requests are open as intakes in each. + +## 15. Change log + +**2026-10-11 proposed successor assembly:** GH-DEC-2026-025's exact approved +candidate adds the carried Staff/deterministic-presentation-evidence tension in +§3.4, the informed-decision Staff/PEP-shaped evidence-source=yes row, explicit +catalogue non-conformance limits and volume/rare per-event guarantees owed in §4. +The existing Staff prohibitions remain. No other normative section changes. +Frontmatter, title and §14 distinguish this proposed source from immutable +accepted v0.8; historical adoption/reviews below are provenance only. Exact +handoff and human receipt are pinned in the adjacent source-owner review. + +**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. + v0.7's stated order left the CAS able to prevent only the second record, never + the second side effect. Protocol correction, not a retraction of the forensic + claim (`GH-DEC-2026-003`). +2. **§9.7.3 gains the binding correspondence** — the approval's recorded PDP + digest MUST equal the digest the PDP publishes for the request with the + approval evidence excluded, and a claim without one is unusable on that path. + No cross-engine vocabulary mapping is published: a translation can be + confidently wrong and fails open, where a digest is identity. The comparison + is against an exclusion-scoped digest because a claim travelling inside a + hashed request cannot name the digest of the request containing it — a hash + cycle, found by `secrets-engine` and reported independently by two engines + within hours of the ruling, which as first written mandated a check that could + never pass (`GH-DEC-2026-008`, raised by `access-engine`, which declined to + close it locally). +2b. **A change in its own right, not a sub-clause of 2** — the label is retained + rather than renumbered so that references written against this list do not + silently repoint. §14's tally counts it. **§6.4 obligation 5 gains the + replay-identity property** — an evidence-bearing + input may be excluded from a correspondence digest but never from the replay + identity, because two requests differing only in which approval was presented + decide differently. Flagged by `access-engine` as a near miss rather than a + request. +3. **§6.4 obligation 5 added** — validation by owning layer, and correspondence + by identity rather than translation. A PIP MUST NOT republish the PDP's + decision. Carries the consequence that a consumer of a summary predicate + trusts the issuer's evaluation of what is folded into it, with + reconstructability at the issuer as the compensating property + (`GH-DEC-2026-005`). +4. **§6.4 obligation 3 — `unknown` is not a zone** and MUST resolve to + `fail_closed`; and every published map MUST name its scoping axis and its + relation to zone. `ops-warden`'s `unknown` cell becomes non-conformant, and + the register records it as such (`GH-DEC-2026-009`, raised by `access-engine` + on two conformant maps that disagree). +5. **§9.5 gains the posture boundary** — recomputability, not volatility, with + the clause that a criterion MUST bottom out in evidence about the subject + rather than another party's conclusion about it. Three consequences, including + that capability readiness MUST NOT be an input to posture. The limit is stated: + *"the same evidence"* is undefined until §17 (`GH-DEC-2026-007`, raised by + `kings-guard` against the line this standard's owner had proposed). +6. **§11 gains the emission-guarantee declaration**, so a source catalogued as + evidence declares what its emission actually guarantees rather than + reintroducing `GH-IN-0001` silently. The check defers the form to the + governing profile instead of restating it: as first cut it required a + heartbeat *or* reconciliation of every load-bearing source, which both + over- and under-stated + `emission-cadence-security-profile_v0.1.md` — it withheld from a volume class + the rate monitoring the profile permits, and accepted for a rare class either + control alone where the profile requires both. It also contradicted its own + following paragraph. Corrected by `net-kingdom` on review of the ownership + §17 assigns it (`NK-WP-0035`). +7. **§11 and §12 gain the derived-artifact rules** — examples validate against + the schema they exemplify and cover both shapes of an optional load-bearing + field; derivatives are marked with source and derivation version; dated review + records are marked as status-as-of-date. Six instances in one week across four + repositories (proposed by `approval-engine`). +8. **§8 gains a demarcation** — validating a fact is not re-issuing it. +9. **§13.1 gains three rows, an axis column, and two statements of limit** — that + cross-axis aggregation is unavailable, and that the migration to + `maturity-engine` waits on a published export (`GH-DEC-2026-006`). +10. **§17 corrected** — emission-cadence ownership is assigned, not proposed, and + both owners have accepted (`GH-DEC-2026-004`). +11. **§16 reconciled** against the decision log; two questions closed, one opened + on whether an absent scope differs from an unknown one. + +Applied during circulation, after the round returned findings against this text +(`gate-house/docs/conformance/2026-09-06-v08-assent-round.md`). The version stayed +`proposed` throughout, so these are corrections to an uncut standard rather than +amendments to an accepted one: + +12. **§6.4 obligation 1 gains attribution** — a decision MUST be attributable to + `access-engine`, and obligation 2's mechanical digest test does not discharge + that. Fail-closed protects against a decision point that is absent, not + against one that lies, and obligation 5 was written over a pair of artifacts + whose authenticity only one half of could be validated. Carried as a declared + §13 gap with `access-engine` as owner rather than as a shipped mechanism + (raised by `access-engine` against its own unsigned envelope, having recorded + it as `FLEX-DEC-2026-010` before reviewing this text). +13. **§6.4 obligation 3's drift test promoted `SHOULD` → `MUST`** — the strongest + obligation in the section had the weakest verification, in a paragraph arguing + that drift is worse than no publication. Already met by four of five §13.1 + rows (raised by `access-engine`). +14. **§6.4 obligation 3 forbids totality by catch-all**, and requires an `absent` + scope to be distinguishable in the record from an `unknown` one and to surface + as a conformance failure. This closes the question item 11 opened (raised by + `access-engine`, from its own 29-fixture tenant defect). +15. **§6.4 obligation 3 and §13.1 gain classification coverage** — published + beside the stance, because `unknown` → `fail_closed` over a population that is + entirely unclassified is conformant and misleading. A transitional + `unknown: fail_open` was asked for and **declined**: it is indistinguishable at + runtime from the stance the rule forbids (requested by `ops-warden`, which + proposed the declared-gap outcome as its own second preference and measured the + coverage figure now in the register). +16. **§13.1 marks `ops-mason`** — an unpublished map is a plainer violation of + obligation 3 than a wrongly-valued cell in a published one, and was stated as + bare fact while the other was bolded (raised by `access-engine`, returning + `gate-house`'s own §11 marking argument unchanged). +17. **§14's tally corrected and §15 item 2b clarified** — 2b is a change in its own + right and is the second item not requested by another repository, so the ratio + is ten of twelve with two exceptions (raised by `approval-engine`). +18. **§6.4's count sentence corrected** — it announced four obligations and listed + five, leaving a defensible reading under which an implementer omits the one + governing how an approval is compared to a decision (raised by + `approval-engine`). +19. **§17's artifact count and closing status corrected** — v0.8's item 10 reached + the emission-cadence paragraph and not the count sentence, which still called + ownership of the decision-record schema unsettled after `access-engine` took it + on (raised by `approval-engine`). +20. **§19 gains a stub** — the heading gap was explained in a §16 bullet, where a + reader checking whether an edit had dropped a section does not look (raised by + `approval-engine`). + +v0.1 → v0.2: + +1. **§5 restructured** into three sanctioned shapes. Added §5.2 conduit + (ops-warden's question, ruled) and §5.3 declared engine gap (ops-warden's + amendment, accepted). +2. **§6.2 added** — doctrine must reach the decision as an input claim or a + versioned policy rule (flex-auth's boundary drawn back, accepted). +3. **§9 added** — the catalog may not assign a capability the rules forbid + discharging; containment marked pending; degraded-mode fallback ruled into + the engine (kings-guard's finding). +4. **§11 restructured** — conformance now has three states, distinguishing a + tracked gap from an undeclared violation. +5. **§12 made normative**, with the explicit statement that an + unsatisfiability finding is a success of the loop. +6. **§13 added** — open gaps register, including the unowned approval storage + and lifecycle capability. +7. §4 catalog gained the pending mark and ops-warden's SSH certificate lane. + +v0.2 → v0.3: + +1. **§9.4 added** — approvals assigned to `approval-engine`, with the operative + state and the evidence record separated between it and `audit-core`. +2. **§9.5 added** — graded progression assigned to `maturity-engine`, closing + the §9.1 defect in gate-house's own conformance-review claim, and carrying + the guardrail that a level may never gate a decision directly. +3. §4 catalog gained both engines; gate-house's conformance-review claim now + names the engine it acts through. +4. §13 register updated: the approval hole is assigned, two new entries added. + +v0.6 → v0.7, from four reviews: + +1. **§3.4 is written.** v0.6 announced the human/agent principal separation in + §1 and §15 and left §3.4 byte-identical to v0.5 — a silent edit failure. A + rule stated about a standard in its own change log is not a rule. Found by + `kings-guard`. The same failure had also dropped two §16 entries, restored + here. +2. **§6.4 obligation 1 rewritten** — it forbade what obligation 3 blesses. A PEP + may proceed under its declared §9.3 stance provided the application of that + stance is *recorded in place of* the decision. Stricter than v0.6 where it + counts: a fail-open result is metadata, never silence. Raised by `ops-warden`. +3. **§6.4 obligation 2 rewritten** — it forbade the session-bound allow §9.7.1 + permits. Scoped to replay outside the decision's own binding and lifetime, + with the canonical request digest as the mechanical test, and negative + caching ruled permitted where the refusal is recorded and the cache lifetime + declared. Raised by `access-engine`. +4. **§6.4 obligation 3** gained the requirement that the published stance map + equal shipped behaviour, asserted by test. **§13.1** now exists as the + register §6.4 mandated and v0.6 did not implement. +5. **§9.6 gained a threat decomposition** — atomicity prevents accidental + omission; cadence and reconciliation detect the adversarial case after the + fact; nothing prevents it at a compromised source. Raised by `audit-core` + against its own proposed remedy. +6. **§9.6 cadence is now MUST for load-bearing sources**, with positive + reconciliation or a heartbeat as the required form for low-volume classes, + because rate monitoring fails exactly where the stakes are highest. +7. **§9.7.2 splits by role** — a PDP states a deadline per input class, a PEP one + at its boundary. Promotes `access-engine`'s provenance gap to a conformance + prerequisite. +8. **§3.3's Evidence row** is stated as an estate trade rather than a property, + leaving independent-recording-before-effect raisable as a declared exception. +9. **§17** moves the decision-record schema to `access-engine`, which argued it + against its own interest; `kings-guard` drafts the emission-cadence schema. +10. **§13** no longer attributes the actuation gap to `kings-guard`; it is + estate-wide. **§19 removed** — a verdict inside a standard grades the + document it lives in. **§17/§18** demoted from H1 to H2. +11. **§20 added** — the Railiance interaction boundary, on `railiance-master`'s + definitions, including that `rein-*` is not a fifth axis. + +v0.5 → v0.6, from the independent assessment of 2026-08-29: + +1. **§3.3 types the engines** — PDP, PIP, Evidence, Lifecycle, with a role + column in §4. A new engine is a PIP unless this standard says otherwise, so + "we need an engine for X" cannot drift into "X now decides". +2. **§6.4 names the enforcement point** — a PEP shape with four obligations: no + side effect without a decision record, no local recaching of the verdict, a + declared unreachable-engine stance, reconstructability. The standard had the + decision and not the gate. +3. **§9.2 replaced** — containment was marked pending against the wrong + repository. Actuation is an Engine concept, unowned, held at zero; Staff + proposes containment and never performs it. +4. **§3.4 separates the two Staff principals** — human and agent share the layer + but not blast radius: no standing credential, conduit or engine API only, + agent memory is not a state plane, every action reconstructable as the + caller's. +5. **§9.7 puts time into the model** — explicit lifetimes, revocation visibility + deadlines, consumption as a state change never inferred, and the three race + modes named. **§9.8** states what holds under partition and leaves the rest + open. +6. **§17 requires the Taxonomy artifacts** — claim, decision-record, gap-record, + and emission-cadence schemas — without which §6.2 and §11 are reviewable but + not compileable. Ownership proposed, not assigned. +7. **§18 composes the sibling standards** — how zone stance, tenancy posture, + and a credential lifecycle event each enter a decision as a claim. They were + cited in frontmatter and nowhere in the rules. +8. **§5 gained a sunset** on the uncatalogued-infrastructure carve-out, and + §5.3 **declines** a proposed fourth "operator of third-party Tooling" shape: + it would convert a tracked gap into a permanent allowance. +9. **§10 gained the six artifacts** a layer change must carry, written from the + `zone-engine` case, including a permission freeze during the cut. +10. **§2 lifts the observation rule** — no estate argument may cite observation + that has not happened. **§13** separates its three normative rules from the + table, which is now a snapshot due to move into `maturity-engine`. +11. **§16** the approval custody question is **decided: no**, rather than left + open. **§19** records the fitness verdict, including that the estate can + propose and decide but cannot yet watch or act. + +v0.4 → v0.5, all from review findings: + +1. **§9.1 split into two marks** — `pending` (no route, capability zero) and + `declared-gap` (route exists under §5.3, capability works and is tracked). + v0.4's single mark would have forced a false `pending` onto ops-warden's + production SSH issuance. Raised by `ops-warden`. +2. **§9.3 rewritten** — input degradation is the engine's; engine-unreachability + is necessarily the consumer's, bounded by a declared, auditable, total stance. + Contested by `flex-auth`: fail-open is not expressible by a PDP, and v0.4 + collided with `ops-warden` `ADR-0009`. +3. **§5 gained a scope rule** — "Tooling-layer system" means a §4 Tooling row; + uncatalogued infrastructure is outside §5 and recorded rather than policed. + Without it every Staff repository was in undeclared violation for writing + progress events. Raised by `ops-warden`. +4. **§9.4 requires a local outbox** — no synchronous dependency on `audit-core` + inside the state-change transaction, so an audit outage cannot block a + revocation. Raised by `audit-core`. +5. **§9.5 forbids compiling maturity levels into registry content** until + decision provenance carries a registry-snapshot digest. Raised by `flex-auth`. +6. **§9.6 gained the load-bearing / attributive distinction**, the mirror rule + that absence is not evidence of non-occurrence, the optimistic-bias + consequence for adaptive systems, and silence-as-signal. Raised by + `kings-guard` on top of `audit-core`'s original. +7. **§11 gained a fourth state** — blocked-clean, which MUST NOT rank below + conforming — and a machine-readable declaration form. Raised by `kings-guard` + and `audit-core`. +8. **§13 gained state and owner-status columns** — declared-contact versus + unowned-capability, proposed versus assented owner. `access-engine`'s + decline of authentication evidence is recorded. Raised by `kings-guard` and + `flex-auth`. +9. **§8** records the asymmetry's payoff under incomplete observation; **§12** + records that its fourth step is unstaffed; **§14** corrects the adoption + arithmetic and the status contradiction. + +Amended in place while `proposed`, 2026-08-28: §11 gained the who-must-declare +rule after a conformance sweep found the standard required an `INTENT.md` +declaration from `OpenBao`, which the estate does not author; and §14 gained the +honest adoption count. + +v0.3 → v0.4: + +1. **§4 catalog gained `audit-core`** as an Engine, on its own declaration. v0.3 + named it as an owner in §9.4 and §13 without cataloguing it — a §11 defect in + the standard itself, raised by `audit-core`. +2. **§9.4 evidence rationale rewritten** to cite `audit-core`'s shipped + `docs/integrity.md` bound rather than its INTENT principle 6, and to state + that `tamper_evidence` is conditional on live preconditions. +3. **§9.4 gained emission atomicity** as `approval-engine`'s obligation, and the + prohibition on `audit-core` exposing an approval-validity query. +4. **§9.6 added** — evidence proves alteration and truncation, not omission at + source. Estate-wide; the sound and unsound forms of the claim are stated. +5. **§13** — evidence half recorded as assented with conditions; two new gaps: + stronger approval custody (unassigned) and emission atomicity + (`approval-engine`). + +## 16. Open questions + +- ~~Whether approvals warrant archival custody stronger than every other audit + source.~~ **Decided (§13): no.** Approval evidence carries the same bound as + every other source. The acute risk for approvals is *omission* — a suppressed + revocation — and archival custody does not address omission at all; emission + atomicity with a local outbox (§9.4) and a detection surface + (`GH-WP-0002-T04`) do. Leaving it open while calling the evidence half + load-bearing created a promise the archive cannot cash. If a future + requirement genuinely needs WORM or a transparency log, that is a different + store with a different owner, raised then. +- Whether SSH certificate issuance evidence is load-bearing or attributive + (§9.6). Ruled attributive here on the argument that no control branches on the + presence of a signing record; `ops-warden` asked for the ruling and the trade + is genuinely two-sided, so it is flagged rather than settled. +- ~~Who marks an approval consumed, and at what point relative to the decision + (§9.4).~~ **Decided (§9.7.3): the PEP, by compare-and-swap, before the + protected side effect.** The PDP never mutates and Staff never consumes. The + three failure modes have owners in + `gate-house/docs/contracts/approval-consumption.md`; there is no unconsume. + `GH-DEC-2026-003`, and `GH-DEC-2026-008` for the binding correspondence. +- Whether other §4 repositories are missing layer declarations; `audit-core` + flagged its own absence and asked whether the catalog needs the same + correction elsewhere. +- ~~Whether the gap register migrates from this standard into `maturity-engine` + once that engine exists, leaving the standard to state the rules only.~~ + **Decided (§13.1): yes, conditioned on a published export.** The engine holds + both registers as data; the migration waits on a committed, versioned export + readable without a live query, because a standard must stay legible in git to a + reader with no cluster access. `GH-DEC-2026-006`. +- ~~Whether §6.4's `unknown` ruling should extend to other total-map scopes that + are absent rather than unknown.~~ **Closed** during v0.8's circulation. It + extends, and the distinction is not a distinction in the stance: `absent` fails + closed too, for the stronger reason that it is the branch reached by discovering + the author's model of their own axis was wrong. The distinction is in the + record — an `absent` hit is a conformance failure and MUST be distinguishable + from an `unknown` hit, or obligation 3's totality requirement is satisfied + vacuously by a catch-all. §6.4 obligation 3; answered by `access-engine`, which + raised the question's real cost from its own 29-fixture tenant defect. +- Whether Tooling warrants subdivision between third-party and homegrown. +- How a future `role-engine` divides responsibility with `access-engine`. +- Whether declared gaps need an estate-wide register rather than per-repository + declarations; ops-warden's `warden route gaps` is candidate machinery. +- Whether non-security repositories adopt the same model. The determinism cut is + not security-specific; if non-security Staff also may not hold + runtime-dependent state, the estate gets one constitution rather than a + security ghetto. +- The rest of §9.8: split brain, partial PIP reachability, and clock skew beyond + the two rules stated. +- Publication integrity of the Taxonomy layer itself. This standard demands + reconstructability of decisions while its own publication path has no digest, + freeze, or rollback discipline. `access-engine` observed during v0.8's + circulation that the same observation applied to the artifact this standard + *regulates* is §6.4 obligation 1's attribution gap — the defect was visible from + inside and had been recorded against the wrong artifact. That half is now a + declared §13 gap; this entry is the half that remains open, and it is this + standard's own. +- The fitness verdict formerly at §19 now lives in + `net-kingdom/history/2026-08-29-layering-standard-assessment.md`. A grade + inside a standard of record becomes normative by adjacency and ages against the + text it grades. Raised by `access-engine`. Its two substantive points remain + live: observation in production is unstaffed (§12) and actuation has no surface + (§9.2). +- The **working companion** (`net-kingdom/SECURITY-COMPANION.md`, v0.2, root of + the repository for onboarding) is the operative form of this statute. The statute governs on disagreement, and a + disagreement is a finding. The v0.1 gap `access-engine` found — publish + your stance map, but nowhere saying where, and no inventory obligation — is + fixed in v0.2 §5.3. +- How the Railiance operational axes meet this model beyond §20's first + statement, which is deliberately minimal. + +--- + +## 17. Taxonomy artifacts + +§6.2 says doctrine reaches a decision as an input claim or a versioned policy +rule. As prose that is a rule a reviewer can apply. As an interface it does not +exist, because nothing defines what a claim *is*. §11 calls itself mechanically +checkable while resting on that gap. + +Four artifacts are therefore required and versioned like any standard. **Two of +the four are not Taxonomy's**, and each is settled below rather than open: the +decision-record schema is `access-engine`'s, and the emission-cadence declaration +is split between `info-tech-canon` and `net-kingdom`. The table names all four +because §6.2 needs all four to exist, not because Taxonomy owns all four. + +| Artifact | Contents | +| --- | --- | +| **request-claim schema** | identity, tenant, zone stance, posture, approval, maturity, assurance — each with its issuer and freshness rule | +| ~~decision-record schema~~ | **moved to `access-engine`** — see below | +| **gap-record schema** | the §5.3 fields — `capability`, `intended_owner`, `blocked_on`, `review` — plus the §13 `state` and owner-status | +| **emission-cadence declaration** | the expected rate a source publishes, so silence is a finding (§9.6) | + +Until these exist, §6.2 and §11 are reviewable but not compileable, and every +engine invents its own claim shape at its own boundary. + +**The decision-record schema is not Taxonomy's.** A decision record is the PDP's +output artifact — the one thing in the estate only `access-engine` produces — and +§2 keeps ownership in the producing repository's own `INTENT.md`. Taxonomy +authoring the schema for an artifact only one engine emits would invert the +ownership rule this standard applies everywhere else. `access-engine` publishes +it as a contract; Taxonomy holds only the shared field vocabulary the claim +schema references. + +Raised by `access-engine` **against its own interest** — the same §2 argument it +used to decline authentication evidence, applied where it takes work on rather +than off. Symmetry of that kind is what makes the ownership rule credible. + +**The emission-cadence declaration has a drafter.** `kings-guard` is its only +consumer, cannot implement silence-as-signal without it, and has offered to draft +it against `qonto-assistant` and hand it to whichever Taxonomy repository takes +ownership — rather than inventing a local shape, which is the drift §17 exists to +prevent. Accepted as a draft; ownership still rests with Taxonomy. + +**Ownership of the emission-cadence declaration is assigned.** `info-tech-canon` +owns the versioned, ecosystem-wide `EmissionCadenceDeclaration` semantic contract +— generic forms, fields, vocabulary, validation semantics, compatibility, and +evolution. `net-kingdom` imports it and owns the NetKingdom security profile: +which evidence classes MUST or SHOULD declare cadence, the prohibition on rate +monitoring for rare load-bearing classes, and the heartbeat-plus-reconciliation +obligations that satisfy §9.6. Each source repository owns its declaration +instance and its emission behaviour; `kings-guard` owns stream evaluation and +silence findings, not the schema. + +The split was made by artifact so each has one owner: joint ownership would leave +version authority ambiguous, and giving the whole artifact to either repository +would conflate a reusable evidence contract with the security obligations of one +estate. Settled in `GH-DEC-2026-004`; both repositories accepted in their own +voice (`ITC-WP-0018`, publishing `ITC-EMISSION-CADENCE 0.1` in canon `0.7.0`; +`NK-WP-0035`, publishing `emission-cadence-security-profile_v0.1.md`). The +`kings-guard` draft is frozen as assimilation provenance. + +**Exactly two artifacts are unsettled: the request-claim schema and the +gap-record schema.** Both sit between `info-tech-canon` and `net-kingdom` on the +same line, and neither has an owner in its own voice yet. The other two are +settled above — the decision-record schema is `access-engine`'s, and the +emission-cadence declaration is assigned and accepted by both its owners. §2 keeps +ownership in the owning repository's `INTENT.md`. + +This paragraph read *"the remaining three artifacts is still proposed"* while +settling one of the three in its own next clause, so a reader checking whether the +decision-record schema needed an owner found it listed among the unsettled — after +`access-engine` had taken it on against its own interest. Raised by +`approval-engine`; v0.8's item 10 corrected the emission-cadence paragraph and did +not reach this one. + +## 18. Composition with the sibling standards + +The related-standards list has been frontmatter and little else. If the +following sentences cannot be written, the list is decoration — so they are +written here rather than in the siblings. + +**Zone stance** (`security-zones_v0.1`). A zone answers which scrutiny a +workload has qualified for; membership is `zone-engine`'s. The *effect* of a +zone on a decision belongs in a versioned `access-engine` policy package, never +in registry content — that ruling is zone-engine's §5, and §6.1 is its +generalization. Zone stance therefore enters a decision as a **claim on the +request or a rule in the package**, and a decision that turned on a zone must +name the package version that read it. + +**Tenancy posture** (`tenancy-posture_v0.1`). Posture is a bounded security-state +input, published by its owner and never a privilege source (§8). It enters as a +**claim**, carries its own freshness, and the §8 asymmetry binds it: posture may +tighten a decision and may never loosen one. A posture too stale to trust is a +missing claim, and a missing claim is not permission. + +**Credential lifecycle** (`credential-management_v0.2`). Issuance, rotation, and +revocation are `secrets-engine`'s and `OpenBao`'s, downstream of a decision — a +credential is an artifact of authority, never its source. A lifecycle event +becomes an **input** to a later decision as a claim (this credential is current, +this lease is bound to this task), never a side channel that changes an outcome +without appearing in the decision record. Revocation visibility is bounded by +§9.7. + +Each of the three composes the same way, which is the point: **facts arrive as +claims, effects live in versioned policy, and anything that changes an outcome +appears in the decision record.** + +--- + +## 19. *(retired)* + +There is no §19. It held a maturity grade for `qonto-assistant`, removed because a +grade inside a standard of record becomes normative by adjacency — it is an +assessment, and assessments belong in `maturity-engine` and in dated review +records. The number is not reused, so references written against earlier versions +do not silently repoint. Retirement recorded in §16 and in +`gate-house/history/`; raised by `access-engine`, and the stub added because a +reader who sees §18 followed by §20 cannot otherwise tell whether an edit dropped +a section (raised by `approval-engine`). + +## 20. The Railiance interaction boundary + +Operations is not NetKingdom's. Workload operations are organized by +**Railiance**, whose framework repository is `railiance-master`, and NetKingdom +provides the security and approval framework those operations consume. This +section states the boundary as it stands today. It is expected to evolve, and it +is written here so that evolution is visible rather than inferred. + +Definitions are `railiance-master`'s and are restated, not authored, here. + +### 20.1 What Railiance organizes + +A **workload** is a managed running deployable. Human commands, credential +patterns, broker actions, approvals, and infrastructure resources that are not +themselves deployables **are not workloads** — which is why an approval object +(§9.4) is not a Railiance axis and never becomes one. + +Every workload is operated through four composable axes, each answering a +different question about the same workload: + +| Prefix | Axis | Question | +| --- | --- | --- | +| `railiance-*` | ownership | Who owns this capability? | +| `rail-*` | execution contract | How does this workload run? | +| `rapp-*` | managed package | What exactly is packaged and operated? | +| `reef-*` | substrate | Where is it bound, and as what operational reality? | + +`rein-*` is **not a fifth axis**. Reins are `glas-harness` agent-harness +backends; the name echoes `rail-*` analogically, not taxonomically. Agentic +session semantics — session loops, tool policy, harness routing, model selection +— belong to `glas-harness`. When a rein is installed and operated as a managed +service it is a workload like any other, packaged and bound through the four +axes above. + +### 20.2 What holds today + +For any Railiance consumer of NetKingdom security, without exception: + +1. Authorization decisions come from `access-engine` and from nowhere else (§6). +2. Approvals are objects in `approval-engine`, consumed as claims (§9.4). +3. Credentials are materialized by `secrets-engine` **after** a decision, never + as a substitute for one. +4. Evidence goes to `audit-core` under the bound in §9.6. +5. Anything causing a protected side effect is **PEP-shaped** and owes the four + obligations in §6.4 — including a published unreachable-engine stance in the + §13.1 register. + +### 20.3 What is not settled + +The mapping between the axes and this model is deliberately thin, because +guessing it would be worse than admitting it: + +- A **`rapp-*`** is the most likely *resource* a decision is rendered about, but + nothing states its identity form in a request claim. +- A **`rail-*`** describes how a workload runs and is therefore where PEP shape + is most likely to live — but §6.4 obligations attach to repositories, and a + rail is a contract, so whether a rail can *carry* an obligation is unwritten. +- A **`reef-*`** answers where a workload is bound, which is adjacent to a + security zone (`security-zones_v0.1`) without being one. `zone-engine` records + that a reef capping availability for everything bound to it is a canon + composition problem. That composition is unwritten. +- The **`railiance-*` ownership axis** names who owns a capability, which is + adjacent to the principal a decision is rendered for. Adjacent is not equal, + and no rule connects them. +- **`glas-harness` and reins** hold tool policy and session semantics for agents, + while §3.4 rule 2 holds that an agent acts only through a conduit or an engine + API. Those two must compose, and neither side may treat its own half as + sufficient. That seam is the most consequential of the five, because it is + where "tool availability is not permission" is actually enforced or lost. + +### 20.4 How this boundary changes + +An interaction boundary between two frameworks is owned by neither alone. +Changes to §20 require assent from `railiance-master` for the axis definitions +and from `glas-harness` for the session and tool-policy seam, on the same terms +as any other boundary in this standard (§10). NetKingdom states what a consumer +owes; it does not define what a rail, rapp, reef, or rein *is*. diff --git a/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.md b/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.md new file mode 100644 index 0000000..f190893 --- /dev/null +++ b/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.md @@ -0,0 +1,105 @@ +--- +reviewer: net-kingdom-owner (agent net-kingdom, codex) +decision: approved +work_item: NK-WP-ADHOC-2026-10-11-T03 +reviewed_manifest_sha256: 271afd04512b3dac642b3385013cac03d28afde22ff97bcca8d0e262ab3d9279 +scope: proposed-source-technical-review-only +--- + +# NetKingdom owner review — Forgejo consumer ESO successor + +Technical source agreement on the exact frozen 17-path proposal, manifest SHA256 +271afd04512b3dac642b3385013cac03d28afde22ff97bcca8d0e262ab3d9279. This is the +established NetKingdom owner role only, under NK-WP-ADHOC-2026-10-11-T03. The +work record was prepared before this review entry; the applying coordinator must +retain that order and sync the owner work record. This review does not change +any admission, bound-claim, type or case status. + +NetKingdom INTENT's Taxonomy declaration, Identity is the Control Plane, +Minimize Threat Exposure and Meta-Orchestration principles support a named, +inspectable identity contract and owner-executed changes. NetKingdom owns the +canonical type, case and responsibility map. Railiance owns deployment mechanics; +platform, consumer, Mason and Warden retain their distinct native execution and +acceptance responsibilities. Working companion v0.3 and accepted layer-model +v0.8 remain unchanged. The Emergent Security start card was withheld after source +changes (package0.2.6, digest8d1d6a9d4d07fec7b619618de7dfe2be2254c1790f85f4198c7fe19db9751c02); +this review uses the actual source files, not withheld guidance. + +## Exact correction and independent evidence + +Initial packet c48b64e5e704e8f11ca65095c376c8a9fecc2b3a58e74b9eb62096c80d00f4fb +incorrectly described the proposed CCR42 as rendered from an acknowledged type. +The requester preserved it at /tmp/forgejo-consumer-eso-refinement-original-c48 +and changed only CCR42 risk.notes[0]. The final note truthfully names proposed1.2, +preparation-only observations, unconfirmed/apply-blocked bindings and a fresh +§6 informed-decision acknowledgment. Independent parsed comparison confirms this +is the only semantic change. Final proposed CCR42 SHA256 is +6544600c63a86559ba053240c476d493f4d2f25c9cd22cf6a9a05f09ee617a86. + +Independently verified all 17 staged hashes and all seven current owner source +pins. Current native type/case validators passed in preparation mode +(require_implemented=False); composition resolution and full render regeneration +were byte-semantically identical to retained render. Full render digest is +sha256:c0afd5576cdae0cbc807eccb2b9fa87ac668f15e32ec7cf79d295bdb23c75b35, and +execution.permitted remains false. Rendering the current1.1 case with the same +current declarations proves all five original structural objects are exactly +unchanged; the proposed sixth object is consumer-eso-role. This is not structural +equality of the whole inventory and cannot transfer old acceptance. Full source +hashes bind composition, follow-through, verification and rollback as well as +structure. Any acknowledgment or accepted-case source change needs new exact +source pins and render/case reconciliation; the old digest is no permission. + +The minimal Mason CCR-filename collision/refusal changes and their tests are +byte-unchanged by the risk-note amendment. The independent Mason owner reports +42 focused passes and an original-source regression failure, and confirms the +proposed source is refused rather than fixture-acknowledged. Those are isolated +source checks, not installed/native materialization proof. + +## Identity contract and retained trust boundary + +The new role binds only forgejo/forgejo-keycape-forgejo-eso and audience openbao, +with the one exact KV data read policy and no default policy. The Forgejo and +runner shared default SA must never be bound. Namespaced SecretStore uses the +dedicated serviceAccountRef with audiences=[openbao] and no namespace override; +ExternalSecret maps only CLIENT_SECRET. Installed-source/retained-metadata support +for TokenRequest and audiences supports this preparation, not an invented live +binding. The SA has automount=false and must have no legacy token references; +a TokenRequest failure must not be bypassed with a legacy/static token. ESO's +600-second Kubernetes token and role's 900-second OpenBao maximum are distinct. + +The shared controller's clusterwide TokenRequest/Secret authority remains a +trusted surface; neither a dedicated reference identity nor automount=false +provides controller-compromise isolation. Existing internal HTTP custody and +legacy-fallback risk remain stated. The proposal adds no default grants, +memberships, group authorization or application-runtime identity change. + +## Required separate acceptance and recovery stops + +The sixth role changes authentication/materialization. Under SecurityCaseTypes +§6 it needs a new founder informed-decision as for a new type, regardless of the +proposed1.2 label. This technical review is not that acknowledgment and does not +inherit acknowledged1.1. Current acknowledged type1.1, accepted case1.1 and +historical CCR42 remain unchanged. No successor case acceptance, implemented +marker, machine-contract acceptance or broad broker-pin relaxation is inferred. +Exact owner/founder receipts and current runtime/source pins must be reconciled +before successor build or execution; pending bound claims still block apply. + +Refresh native metadata and refuse conflicting/shared/unknown ownership before +an exact native action. Materialization receipts must prove six-object structure, +exact SA/namespace/audience/policy and created-versus-matched identities without +reading secrets. Existing Warden descriptors/session/revocation and per-owner +provenance gates remain. Delivery Ready cannot substitute for Forgejo Helm OIDC +consumption, group enforcement, break-glass/account-link/MFA and positive/negative +browser acceptance. These stay in their existing owner/project work records. + +Recovery starts with the consumer owner's reference/Helm rollback, then only +proved-created delivery objects and target UID/ownerReference. Matched/shared +objects stay protected. Revoke issued reader tokens or prove expiry before +removing the created role, then the policy. Role/SA deletion alone does not revoke +issued OpenBao tokens. Legacy planned inventory confers no delete authority; +changed references/UIDs/ownership stop recovery. Source preparation creates no +credential, role, policy, service account, value or client and closes no first-case +runtime task. + +No additional source correction is required in this exact corrected packet for +NetKingdom's technical review. Separate owner and founder dispositions remain due. diff --git a/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.sources.json b/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.sources.json new file mode 100644 index 0000000..975057b --- /dev/null +++ b/docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.sources.json @@ -0,0 +1,193 @@ +{ + "reviewed_manifest": { + "path": "/tmp/forgejo-consumer-eso-refinement-stage/manifest.json", + "sha256": "271afd04512b3dac642b3385013cac03d28afde22ff97bcca8d0e262ab3d9279" + }, + "initial_manifest": { + "path": "/tmp/forgejo-consumer-eso-refinement-original-c48/manifest.json", + "sha256": "c48b64e5e704e8f11ca65095c376c8a9fecc2b3a58e74b9eb62096c80d00f4fb" + }, + "amendment_receipt": { + "path": "/tmp/forgejo-consumer-eso-refinement-amendment-receipt.json", + "sha256": "e27a3f5a56565d270d8f038f77333aea13460135a16ae4e60a914dc5d17365c9" + }, + "staged_proposal_files": [ + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/consumer-delivery.yaml", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/consumer-delivery.yaml", + "original_sha256": null, + "staged_sha256": "56478a83d799c08dc1e5159983b1e843a46b16dfeee7e84c31401d1f92430df2" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/native-metadata.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/native-metadata.json", + "original_sha256": null, + "staged_sha256": "4e2993f5920215f41e4a235743023f22b78b8f597d3d70ed279991b2fc3204b5" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/observe-native-metadata.py", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/observe-native-metadata.py", + "original_sha256": null, + "staged_sha256": "3732aa0ff45b5197ac7837cbc5814f59ea3d694d4a157d19d00711f29da76913" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/owner-design.md", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/owner-design.md", + "original_sha256": null, + "staged_sha256": "a6d735ef1ebaddb062603e6a5b5a01a38d16658445c95bb2735dfbee9b714c9e" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/owner-source-pins.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/owner-source-pins.json", + "original_sha256": null, + "staged_sha256": "775971a60db57f7334f68b0916a27760e28f02c62f2c653e963237925a1c2711" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/primary-source-provenance.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/primary-source-provenance.json", + "original_sha256": null, + "staged_sha256": "c3d5ce5c6a5e89f19be5e293034c8d633183d19666fc61d837537527246d9a42" + }, + { + "repo": "railiance-apps", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/validation.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-apps/docs/proposals/2026-10-11-forgejo-consumer-eso/validation.json", + "original_sha256": null, + "staged_sha256": "013e073e826a4b863dc2f7c83fa59270de54de64cd8f19bd32238c91aa24b2de" + }, + { + "repo": "railiance-platform", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/CCR-2026-0042-proposed-body.yaml", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-platform/docs/proposals/2026-10-11-forgejo-consumer-eso/CCR-2026-0042-proposed-body.yaml", + "original_sha256": null, + "staged_sha256": "6544600c63a86559ba053240c476d493f4d2f25c9cd22cf6a9a05f09ee617a86" + }, + { + "repo": "railiance-platform", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/reader-role.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-platform/docs/proposals/2026-10-11-forgejo-consumer-eso/reader-role.json", + "original_sha256": null, + "staged_sha256": "976b19e0780b6056ed54bf5e8f27a0eb786af65817d9ec00ca161ac46e7d72e7" + }, + { + "repo": "railiance-platform", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/workload-kv-read-keycape-forgejo-forgejo.hcl", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/railiance-platform/docs/proposals/2026-10-11-forgejo-consumer-eso/workload-kv-read-keycape-forgejo-forgejo.hcl", + "original_sha256": null, + "staged_sha256": "af3a638605c1f6dff7879771fede4c56a6b9a7e430d4b5b58c370063b2c888ca" + }, + { + "repo": "net-kingdom", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/case-1.2.yaml", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/net-kingdom/docs/proposals/2026-10-11-forgejo-consumer-eso/case-1.2.yaml", + "original_sha256": null, + "staged_sha256": "1c868c1da7d9077fae97bc6bc029706ec3dc418cfeaae30dc0f92b5b4ba6f2ab" + }, + { + "repo": "net-kingdom", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/render-1.2.json", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/net-kingdom/docs/proposals/2026-10-11-forgejo-consumer-eso/render-1.2.json", + "original_sha256": null, + "staged_sha256": "96b25108335e2cf5f96af481fe8a7735831c8320d81b50f7c6e6d4e53d0c0f02" + }, + { + "repo": "net-kingdom", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/review-boundary.md", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/net-kingdom/docs/proposals/2026-10-11-forgejo-consumer-eso/review-boundary.md", + "original_sha256": null, + "staged_sha256": "21c8d666a46490f829cfb9c043ea168ad1c02873dc6baf7e50173188e0c99ea9" + }, + { + "repo": "net-kingdom", + "path": "docs/proposals/2026-10-11-forgejo-consumer-eso/type-1.2.yaml", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/net-kingdom/docs/proposals/2026-10-11-forgejo-consumer-eso/type-1.2.yaml", + "original_sha256": null, + "staged_sha256": "017885bdd139cd66a5bf6d9839b1b8ec9bc08fb051d9577adc3928b76a7be6db" + }, + { + "repo": "ops-mason", + "path": "docs/forgejo-consumer-eso-builder-review.md", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/ops-mason/docs/forgejo-consumer-eso-builder-review.md", + "original_sha256": null, + "staged_sha256": "8930aa8269eab247a66f0f72ae138a2a8ba9a3f85523b65f2b44dfb4f7785429" + }, + { + "repo": "ops-mason", + "path": "src/ops_mason/case_build.py", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/ops-mason/src/ops_mason/case_build.py", + "original_sha256": "249cc8574939d2c3193f968309781c472c96c199e04206c336463b4d65ea6659", + "staged_sha256": "2e1d9cec6a47bb0e9b76f5446f5a58cc02275bcf35bae1779bbeac015b91a243" + }, + { + "repo": "ops-mason", + "path": "tests/test_case_build.py", + "staged_path": "/tmp/forgejo-consumer-eso-refinement-stage/ops-mason/tests/test_case_build.py", + "original_sha256": "177e8feed5d1af9abe96522fb5399780b3199daed6bf360882398044357071bc", + "staged_sha256": "7a4789857b76c9cc585f58d8689e05e803cd69203ca25be0b900786e401dca20" + } + ], + "owner_sources": [ + { + "path": "/home/worsch/net-kingdom/AGENTS.md", + "sha256": "065d47b7bdbfe829672a2a6161a7f8cf243237a1210fb61d82f153fa37f22131" + }, + { + "path": "/home/worsch/net-kingdom/INTENT.md", + "sha256": "fd2ba8dff9dfd5583ec6d8b0348f273bfe00c59923b5d5d47cd22b1fb4658c54" + }, + { + "path": "/home/worsch/net-kingdom/SECURITY-COMPANION.md", + "sha256": "06374445ca888549f1bf79527d1345d94918d7a7ec363160d8427d0e7a31d643" + }, + { + "path": "/home/worsch/net-kingdom/canon/standards/security-layer-model_v0.8.md", + "sha256": "3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b" + }, + { + "path": "/home/worsch/net-kingdom/canon/standards/security-case-types_v0.1.md", + "sha256": "a4fda906d5138d2594a1f8d047c7c28e1cdf96b1eae051f543b9a5e5852bcb5e" + }, + { + "path": "/home/worsch/net-kingdom/security-case-types/oidc-browser-relying-party/type.yaml", + "sha256": "f705c64e4875e9b8e18a912fb51c135e77898926d6a451f5cb74ab3c0cbe4d1c" + }, + { + "path": "/home/worsch/net-kingdom/security-cases/forgejo-netkingdom-oidc.yaml", + "sha256": "bcc2c6d5bae0d28242b3cdb71e74d8ca297c2afe04766b55d53597f86893351d" + }, + { + "path": "/home/worsch/net-kingdom/tools/security-case-types/security_case_validator.py", + "sha256": "ef380a85ca9949e0ebc59d1cdce422bd45e362eb976330b2b72b8fd73784ae0a" + }, + { + "path": "/home/worsch/net-kingdom/tools/security-scenario-composer/security_scenario_composer.py", + "sha256": "9f0cc69930aa8ee2cc3fb92236e6a99728df17b8c0fe36e1250241c38fc01c4f" + }, + { + "path": "/home/worsch/the-custodian/canon/standards/delegated-owner-review_v0.1.md", + "sha256": "d372b2ad21849a18d90d40636fad3c31425b2bd61f0778f43e57c62402a06d6c" + } + ], + "independent_checks": { + "reviewed_manifest_sha256": "271afd04512b3dac642b3385013cac03d28afde22ff97bcca8d0e262ab3d9279", + "original_manifest_sha256": "c48b64e5e704e8f11ca65095c376c8a9fecc2b3a58e74b9eb62096c80d00f4fb", + "manifest_files_verified": 17, + "amendment_verified_only_risk_note": true, + "type_validation_pass": true, + "case_validation_pass_preparation_only": true, + "source_render_regeneration_identical": true, + "render_digest": "sha256:c0afd5576cdae0cbc807eccb2b9fa87ac668f15e32ec7cf79d295bdb23c75b35", + "old_five_structural_objects_exactly_equal": true, + "added_structural_object": "consumer-eso-role", + "seven_current_source_pins_verified": true, + "mason_code_and_tests_unchanged": true, + "native_mutation": false, + "execution_permitted": false + } +} diff --git a/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.md b/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.md new file mode 100644 index 0000000..90feefc --- /dev/null +++ b/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.md @@ -0,0 +1,58 @@ +--- +reviewer: net-kingdom-owner (agent net-kingdom, codex) +decision: approved +work_item: NK-WP-ADHOC-2026-10-11-T04 +scope: bounded-handoff-reception-and-proposed-source-assembly-only +--- + +# NetKingdom source-owner reception of GH-DEC-2026-025 + +NetKingdom accepts the source-owner handoff for assembly, not whole-revision +adoption. Under INTENT's Taxonomy declaration and Meta-Orchestration principle, +NetKingdom holds canonical source and publication; Gate House supplies doctrine, +InformedDecision records the actual human act, and PolicyNexus retains its own +accepted-source publication route. This is the same established NetKingdom role, +not a review for another owner. Own T04 is completed before this entry; the +applying coordinator must first retain live NET-IN-0004 and the owner work record. + +Reviewed exact handoff SHA256 +1fd8dc06d417c7a0d97920ddc1e51b0fb28113efb8047a8380cd2b9d3ff3289c against the +accepted bounded proposal08bc78a29c2b67cec0aafba993fb2d25312b629ecccb81458980baafe38e566a +and native receipt eb67e6db46acc3d1eb102ae541c60508379c216061a4c694fb4aee35dc845a7b. +The retained native outcome confirms a nonstale version1 person ACCEPT at +2026-10-11T01:46:25Z, approval d90c899b-f25c-4e66-a003-808ee5b1324f and disposition +disp-24e94200-ed93-4a18-900c-3128d26ba212. Its scope is the exact bounded doctrine +proposal; it does not ratify whole v0.9 or authorize native publication/deployment. + +Proposed successor security-layer-model_v0.9.md SHA256 +28331f0ccbbede3a47ca24dfe11a6ce84635419d7ed3feb60e9af9a90d8f66e6 carries the exact +complete §3.4 paragraph block, §4 row, replacement evidence-values paragraph and +per-event paragraph. All four match both handoff and immutable approved proposal; +no partial slicing or inferred normative wording is used. The only changed body +sections are3,4,14,15:3/4 are the approved candidate,14 and15 provenance/adoption +annotations. All other body sections match accepted v0.8 exactly. Frontmatter and +title label v0.9 proposed and omit predecessor acceptance markers; historical +assent/adoption records are explicitly predecessor provenance, not successor assent. + +Accepted v0.8 remains operative and byte-identical at SHA256 +3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b. Its current +companion, serving source and checker pins remain unchanged. No broader model +revision, new layer, permission or source conformance is introduced. Existing +Staff prohibitions and approval-engine/access-engine ownership remain binding. + +The §3.4 deterministic-evidence tension remains unresolved. The informed-decision +Staff/PEP-shaped evidence=yes row identifies obligations, not satisfaction; +presentation remains volume/load-bearing, disposition and stance-application +rare/load-bearing, with class-specific guarantees owed until source-owner proof. +No delivered row, human bind, layer agreement, detector PASS or independent custody +claim proves whole-class emission or honest display. No mandatory-evidence failure +exception is added. Finished INFD-WP-0005/0007 remain historical evidence and are not +reopened solely from stale declarations. Source-owner class-specific reconciliation +remains distinct; INFD-IN-0007 awaits actual accepted standard voice. + +Gate House can distinguish its completed doctrine disposition/handoff from the +pending standard adoption now held in live NET-IN-0004. NetKingdom must obtain +required exact whole-revision disposition/reviews before acceptance annotations, +operative companion/checker repointing and subsequent owner publication. This +review supplies source reception/assembly only and performs none of those steps. +No further bounded text correction is required for this exact proposed assembly. diff --git a/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.sources.json b/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.sources.json new file mode 100644 index 0000000..36e0980 --- /dev/null +++ b/docs/reviews/2026-10-11-staff-evidence-handoff-owner-review.sources.json @@ -0,0 +1,74 @@ +{ + "assembly_checks": { + "handoff_sha256": "1fd8dc06d417c7a0d97920ddc1e51b0fb28113efb8047a8380cd2b9d3ff3289c", + "human_receipt_sha256": "eb67e6db46acc3d1eb102ae541c60508379c216061a4c694fb4aee35dc845a7b", + "proposal_sha256": "08bc78a29c2b67cec0aafba993fb2d25312b629ecccb81458980baafe38e566a", + "successor_sha256": "28331f0ccbbede3a47ca24dfe11a6ce84635419d7ed3feb60e9af9a90d8f66e6", + "accepted_v08_sha256": "3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b", + "exact_candidate_blocks_match_handoff_and_approved_proposal": true, + "accepted_v08_unchanged": true, + "proposed_successor_status": "proposed", + "native_human_acceptance_bounded_only": { + "actor": { + "kind": "person", + "sub": "uid=platform-root,ou=people,dc=netkingdom,dc=local" + }, + "approval_id": "d90c899b-f25c-4e66-a003-808ee5b1324f", + "at": "2026-10-11T01:46:25Z", + "id": "disp-24e94200-ed93-4a18-900c-3128d26ba212", + "memo_id": "review-2e615985-54c9-40d8-8547-b8fdcb10b1d6", + "memo_version": 1, + "note": null, + "presentation_id": "pres-f44a4a5d-6998-422c-b46e-da7af46906f6", + "reasons": [], + "verb": "accept" + }, + "live_adoption_owner_record": "NET-IN-0004", + "cumulative_adhoc_requires_prior_T03_return": true, + "only_changed_body_sections": [ + 3, + 4, + 14, + 15 + ], + "other_normative_sections_exactly_unchanged": true + }, + "sources": [ + { + "path": "/home/worsch/net-kingdom/AGENTS.md", + "sha256": "065d47b7bdbfe829672a2a6161a7f8cf243237a1210fb61d82f153fa37f22131" + }, + { + "path": "/home/worsch/net-kingdom/INTENT.md", + "sha256": "fd2ba8dff9dfd5583ec6d8b0348f273bfe00c59923b5d5d47cd22b1fb4658c54" + }, + { + "path": "/home/worsch/net-kingdom/SECURITY-COMPANION.md", + "sha256": "06374445ca888549f1bf79527d1345d94918d7a7ec363160d8427d0e7a31d643" + }, + { + "path": "/home/worsch/net-kingdom/canon/standards/security-layer-model_v0.8.md", + "sha256": "3d8298560069ef471fba28d2b1245fb2309328f231dad1a667cdf0ce5a5a7c8b" + }, + { + "path": "/home/worsch/gate-house/docs/amendments/2026-10-11-staff-evidence-disposition-handoff.md", + "sha256": "1fd8dc06d417c7a0d97920ddc1e51b0fb28113efb8047a8380cd2b9d3ff3289c" + }, + { + "path": "/home/worsch/gate-house/docs/amendments/informed-decision-staff-evidence-disposition-proposal.md", + "sha256": "08bc78a29c2b67cec0aafba993fb2d25312b629ecccb81458980baafe38e566a" + }, + { + "path": "/home/worsch/gate-house/docs/evidence/2026-10-11-staff-evidence-human-disposition.json", + "sha256": "eb67e6db46acc3d1eb102ae541c60508379c216061a4c694fb4aee35dc845a7b" + }, + { + "path": "/home/worsch/gate-house/decisions/decisions.md", + "sha256": "a5e227d462627ed7f25029267f204d0c5af0438c05240f601765b7cbfff82299" + } + ], + "proposed_source": { + "path": "canon/standards/security-layer-model_v0.9.md", + "sha256": "28331f0ccbbede3a47ca24dfe11a6ce84635419d7ed3feb60e9af9a90d8f66e6" + } +} diff --git a/intakes/intakes.md b/intakes/intakes.md index 811fdf9..e48def5 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -73,3 +73,64 @@ updated: '2026-08-29' state_hub_intake_id: "01a06eb9-c4af-7a9e-8ff5-1bc5f845eb38" ``` + +## NET-IN-0003 — Demand-deferred workload-requested step-up interoperability + +```yaml +id: NET-IN-0003 +kind: intake +title: 'Demand-deferred workload-requested step-up interoperability' +status: open +flavor: residual +origin: residual +origin_ref: NK-WP-0042 +priority: low +owner: net-kingdom +requested_by: net-kingdom +created: '2026-10-10' +updated: '2026-10-10' +description: > + Proposed IAM v0.4 carries the acr_values strength and max_age freshness + contract, but no arbitrary-client workload-requested step-up integration + has been accepted. The founder selected optional MFA on coulomb-social + with no acr_values=aal2 switch-on (user-engine/docs/mfa-pilot-decision.md). + Keep this demand-deferred: promote only for a named workload requirement + and separately approved issuer/client policy. On promotion coordinate + KeyCape enforcement, user-engine enrollment/recovery and workload/PDP + assurance; prove no-factor refusal, enrollment return, stale AAL1 and + provider unavailability with actual-user acceptance. Existing optional + U05-U08 acceptance stays live in USER-WP-0027-T04 / USER-WP-0028-T03 + and decision cef97ccd; it is not deferred by this intake. +state_hub_intake_id: "01a12705-4400-7121-b326-1f63135bcab4" +``` + +## NET-IN-0004 — Adopt and publish the bounded Staff-evidence successor source + +```yaml +id: NET-IN-0004 +kind: intake +title: 'Adopt and publish the bounded Staff-evidence successor source' +status: open +origin: cross-repo +origin_ref: GH-WP-0004-T06 / GH-DEC-2026-025 +priority: medium +owner: net-kingdom +requested_by: gate-house +created: '2026-10-11' +updated: '2026-10-11' +description: > + The confirmed founder disposition accepts the bounded doctrine proposal, + not an entire successor standard. Proposed security-layer-model_v0.9.md + assembles only its exact section3.4/4 candidate. Obtain exact successor + source-owner/doctrine review and separate required whole-revision acceptance + before acceptance annotations, operative companion/checker repointing or + PolicyNexus owner publication. Retain acceptedv0.8 SHA3d829856 unchanged. + Existing GH-WP-0004 holds GateHouse doctrine/checker responsibilities; this + one owner intake retains source adoption/publication without a parallel plan. + Source receipt completes GateHouse handoff, not standard adoption. + INFD-IN-0007 waits for the accepted standard voice. Staff tension stays + unresolved; per-event guarantees remain owed until source-owner class-specific + reconciliation returns proof. Finished INFD-WP-0005/0007 remain historical + receipts and must not be reopened solely from stale declarations. + No deployment, credentials or runtime conformity is authorized here. +``` diff --git a/workplans/ADHOC-2026-10-11.md b/workplans/ADHOC-2026-10-11.md index de4d182..9210040 100644 --- a/workplans/ADHOC-2026-10-11.md +++ b/workplans/ADHOC-2026-10-11.md @@ -11,6 +11,7 @@ topic_slug: netkingdom created: "2026-10-11" updated: "2026-10-11" related: [GH-WP-0004] +state_hub_workstream_id: "930ae9b3-4769-57ce-bb77-ba2a997f653e" --- ## Review exact requested successor-canon amendment without publication @@ -19,6 +20,7 @@ related: [GH-WP-0004] id: NK-WP-ADHOC-2026-10-11-T01 status: done priority: medium +state_hub_task_id: "9dd7fb12-1ca4-5fd5-94e7-a75dd3e00939" ``` Source-owner review only of GH-WP-0004-T06-r1, exact proposal SHA256 @@ -36,6 +38,7 @@ is asserted. Review and exact sources are retained in docs/reviews/. id: NK-WP-ADHOC-2026-10-11-T02 status: done priority: high +state_hub_task_id: "60c1a740-75ac-56f8-bee8-905e7d236460" ``` NetKingdom-only source-owner review of applied refined nine-file User Engine @@ -47,3 +50,46 @@ runtime go, catalogue write, default role/grant or normal PDP bypass permission is inferred. The fresh User Engine owner supplies its distinct review; this worker signs only the established NetKingdom owner role. Exact review/sources are retained in docs/reviews/. + +## Review the exact Forgejo consumer ESO successor source + +```task +id: NK-WP-ADHOC-2026-10-11-T03 +status: done +priority: high +``` + +NetKingdom-only source-owner review of the frozen 17-path Forgejo consumer ESO +successor proposal. Initial manifest c48b64e5e704e8f11ca65095c376c8a9fecc2b3a58e74b9eb62096c80d00f4fb +contained a misleading acknowledged-type risk note; the requester corrected it +and retained that original revision. Final manifest +271afd04512b3dac642b3385013cac03d28afde22ff97bcca8d0e262ab3d9279 independently +verified, including the sole risk-note amendment, all 17 paths, seven current +source pins, native source validators, identical full render regeneration and +exact preservation of the original five structural objects plus a sixth role. +Technical source agreement only: SecurityCaseTypes §6 requires a new founder +informed-decision acknowledgment for this authentication/materialization change; +current type/case1.1, historical CCR42 and all native state remain unchanged. +No type/case acknowledgment, binding admission, materialization, credential +grant or live delivery is authorized. Exact review and evidence retained in +docs/reviews/2026-10-11-forgejo-consumer-eso-net-owner-review.*. + +## Receive the accepted bounded doctrine handoff and assemble proposed source + +```task +id: NK-WP-ADHOC-2026-10-11-T04 +status: done +priority: high +``` + +Received exact GH-DEC-2026-025 / GH-WP-0004-T06 source-owner handoff after +confirmed person ACCEPT d90c899b-f25c-4e66-a003-808ee5b1324f at2026-10-11T01:46:25Z +of proposal08bc78a29c2b67cec0aafba993fb2d25312b629ecccb81458980baafe38e566a. +Assembled the exact bounded §3.4/§4 candidate in proposed v0.9 only; accepted +v0.8 stays byte-identical/operative. Reviewed full paragraph/row equality against +both immutable proposal and handoff, native receipt scope, unchanged other +normative sections and retained Staff/evidence limits. No whole v0.9 acceptance +or serving/deployment is inferred. Live successor adoption/publication is +retained first as NET-IN-0004; INFD-IN-0007 stays open pending accepted voice. +Gate House handoff completion is distinct from this source-owner's outstanding +standard adoption. No finished INFD implementation plan is reopened.