The checker now prints VALIDATED_AGAINST and its scope on every run,
including the OK line (kings-guard pattern). A12 detection widens from
the key name standard_version to every key and value of INTENT.md
frontmatter and layer.yaml: versioned standard:/companion: paths,
companion_version, and any *_version key except schema_version.
Comments and non-declaration files are not reached. Declaration
unchanged; gate-house confirmed it conforms.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
INTENT.md governs; layer.yaml is now marked derived (derived: true,
derived_from: INTENT.md). standard_version is removed from both forms
(A12). The checker changes in the same commit: it no longer requires or
prints standard_version, rejects it in either form, requires the derived
markers, and checks both layer values against the closed four-token
vocabulary after an ASCII case-fold (A9). Layer values are left as
spelled (INTENT.md Engine, layer.yaml engine); they agree once folded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
The workplan is finished; the retirement section no longer describes it
as the revision still underway.
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Updated by fix-consistency on 2026-08-29:
- update .custodian-brief.md for zone-engine
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Declare the layer in layer.yaml, check it against INTENT.md, and fail
make check on a new Tooling client or HTTP decision surface. Record the
six statute §10 artifacts for the 2026-08-23 cut, name access-engine on
the README, and offer a non-schema PIP field mapping to Taxonomy.
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Intake absorbed into ZONE-WP-0003; gate-house notified that this
repository has declared Engine/PIP under v0.7.
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Updated by fix-consistency on 2026-08-29:
- update .custodian-brief.md for zone-engine
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Sibling repos already ignore this directory. It blocked registrar
reconciliation of ZONE-WP-0003 because the worktree was dirty.
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Assent to ZONE-IN-0001 in this repository's own voice: layer Engine, role
PIP, offline reference remaining the catalogued surface. Align INTENT,
SCOPE, and GOAL with accepted statute v0.7 and companion v0.2. Record the
scope-against-intent review and open ZONE-WP-0003 for the mechanical
remainder. Do not reopen the no-runtime decision.
Assistant: grok
Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
Regenerated by fix-consistency; adds the inbound layer-declaration intake.
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
The layer model is now published as
net-kingdom/canon/standards/security-layer-model_v0.1.md (proposed) and
ratified by gate-house GH-DEC-2026-001. The note previously said the
standard was not yet written.
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
Records this repository's layer in the NetKingdom IT-security layer model
(Taxonomy / Tooling / Engines / Staff) and what should change in this INTENT
as a result. Links to the review that established the model:
gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
The note flags pending adaptation only; the body is unchanged.
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
Records absent from central carried random pre-ADR-007 identifiers minted by
the retired local hub, which C-06 refused as stale references. Deriving from
the canonical record id takes no identity from anything.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
T02 said no join key exists — too strong. The correction said the workload side
exists "and most of the join with it" — too optimistic, and it was an inference
from structure rather than a measurement. Computed, the join matches exactly one
lane: issue-core-ingestion-api-key.
rapp-qonto-keycape-client demonstrates the predicted naming failure: the path
offers keycape-client and rapp-qonto while the rapp declares name qonto, so
neither candidate matches.
The gap is therefore not a missing key but missing declarations. Thirteen lanes
name something plausible that no rapp declares as a workload; thirteen more are
not KV addresses at all.
This blocks stance modelling rather than unblocking it, and the tempting escape —
binding zones to something other than a workload for lanes that have none —
would quietly undo the subject decision. Recorded as a decision for repo-manager
and net-kingdom rather than resolved here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T02 concluded no registry carries a lane-to-workload join key. Too strong — it
was derived from ops-warden's catalog alone, which is the one place a workload
declaration would not live.
rapp-*/declarations/rapp.yaml declares workload_identity with
data_classification, criticality, readiness_state and bound_reefs for nine
workloads. ops-warden's dataclass_floor already maps synthetic/internal/
confidential/restricted to M0-M3. So workload -> classification -> minimum
maturity is a shared vocabulary spanning two repos already, and it is the
operator's maturity-derived default half-implemented by accident. criticality
is the other half and no control reads it yet.
Three real defects replace the blocking unknown: the lane-to-workload key is
only derivable by parsing path_template, whose convention is inconsistent
(rapp-qonto/keycape-client parses a bundle as a workload) and whose names
disagree with workload_identity.name; rapps declare "public" which
dataclass_floor does not map; and nine declared workloads do not cover ~17
catalog path identities.
Consequence for ownership: zone-engine does not need to build a workload
registry. It consumes rapp declarations plus dataclass_floor, and asks
ops-warden for one explicit field.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The lane-to-workload join moves from a noted gap to the critical path: with no
workloads in the corpus there is nothing to attach an admission standard to, and
the honest answer may be that the join belongs to whatever declares workloads
rather than to zone-engine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator direction. The T02 analysis concluded "a zone is a property of the
lane", which mistook the corpus for the subject — ops-warden's catalog is a
credential surface with no workloads in it, so lane properties were the only
thing available to partition. Partitioning what is available is not the same as
finding what policy applies to.
Three roles: the repo providing the software SUGGESTS a posture for running it;
the workload and its responsible party DECLARE the scrutiny applied, and are the
policy subject; the zone REQUIRES a standard for admission. A workload is not
labelled with a zone, it qualifies to run in one.
This is canon's existing mechanism, not a new one. Decision 8.2 already splits
authority this way and joins tier minima by machine, precisely so a checkable
constraint does not depend on someone remembering a signature; Decision 5.6
already ruled stance behaves as a tier minimum under it. It also dissolves the
grade-versus-acceptance question raised for T03 — they are the two sides of that
join.
Consequence: the four bands survive as membership inputs, demoted from
conclusions, and the missing lane-to-workload join is not a tidy-up. It is the
model. M0-M3 already grades workloads, which is the side of the join that exists.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
