net-kingdom/canon/standards/security-layer-model_v0.8.md

id	type	title	domain	status	version	supersedes	owner	publication_owner	created	updated	last_reviewed	review_interval	source_revision	standard_token	assented_by	related
netkingdom-security-layer-model-v0.8	standard	NetKingdom Security Layer Model v0.8	netkingdom	proposed	0.8	canon/standards/security-layer-model_v0.7.md	gate-house	net-kingdom	2026-08-28	2026-09-07	2026-09-07	3m	gate-house@516ed4e	security-layer-model_v0.8	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	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.8

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, and an honest statement of what it cannot answer.

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

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.

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
info-tech-canon	Taxonomy	—	ecosystem-wide semantic contracts and terminology
net-kingdom	Taxonomy	—	NetKingdom standards of record; publication
key-cape	Tooling	—	packaged identity tooling; IAM profile; authentication
OpenBao	Tooling	—	secret storage, leases, PKI, dynamic secret engines
user-engine	Engine	PIP	users, accounts, memberships
tenant-engine	Engine	PIP	tenant-as-an-entity facts
zone-engine	Engine	PIP	zone identity and membership — offline reference conformance per its 2026-08-23 disposition
secrets-engine	Engine	Lifecycle	credential abstraction, custody, lifecycle
audit-core	Engine	Evidence	audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6)
access-engine	Engine	PDP	the policy decision — the only decision point (§6)
approval-engine	Engine	PIP	the approval object — durable, authenticated, consumable, atomically supersedable (§9.4)
maturity-engine	Engine	PIP	graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5)
gate-house	Staff	—	security doctrine, authority context, curriculum; conformance review — through maturity-engine (§9.5)
ops-mason	Staff	PEP-shaped	building and tearing down access routes and perimeters
ops-warden	Staff	PEP-shaped	operational access lanes, stewardship, runbooks; SSH certificate issuance — declared-gap (§9.1, §13)
kings-guard	Staff	—	adaptive defence and judgment; observation of Staff-reachable sources — identity and secret observation pending; proposes containment, which it does not own (§9.2)
whitehat-security	Staff	—	offensive validation

An actuation surface — reduce authority, require step-up, isolate a workload — is catalogued nowhere because it does not exist. See §9.2: it is an Engine concept held at zero, not a Staff capability.

access-engine is the ruled name for the repository currently called flex-auth; both denote the same authority until the governed rename completes. Execution conditions for that rename are recorded in its migration decision, not here.

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.

Four 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.

   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 SHOULD 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.

   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 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

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 INTENT.md frontmatter, or an equivalent declaration file. Without it this section asserts a property it cannot deliver — the defect this standard has now corrected three times elsewhere. ops-warden has implemented a reference form (layer.yaml, a conformance script, and a test covering the §5.2 no-authority property) and offered it to the repositories that have yet to declare. Raised by audit-core, which noted that flex-auth's conforming declaration is legible as one only by following its decision trail.

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 catalogued in §4 as a source of evidence declares its emission guarantee in its machine-readable layer declaration: 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; 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 now corrected four times. 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 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:

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
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	Shape
ops-warden	ops-warden/pep-stance.yaml	security zone	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
user-engine	user-engine/pep-stance.yaml	security zone	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	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	total over stage plus unknown; no implicit default; runtime-read; pinned to SHIPPED_STANCE by test
ops-mason	—	—	not published; catalogued PEP-shaped in §4

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. v0.7 remains accepted and in force until this version is accepted in its place; it is not patched.

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)
Not claimed	no repository has yet reviewed v0.8 as text, apart from net-kingdom's review of §11 and §17 against the profile it owns (2026-09-07: §17 confirmed in its own voice, §11 corrected). This version is circulated for that review before acceptance

Ten of this version's eleven changes were requested by another repository, seven of them by a repository arguing against its own interest or reporting its own error. The exception is §17's ownership correction, which gate-house found by auditing its own accepted text. 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

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. §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.

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 — a scope a consumer has never enumerated is not the same as one it cannot classify, and the standard does not yet distinguish them.
• 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.
• 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, owned by Taxonomy and versioned like any standard:

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.

Ownership of the remaining three artifacts is still proposed. The request-claim and gap-record schemas sit between info-tech-canon and net-kingdom on the same unsettled line; the decision-record schema is access-engine's, per above. §2 keeps ownership in the owning repository's INTENT.md.

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.

---

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.