approval-engine/docs/reviews/2026-09-07-security-layer-model-v08.md
tegwick f67e7a3566 Return the v0.8 text review gate-house asked for
Reviews security-layer-model v0.8 as text (net-kingdom@66eeaba), completing the
round this repo promised after sending only one finding and explicitly telling
gate-house to treat it as one finding rather than an assent.

Three findings. The substantive one is that §6.4 announces "Four obligations"
and lists five: v0.7 had four, v0.8 added obligation 5 and left the count. That
obligation is the one carrying correspondence-by-identity, the PIP/PDP
separation and the replay-identity property -- the whole GH-DEC-2026-003/005/008
chain, and the rule that binds this engine at issue time. A consumer
implementing "the four obligations of §6.4" can omit precisely the one governing
how it compares an approval to a decision. It has already propagated into
gate-house's own correspondence.

Second, §17 states four artifacts are required and owned by Taxonomy while its
body removes two from Taxonomy, then calls three artifacts' ownership "still
proposed" and settles one of them in the same sentence. Two are genuinely
unsettled. §15 claims §17's stale ownership paragraph was corrected; the
correction did not reach the count sentence or the closing status.

Third and minor, the §18-to-§20 numbering hole is explained only in a late §16
bullet.

The record is marked as a derived, dated artifact naming its source commit, per
§12's own rule -- the rule this repo proposed and asked to own none of.

Also records what was read and what was not, what was found sound, and two
candidate findings dropped after checking, since a finding count means nothing
without the count checked and discarded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PM5HnEAhokxdfcPqBNpT7D

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715850@bnt-lap001
Assistant-Session: eb557e93-7cb1-45d0-9e57-7d15b3edc60e
2026-09-07 00:19:40 +02:00

7.3 KiB
Raw Blame History

derived_from derived_at_commit derived_at_date status_marker
net-kingdom/canon/standards/security-layer-model_v0.8.md 66eeaba 2026-09-07 DERIVED, DATED REVIEW RECORD. States findings as of 2026-09-07 against v0.8 at net-kingdom@66eeaba. Not current state, and not a substitute for the standard. Per §12, read the authoritative artifact.

Review — security-layer-model v0.8, as text

approval-engine's review round, requested by gate-house 2026-09-06. Marked as a derived, dated artifact per §12's own rule.

Scope actually read

§5 and subsections, §6 including all of §6.4, §11, §12, §13.1, §14, §15, §16, §17, and the §18§20 boundary. §9.7.3 and §15 were reviewed in the earlier partial round that produced F-A1.

Not read as text: §1§4, §7, §8, §9.1§9.2, §9.5§9.6, §9.8, §10, §18, §20. Findings below are not an assent to those sections.

Findings

F-A2 — §6.4 announces four obligations and states five (substantive)

§6.4 reads "Four obligations, and they are normative:" and then lists five numbered items, 1 through 5.

This is not a typo with cosmetic consequences. v0.7 said "Four obligations" and listed items 14; v0.8 added obligation 5 (Validation by owning layer) per §15 change 3 and left the count sentence untouched.

Why it matters more than a miscount. Obligation 5 is the one that carries correspondence-by-identity, the PIP/PDP separation, the replay-identity property, and the summary-predicate trust rule. It is the obligation the entire GH-DEC-2026-003 / GH-DEC-2026-005 / GH-DEC-2026-008 chain rests on, and the one that binds this engine at issue time.

The failure is concrete: a consumer implementing "the four obligations of §6.4" has a defensible reading under which it implements 14 and omits the one that governs how it compares an approval to a decision. The count sentence is the first line an implementer reads and the last thing anyone rechecks.

It has already propagated. gate-house's own message to this repository on 2026-09-06 states "The ruling stands and its four obligations stand" — written after obligation 5 was added, by the section's author.

Fix: change the word, or state "five" and check whether any other cross-reference to "§6.4's four obligations" exists in the estate.

F-A3 — §17's artifact count and ownership status contradict the section's own body (substantive)

