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

Review security layer model v0.4 — assent, three findings
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
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
This commit is contained in:
tegwick 2026-08-28 23:06:27 +02:00
parent 3177d2cee0
commit c7a0ce9557
1 changed files with 120 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

120
history/2026-08-28-security-layer-model-v0.4-review.md Normal file
View file

@ -0,0 +1,120 @@
# 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.