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

Security Layer Model v0.5 — four reviews, nine changes

Browse source 
All four reviewing repositories returned findings on v0.4 and one contested a
rule. Every change below came from a reviewer, not from gate-house.

- §9.1 split into `pending` (no route, capability zero) and `declared-gap`
  (route exists under §5.3, capability works). v0.4's single mark would have
  forced a false "pending" onto ops-warden's production SSH issuance —
  the fix was worse than the defect, and the defect was in this section.
- §9.3 rewritten. flex-auth contested it and was right: it collapsed "engine
  reachable but degraded" with "engine unreachable", and the second has no
  evaluator in the path to express anything. Input degradation is the engine's;
  unreachability is the consumer's, bounded by a declared auditable total
  stance — which ops-warden ADR-0009 already satisfies. v0.4 had ruled against
  shipped behaviour in a repository that assented to it.
- §5 scoped: "Tooling-layer system" means a §4 Tooling row. Without this every
  Staff repository was in undeclared violation for writing progress events.
- §9.4 requires the outbox to be local — no synchronous audit-core dependency
  inside the state-change transaction, so an audit outage cannot block a
  revocation.
- §9.5 forbids compiling maturity levels into registry content while decision
  provenance carries no registry-snapshot digest.
- §9.6 gained load-bearing versus attributive evidence, the mirror rule that
  absence is not evidence of non-occurrence, and kings-guard's finding that
  suppression biases posture optimistic and silently.
- §11 gained a fourth state: blocked-clean, which MUST NOT rank below
  conforming. A repository that declined a break-glass path and left a
  capability at zero complied at cost; one that quietly opened a client and
  declared nothing did not.
- §11 gained a machine-readable declaration form; ops-warden's layer.yaml is
  the reference implementation.
- §13 gained state and owner-status columns; access-engine's decline of
  authentication evidence is recorded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
tegwick 2026-08-29 02:54:25 +02:00
parent bbdff49abf
commit 0efa06fe5c
4 changed files with 4019 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

3235
.repo-manager/index.json Normal file
View file

File diff suppressed because it is too large Load diff

2
README.md
View file