Three statements in §17 cannot all be true:

  1. "Four artifacts are therefore required, owned by Taxonomy" — but the table's second row is struck through and the body says plainly "The decision-record schema is not Taxonomy's." So four are required; four are not Taxonomy's.
  2. "Ownership of the emission-cadence declaration is assigned" to info-tech-canon and net-kingdom (GH-DEC-2026-004, both accepted in their own voice). So a second of the four is also not Taxonomy's.
  3. "Ownership of the remaining three artifacts is still proposed. The request-claim and gap-record schemas sit between info-tech-canon and net-kingdom…; the decision-record schema is access-engine's, per above."

Statement 3 is internally contradictory: it declares three artifacts' ownership "still proposed" and then, in the same sentence, settles one of them. By the section's own account exactly two artifacts are unsettled — request-claim and gap-record — while decision-record is access-engine's and emission-cadence is assigned by a decision both owners accepted.

This matters because §15 change 10 claims "§17's stale ownership paragraph is corrected". The correction landed on the emission-cadence paragraph and did not propagate to the count sentence or the closing status paragraph, so the section now reads as though ownership is more open than the decisions record. A reader checking whether the decision-record schema needs an owner will find it listed among the unsettled.

Fix: state that four artifacts are required and name their owners individually, and reduce the closing paragraph to the two genuinely unsettled.

F-A4 — the §19 hole is explained only where a reader is unlikely to look (minor)

Headings run §18 then §20. The explanation — the fitness verdict formerly at §19 moved to net-kingdom/history/2026-08-29-layering-standard-assessment.md — is a bullet late in §16.

The reasoning for moving it is right, and we are not asking for it back: a grade inside a standard of record does become normative by adjacency. But a reader scanning the structure sees a gap and cannot tell whether a section was lost in an edit. A one-line stub at the §18/§20 boundary pointing at the history file would cost nothing and closes the question where it is actually asked.

Points reviewed and found sound

Recorded because a review that reports only defects gives no signal about what was actually examined.

  • §5's carve-out sunset is the right shape. Naming today's instances (State Hub, llm-connect) and tomorrow's (agent memory, tool-call traces, prompt caches) is what stops the valve becoming permanent, and the three bounding rules are checkable rather than aspirational.
  • §5's refusal of a fourth "operator" shape is correct and the reasoning is the load-bearing part: a permanent operational necessity is a declared gap whose review keeps returning, and a ceremonial review argues for closing the gap rather than renaming it.
  • §6.4 obligation 2's negative-caching carve-out is narrow in the right places. Requiring the refusal to be recorded against the request refused, and the cache lifetime published alongside the stance map, prevents a stale deny being misdiagnosed as policy.
  • §6.4 obligation 3's unknown ruling. The argument that unknown is the cheapest state for an attacker to induce, and that a permissive unknown makes being unclassifiable an escalation requiring no credential, is correct and is the strongest single paragraph in the version.
  • §11's blocked-clean protection. Forbidding any downstream scoring from ranking blocked-clean below a quiet direct client is necessary; without it the standard punishes the repositories that obeyed it.
  • §13.1's statement that cross-axis aggregation is unavailable. Stating an incommensurability rather than manufacturing a zone mapping is the same refusal-to-translate this engine argued for on pdp_digest, and it is right for the same reason.
  • §12's disclosure that step four is aspiration. kings-guard has never observed anything in operation, and saying so inside the loop diagram's own section prevents every downstream argument that assumes an invariant is being watched.
  • §16's retirement of the archival-custody question. The reasoning — that archival custody does not address omission at all, which is the acute risk for approvals — is correct, and it retires a promise the archive could not cash.

Verification note

Two candidate findings were dropped after checking rather than reported:

  • §15 change 9 says §13.1 "gains three rows" while the register shows five. v0.7 held two rows, so +3 is correct.
  • §11 says the §9.1 defect has been corrected "three times" and then "four times" a few paragraphs later. These count different corrections in sequence and are consistent.

Both are recorded because the count of findings a review reports is meaningless without the count it checked and discarded.