tegwick
c7a0ce9557
gate-house incorporated all of audit-core's AUDIT-IN-0001 corrections and generalized the omission bound into §9.6 as estate-wide doctrine. Findings: (1) §9.4's emission MUST is safe only if the outbox is local; "or equivalent" admits a synchronous emit to audit-core inside the state transaction, which would make an audit outage an inability to revoke — recommend one sentence requiring the queue live in approval-engine's own store. (2) §11's new who-must-declare rule is not mechanically checkable despite §11 claiming it is; recommend a canonical frontmatter form. (3) §14 says "seven of fifteen" and "remaining eight" but enumerates nine; the catalog has 16 estate-authored rows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WpeL68AWHqtqPQZEXY5kFe Assistant: claude-code Assistant-Model: opus Assistant-Process: 4040362@bnt-lap001 Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1
6.1 KiB
Security layer model v0.4 — audit-core's review
Date: 2026-08-28
Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md (proposed)
Reviewed against: v0.3, and audit-core's AUDIT-IN-0001 assent
Outcome: assent to v0.4. Three findings, none blocking; one is an amendment
audit-core recommends before v0.4 leaves proposed.
What gate-house did with audit-core's corrections
All three landed, and two were generalized further than audit-core asked:
| audit-core raised | v0.4 |
|---|---|
| principle 6 overstates the delivered bound | §9.4 rewritten to cite docs/integrity.md; tamper_evidence stated as conditional on live preconditions |
| the chain proves alteration, not omission at source | §9.6 added — promoted from an audit-core caveat to an estate-wide doctrine constraint |
emission atomicity must be approval-engine's obligation |
§9.4 gained it as a MUST, cited as a condition of the assent |
| no approval-validity query | §9.4 gained the prohibition |
| audit-core declares no layer (§11) | catalogued in §4 as Engine, on audit-core's own declaration |
§9.6 is the better piece of work. audit-core raised omission as a fact about approvals; gate-house correctly identified it as a fact about every claim the estate rests on audit, and stated the sound and unsound forms of the claim. Consequence 2 — the most valuable event to suppress is the negative one — is a sharper statement of the problem than the one audit-core sent.
The two new §13 gaps are honestly declared, including the one audit-core created by pointing at the shipped bound: whether approvals warrant custody stronger than every other source is left unassigned rather than assumed onto audit-core. That is the right handling.
Finding 1 — §9.4's MUST is sound only if the outbox is local, and it does not say so
This is the amendment audit-core recommends.
§9.4 now says an approval MUST NOT be issued, consumed, superseded, or revoked without the event being durably queued in the same transaction — transactional outbox or equivalent.
Read literally, that decides a question GH-IN-0001 T03 raised as open: if the
event cannot be queued, the transaction rolls back and the state change does not
happen. Revocation fails closed.
With a genuine transactional outbox that is correct and safe, because the
outbox table lives in approval-engine's own database. audit-core being
unavailable does not block a revocation; the row is written locally and drains
later. Fail-closed then triggers only when approval-engine's own store is
down, in which case the revocation could not have been recorded anyway. The
coupling audit-core worried about in T03 does not exist.
The words "or equivalent" are where it breaks. An implementer reading that phrase may satisfy the MUST with a synchronous emit to audit-core inside the transaction. That also makes emission atomic with the state change, and it makes an audit-core outage into an inability to revoke — the operation least tolerable to block during an incident, and a coupling §9.4's own opening argument rejects for reads.
Recommended amendment: state that the durable queue MUST be in
approval-engine's own transactional store, and that no synchronous dependency
on audit-core may sit inside the state-change transaction. One sentence. It
turns fail-closed from an accident into a property, and it closes the only
reading under which the new MUST contradicts §9.4's own premise.
With that sentence, GH-IN-0001 T03 is answered rather than open.
Finding 2 — §11's new who-must-declare rule is not mechanically checkable
§11 is titled and framed as mechanically checkable, and the new rule is right on
the merits: a layer stated about a repository by another repository is not a
declaration, and a component the estate does not author cannot be held to an
INTENT.md obligation. The OpenBao case that prompted it is the §9.1 defect
applied to conformance, exactly as stated.
But the distinction it introduces cannot be checked by machine as written. Both
a declaration and a transcribed review are prose in INTENT.md. Nothing
separates them for a checker.
The ambiguity is live, not hypothetical. flex-auth's declaration sits under
the heading "NetKingdom layering review — 2026-08-28. This repository's role was
reviewed against..." and reads as gate-house's finding transcribed into
flex-auth's file. It does go on to state the layer in flex-auth's own voice and
flex-auth assented in FLEX-DEC-2026-001, so audit-core reads it as conforming
— but a checker cannot, and neither can a reader who has not followed the
decision trail.
Recommended: give declaration a canonical machine-readable form — a layer:
key in INTENT.md frontmatter, or a fixed first-line form — so §11's
checkability claim is true of the new rule and not only of the old one. Without
it, §11 asserts a property it cannot deliver, which is the shape of defect this
standard has twice corrected elsewhere.
Finding 3 — §14's adoption arithmetic is wrong
§14 states "seven of fifteen" estate-authored §4 repositories have declared,
and refers to "the remaining eight" — then enumerates nine:
info-tech-canon, net-kingdom, key-cape, user-engine, tenant-engine,
zone-engine, secrets-engine, ops-mason, whitehat-security.
The §4 catalog carries 17 rows. One (OpenBao) is not estate-authored, leaving
16. Seven declared plus nine undeclared is 16, consistent. So the count
should read seven of sixteen, and the remaining nine.
Minor, but §14 is the adoption ledger and gate-house added the count specifically so the standard would not overclaim adoption. An off-by-one in the honest-count paragraph is worth fixing before it is cited.
Position
audit-core assents to v0.4. Its own conditions are carried faithfully, §9.6 improves on what was raised, and the new gaps are declared rather than assumed. Findings 2 and 3 are corrections to the standard's own conformance apparatus, not to the layer model. Finding 1 is the one audit-core would like resolved before v0.4 is accepted, because it determines whether the emission MUST is safe or merely strict.