@ -12,7 +12,7 @@ The dynamic, self-optimizing security platform is the long-term direction in
## Orientation
- [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
- [Security layer model](canon/standards/security-layer-model_v0.4.md) — how the
- [Security layer model](canon/standards/security-layer-model_v0.5.md) — how the
security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
layer may own
- [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)

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

@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.4
type: standard
title: "NetKingdom Security Layer Model v0.4"
domain: netkingdom
status: proposed
status: superseded
version: "0.4"
supersedes: canon/standards/security-layer-model_v0.3.md
owner: gate-house
@ -14,6 +14,7 @@ last_reviewed: "2026-08-28"
review_interval: 3m
source_revision: "gate-house@516ed4e"
standard_token: security-layer-model_v0.4
superseded_by: canon/standards/security-layer-model_v0.5.md
assented_by:
- "flex-auth FLEX-DEC-2026-001"
- "kings-guard KG-DEC-2026-001"
@ -29,6 +30,11 @@ related:
# NetKingdom Security Layer Model v0.4
> **Superseded 2026-08-29 by [v0.5](security-layer-model_v0.5.md).** All four
> reviewing repositories returned findings; `flex-auth` contested §9.3 and was
> right. v0.5 splits §9.1 into two marks, rewrites §9.3, scopes §5, requires a
> local outbox in §9.4, and gives §11 a fourth conformance state.
## 1. Purpose
This standard states how NetKingdom's IT-security estate is layered, and what

776
canon/standards/security-layer-model_v0.5.md Normal file
View file

@ -0,0 +1,776 @@
---
id: netkingdom-security-layer-model-v0.5
type: standard
title: "NetKingdom Security Layer Model v0.5"
domain: netkingdom
status: proposed
version: "0.5"
supersedes: canon/standards/security-layer-model_v0.4.md
owner: gate-house
publication_owner: net-kingdom
created: "2026-08-28"
updated: "2026-08-28"
last_reviewed: "2026-08-28"
review_interval: 3m
source_revision: "gate-house@516ed4e"
standard_token: security-layer-model_v0.5
assented_by:
- "flex-auth FLEX-DEC-2026-001"
- "kings-guard KG-DEC-2026-001"
- "ops-warden ADR-0010"
- "audit-core AUDIT-IN-0001, and v0.4 review with three findings"
- "flex-auth FLEX-DEC-2026-002 (v0.4, §9.3 contested)"
- "kings-guard v0.4 review, four findings"
- "ops-warden 2026-08-29 v0.4 review, three findings"
related:
- canon/standards/security-zones_v0.1.md
- canon/standards/tenancy-posture_v0.1.md
- canon/standards/credential-management_v0.2.md
- gate-house/decisions/decisions.md
- gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
---
# NetKingdom Security Layer Model v0.5
## 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.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 |
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.
## 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.
### 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.
## 4. Layer catalog
| Repository | Layer | 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 | users, accounts, memberships |
| `tenant-engine` | Engine | tenant-as-an-entity facts |
| `zone-engine` | Engine | zone identity and membership — offline reference conformance per its 2026-08-23 disposition |
| `secrets-engine` | Engine | credential abstraction, custody, lifecycle |
| `audit-core` | Engine | audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6) |
| `access-engine` | Engine | **the policy decision** — the only decision point (§6) |
| `approval-engine` | Engine | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) |
| `maturity-engine` | Engine | 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 | building and tearing down access routes and perimeters |
| `ops-warden` | Staff | operational access lanes, stewardship, runbooks; SSH certificate issuance — **declared-gap** (§9.1, §13) |
| `kings-guard` | Staff | adaptive defence; observation of Staff-reachable sources — identity and secret observation **pending**; containment **pending** (§9.2) |
| `whitehat-security` | Staff | offensive validation |
`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.
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.
## 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.
## 7. Relationship to the Active Secrets Management Canon
```text
Staff interactive, non-deterministic ≈ Cognitive Plane
Engines deterministic APIs ≈ Authority Plane
Tooling deterministic state ≈ Execution Plane
Taxonomy cross-cutting language
```
*Cognition proposes. Authority disposes. Infrastructure executes.* is therefore
NetKingdom's layering rule, not only its security maxim. §5 and §6 are that
principle applied to repositories rather than to requests.
## 8. Vocabulary demarcations
| Term | Belongs to | Not |
| --- | --- | --- |
| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision whether they may |
| **access rule** | access-engine (Engine) — whether an actor may act | the route by which they arrive |
| **control plane** | Engine layer | a Staff repository's self-description |
| **doctrine** | gate-house | a lane owner's runbook |
| **runbook** | the Staff repository stewarding the lane | a substitute for doctrine |
| **posture** | kings-guard publishes; gate-house defines its authority meaning; access-engine renders it | a privilege source |
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 Containment is pending an engine surface
No engine exposes a containment surface today — nothing to reduce authority,
require step-up, or isolate a workload as a deterministic API. kings-guard's
containment claim is marked pending in §4 until one exists.
### 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.
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.
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.** A source SHOULD declare an expected emission cadence,
and a drop below it SHOULD become a finding in its own right — the stream
observed, not only its contents. This converts the blind spot into something
detectable without any Tooling contact and without any engine gap, because the
source publishes its own stream.
Raised by `audit-core` against its own principle; extended by `kings-guard` from
its own evaluator and confidence model.
## 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.
## 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.
Requires review: whether claims stay inside layer permissions; whether compiled
or cached data has become an early decision (§6.1); whether doctrine is reaching
decisions as declared inputs (§6.2); whether the §8 vocabulary is used correctly.
## 12. The conformance loop
Doctrine no engine implements is fiction. The loop is normative, not
aspirational:
```text
gate-house asserts an invariant
→ the engines implement it, or declare a gap
→ whitehat-security tries to break it
→ kings-guard observes it in operation
→ findings return to gate-house as doctrine change
```
A finding that a rule is unsatisfiable is a **success** of this loop, not a
failure of the reporting repository. Four of this standard's five versions exist
because a reviewing repository used it.
**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 |
| Containment surface | unowned-capability | kings-guard | access-engine + runtime engines | proposed |
| Identity and secret observation | unowned-capability | kings-guard | as above | proposed |
| 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) |
`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.
Gaps are recorded here but tracked in `maturity-engine` (§9.5) once it exists;
this table is the interim register and should not outlive it. The `state` column
MUST survive that migration.
## 14. Adoption
Status is **proposed** — the frontmatter is authoritative, and v0.2 was the last
version to reach `accepted`. Four repositories have assented, each with a record,
and all four returned findings on the versions since:
| 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.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.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 (§13), and if so which mechanism and who owns it.
- 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). `flex-auth` notes the decision precedes the action and the action
precedes consumption, so an allow rendered against an approval then never
consumed, or consumed twice by a racing caller, is a gap neither engine closes
alone. Needed before `FLEX-WP-0017` T05.
- 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.
- 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.