**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 capability over a Tooling store — `secrets-engine`. The store may serve other engines. | that engine's failure semantics |
| `kings-guard` | Staff | — | adaptive defence and judgment; observation of Staff-reachable sources — identity and secret observation **pending**; **proposes** containment, which it does not own (§9.2) | unassessed |
| **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
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
4.**Three failure modes are named, and each needs an owner**: an allow rendered
then never consumed; a double consumption by racing callers; consumption
after the authorized action has already failed. Neither engine closes these
alone. Recorded in §16 and `GH-WP-0002-T06`.
### 9.8 Partition is not one-dimensional
§9.3 handles *engine unreachable*. A real estate spends most of its incident
time in the band between reachable and gone: partial PIP reachability, clock
skew across a decision and its enforcement, and two consumers with different
declared stances seeing different worlds at the same moment.
Two rules hold today, and the rest is open (§16). A PEP MUST resolve its own
stance from its declared map without consulting another consumer — divergent
views are expected and are not a coordination problem to be solved at enforcement
time. And where clock skew could extend a lifetime under §9.7, the shorter
reading governs.
## 10. Changing layer
A repository's layer is not permanent. `zone-engine` changed layer in practice
when its runtime hypothesis was falsified.
A layer change MUST be recorded as a decision, MUST update the repository's
`INTENT.md`, and MUST obtain assent from the repositories whose boundaries move.
A repository MUST NOT acquire a new layer's permissions by gradual practice.
"No gradual practice" needs a check rather than a sentence. A layer change MUST
carry six artifacts, written from the `zone-engine` case that the procedure
should have been derived from in the first place:
| Artifact | Why |
| --- | --- |
| before/after `INTENT.md` | the declaration is the conformance surface (§11) |
| client inventory | what the repository holds against Tooling, before and after |
| gap inventory | which §5.3 gaps close, open, or transfer |
| assent list | every repository whose boundary moves |
| state-migration decision | what happens to live state and to consumers reading it |
| permission freeze | no new permissions of the target layer are exercised until the cut completes |
The freeze is the one that makes the rule checkable: a repository mid-change
holds its old permissions, not the union of both.
## 11. Conformance
Conformance has four states, and the distinction between the last two is the
point:
| State | Meaning |
| --- | --- |
| **Conforming** | no Tooling contact, or only §5.1/§5.2 shapes, declared |
| **Blocked-clean** | the capability does not exist because no engine exposes it, and the repository makes **no** Tooling contact — §9.1 `pending`, and not a non-conformance |
| **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance |
| **Undeclared violation** | anything else — a finding |
**Blocked-clean is not a lesser state than conforming.** A repository that
declined a break-glass path and left a capability at zero has complied at cost;
a repository that quietly opened a direct client and declared nothing has not.
Any downstream scoring — `maturity-engine` included (§9.5) — MUST NOT rank the
first below the second. Raised by `kings-guard`, whose three gaps are all of
this kind and which would otherwise have been graded down three times for
having taken the standard seriously.
**Who must declare.** A repository the estate authors declares its layer in its
own `INTENT.md`. For a component the estate catalogues but does not author —
third-party or vendored, such as `OpenBao` — the §4 catalog row **is** the
declaration, and no `INTENT.md` obligation attaches. A rule that assigns an
obligation the holder cannot discharge is the §9.1 defect applied to conformance
rather than capability.
A layer stated *about* a repository by another repository is not a declaration.
Review notes, catalog rows, and correspondence record an intent to adopt; only
the repository's own file conforms.
**Declaration form.** Because prose cannot distinguish a declaration from a transcribed review, a declaration
MUST carry a machine-readable form: **a `layer:` key in the repository's own `INTENT.md`
frontmatter.** An equivalent declaration file MAY accompany it and is a **derived
artifact** under this section's derived-artifact rule: it MUST be marked as derived, MUST
name `INTENT.md` as what it derives from, and MUST agree with it. `INTENT.md` governs.
This is not a preference between two files. This section already says a repository
declares its layer in its own `INTENT.md`; the alternative form was added to give the
declaration a machine-readable *form*, and was read as giving it a second *authority*.
**A disagreement between the two forms is a finding in its own right** and MUST be
reported rather than resolved away by precedence. Precedence says which value is the
repository's answer; it does not say the disagreement did not happen. Where one
appearance is reachable by two routes, the record says which route.
**A conformance run MUST state its scope.** This section's obligations attach to
estate-authored repositories **in §4**. A repository outside §4 may declare voluntarily
using this form, and a voluntary declaration is welcome; it is not a §4 obligation and a
run that grades it is over-scoped. A run over §4 and a run over every repository carrying
a declaration answer different questions, and a report that does not say which it did
cannot be acted on. **A run over a single repository is a permitted third scope:** it
names the repository and states whether that repository is in §4, and a run over a
repository outside §4 reports a voluntary result, not §4 conformance.
**A layer declaration MUST NOT carry a standard version.** The declared layer is a
standing property of the repository and does not change when this standard is revised; a
version in the declaration makes every revision read as though it invalidated every
declaration. That is the confusion this standard's own `assented_by` note exists to
prevent: assent records assent to a **boundary**, given at the version named, and is not
assent to the current text.
**The rule reaches content, not a key name.** The declaration, for this purpose, is every
key of the `INTENT.md` frontmatter and every key of a derived declaration file. No key or
value of either carries a version of this standard **or of its companion** — including a
version carried in a path or file name, such as a `standard:` key naming
`…security-layer-model_v0.7.md`. Comments, and the version of a declaration file's own
schema, are not versions of this standard and are not reached. *(r3)* **A version is
reached when it is carried as a pin:** in a key naming a version of this standard or its
companion, in a path or file name, or in the value of a key that identifies this standard
or its companion. A citation of an earlier revision in a record's prose, stating where a
rule came from, is provenance and is not reached.
**The rule reaches the declaration only.** A stance map, claims map, or evidence
classification states a position on clause text, which is version-scoped as a layer is
not, and it SHOULD carry the version of the text it answers; this rule does not apply to
it and a conformance run MUST NOT apply it there.
**Version-scoped state belongs to the conformance run.** Every run MUST state, in its
output, the version or commit of this standard it checked against and its scope. A checker
re-run on demand satisfies this by stating both on every run; no declaring repository is
required to emit a durable conformance record. Where a run's output is **retained or
relied upon**, the retained output is a derived artifact under this section's
derived-artifact rule, and the party retaining it carries the version or commit it was
derived at.
If a future revision changes §3's vocabulary such that a declared token no longer denotes
the same layer, declarations do **not** silently retarget: that revision carries a
re-declaration round, run in this standard's authoring voice. A per-file version pin would
not have caused anyone to re-read anything.
Mechanically checkable:
- every estate-authored repository in §4 carries a machine-readable layer
declaration;
- every direct Tooling client in a Staff repository maps to a declared §5.1,
§5.2, or §5.3 entry, and non-Tooling clients are recorded so the check is
total;
- no repository other than `access-engine` exposes an authorization decision
surface;
- no §4 capability is catalogued without an engine surface, a `pending` mark, or
a `declared-gap` mark;
- every repository **marked in §4 as an evidence source** declares its
**emission guarantee** in its machine-readable layer declaration, **per event
class** — a single repository-level guarantee over a stream containing both
a high-volume and a rare class is an average, not a declaration, and will be
satisfied by rate monitoring that cannot see the rare event go missing; for a
**load-bearing** source, a local transactional outbox (§9.4), its declared
cadence, and the detection surface the governing cadence profile requires for
that class — under `net-kingdom`'s
`emission-cadence-security-profile_v0.1.md`, a **volume** load-bearing class
MAY be covered by rate monitoring where the source has classified it as
suitable, with a positive window and a positive minimum; a **rare**
load-bearing class MUST NOT be, and MUST carry a heartbeat **and**
reconciliation, not either alone, and, where that guarantee is not itself
completeness, an explicit statement that completeness is not claimed; for an
**attributive** source, the trade it
makes and an explicit statement that completeness is not claimed. Which class
an event falls in, and whether it is rare, is the source's published
classification: a conformance run is supplied that inventory and MUST NOT
infer it from an event name, payload, or observed rate, or the check becomes
circular;
- every published example, fixture, or sample document validates against the
schema it exemplifies, and where a field is optional but load-bearing, the
examples cover both its presence and its absence rather than leaving one shape
to be inferred from the other;
- every derived artifact — a summary, example, change log, or review record that
restates a normative body — is marked as derived, names the artifact it
derives from, and carries the version or commit it was derived at.
A source that declares no emission guarantee is not conforming, and neither is
one that declares load-bearing emission with rate monitoring alone where its
event class is rare (§9.6). The declaration is what makes §9.6 checkable rather
than reviewable; without it the section states an obligation whose satisfaction
cannot be observed, which is the §9.1 defect this standard has repeatedly
corrected; the instances are listed in §15. Drafted in `gate-house/docs/contracts/approval-emission-detection.md`,
which `approval-engine`'s `cadence.yaml` implements as the reference instance.
The check states no MUST/SHOULD split of its own: which evidence classes must
declare cadence, and in which form, is the governing profile's to say (§17), and
this item follows it rather than restating it.
Raised by `audit-core` as the general form of `GH-IN-0001`, so the finding that
produced `GH-WP-0002` cannot recur unnoticed.
**The completeness non-claim binds both arms.** Where the declared guarantee is
not itself completeness, the declaration carries an explicit statement that
completeness is not claimed. A load-bearing guarantee states the controls, not
their sufficiency. The outbox is atomicity at the source against crash and partial
failure. Heartbeat and reconciliation detect loss after the fact. Neither is a
proof that a record was never sent, and neither covers a compromised source
suppressing an event and its own count together. Completeness, where this standard
actually requires it, is emission atomic with the state change; the declaration
may say that, and it MUST NOT describe the detection surface or the archive as
that completeness. Ruled in `GH-DEC-2026-024` §1, from the bound on rule 13 and
from §9.6.
No detectable or direction-limited failure-path release exception is added to
§9.6 or this check (`GH-DEC-2026-024` §3).
The example-validation check is the mechanical half of §12's derived-artifact
rule; `approval-engine` reports it at fifteen lines. Its second clause is the
non-obvious one: an example set that silently omits an optional field teaches
| Decision-record authenticity — a PEP cannot attribute a decision to `access-engine` (§6.4 obligation 1); unsigned envelope, plain-HTTP pins | declared-contact | flex-auth | flex-auth | self-declared (`FLEX-DEC-2026-010`, `FLEX-WP-0024`) |
| Human principal's tenant is unresolvable from the directory, so a client registration supplies it (`GH-DEC-2026-013`) | declared-contact | key-cape | directory adapter — unnamed | proposed |
| `ops-warden` | `ops-warden/pep-stance.yaml` | security zone | signing targets 0/3 resolved; routing lanes 3/21 resolved (2026-09-09, self-measured) | total per zone; open `z0`–`z2`, closed `z3-critical`; test asserts the published map equals the shipped default (`ADR-0009`). **`unknown` → `fail_open` is non-conformant under §6.4 obligation 3 as of this version**; route `WARDEN-WP-0040` |
| `user-engine` | `user-engine/pep-stance.yaml` | security zone | not reported | total per zone; `fail_closed` for `z0`–`z3`, unknown, and not-applicable; test asserts the published map equals `user_engine.pep_stance` |
| `tenant-engine` | `tenant-engine/pep-stance.yaml` | security zone | not reported | total; `fail_closed` for unset, unreachable, non-allow, unknown; test asserts the file equals shipped behaviour |
| `secrets-engine` | `secrets-engine/pep-stance.yaml` | catalog stage — interim, pending zone membership as a claim | not reported | total over stage plus unknown; no implicit default; runtime-read; pinned to `SHIPPED_STANCE` by test |
| `ops-mason` | — | — | — | **not published — non-conformant under §6.4 obligation 3**; catalogued PEP-shaped in §4; no route recorded |
**Two rows are marked, and the marking is the point.** `ops-warden`'s cell is
wrongly valued in a published map; `ops-mason` has published no map at all, which
is the plainer violation of the same obligation and read as a bare statement of
fact through v0.8's circulation. A reader scanning for the bold marks would have
found one row and concluded the other four were fine. That is §11's marking
obligation applied to this standard's own register, and it was returned to
`gate-house` unchanged by `access-engine`, which had received the same argument
about a stale row of its own.
**Coverage is reported by the consumer and is not inferred here.** A blank is
"not reported", never "complete": the register does not compute another
repository's classification coverage, and a stance with no coverage figure beside
it says less than it appears to. §6.4 obligation 3 states why the figure belongs
next to the stance, and why it does not soften it.
**Cross-axis aggregation is unavailable.** Three maps scope by security zone and
one by catalog stage, which §6.4 permits as an equivalent scope. The register
therefore cannot answer *"what is the estate's stance for a `z2`-protected
workload"* for every consumer, and it states that rather than implying it can.
The convergence path is zone membership reaching the decision as a claim, after
which a stage-scoped map converges onto zones without either side inventing a
mapping.
**The register earned itself at two rows.** `access-engine` said in the v0.6
round that it was the repository positioned to notice when the aggregate of
consumer stances diverges from the policy packages, and recorded that the claim
was sound while one row could not diverge from anything. The second row produced
two findings on first inspection: two conformant maps taking opposite stances on
`unknown`, and two incommensurable axes. Both are settled in `GH-DEC-2026-009`.
This register moves to `maturity-engine` when — and not before — that engine
publishes a committed, versioned export of §13 and §13.1 readable without a live
query, generated rather than hand-edited, and regenerable so drift between the
export and its computed state is detectable. A standard of record must stay
legible in git, at a version, to a reader with no cluster access, including one
auditing the estate precisely because they do not trust its running systems; a
pointer to a live engine is an instruction to run software, not a register.
`maturity-engine` holds both registers as queryable data already (`MAT-WP-0001`),
so what remains is publication — the migration's precondition, not its
Prior-revision assent was not carried over. Those receipts are technical
returns to the exact amendments, not founder acceptance or a review of
every final-cut adaptation. Gate-house retains authoring
disposition and net-kingdom publication; the named founder acceptance act
was separately supplied by the confirmed human memo acceptance above. T11 checker
convergence is now due after this flip, rather than being inferred complete.
Two things that acceptance does and does not mean, kept apart because
`ops-warden` asked for the distinction:
| | |
| --- | --- |
| **Boundary assent** | given by the four repositories below, at the version named in each record, and undisturbed since |
| **Revision review** | v0.7's changes were each the adopted remedy of a v0.6 finding. All fifteen v0.6 findings were subsequently audited against the v0.7 body — not against its change log — and confirmed dispositioned (`gate-house/docs/conformance/2026-09-06-v06-findings-audit.md`) |
| **Reviewed as text** | v0.8's circulated round returned findings from `access-engine`, `approval-engine`, `ops-warden`, and `net-kingdom`, and every finding is dispositioned in `gate-house/docs/conformance/2026-09-06-v08-assent-round.md`. Nine corrections landed in this text during circulation (§15 items 12–20) and one request was declined with its reasons in §6.4 |
| **Not claimed** | No clean-bill review of every section is claimed. `kings-guard`'s §9.5 criteria-grounding and §12 step-four review is not claimed here. `audit-core` returned its §11 review on 2026-09-23; its findings are dispositioned by GH-DEC-2026-024 and incorporated in this proposed cut. `approval-engine` named the sections it did not read in the earlier circulation; A11 r2/A12 r3 returns concern those exact amendments, not all sections. |
**Ten of this version's twelve changes as cut were requested by another
repository**, seven of them by a repository arguing against its own interest or
reporting its own error. There are two exceptions, not one: §17's ownership
correction, which `gate-house` found by auditing its own accepted text, and item
2b, which `access-engine` flagged as a near miss it was explicitly *not* asking to
have written down. The count was stated as ten of eleven until `approval-engine`
observed that item 2b's numbering left a reader unable to tell whether it was a
change or a sub-clause — and that the ambiguity moved both halves of a ratio §14
calls the argument rather than the background. The nine corrections applied during
circulation (items 12–20) were all requested by another repository. That ratio is the reason the standard is
circulated rather than accepted on the owner's decision as v0.7 was: this version
imposes costs on named repositories — `ops-warden` acquires a non-conformant
stance cell, `approval-engine` acquires an issue-time obligation — and a cost
imposed without a review round is the kind of rule §12 exists to catch late.
Findings against this text are §12's normal business. Two are anticipated and
would be welcome: whether §6.4's `unknown` ruling is too broad for a genuinely
low-consequence unclassified scope, and whether a maturity criterion exists that
cannot be expressed without dereferencing a judgment. Both are written into the
reversal clauses of their decision records as the falsifiers that would revert
them.
| Repository | Record | Outcome |
| --- | --- | --- |
| flex-auth | `FLEX-DEC-2026-001` | assent to all three items; one self-declared non-conformance; two rename conditions |
