approval-engine/docs/reviews/2026-09-07-security-layer-model-v08.md

---
derived_from: net-kingdom/canon/standards/security-layer-model_v0.8.md
derived_at_commit: "66eeaba"
derived_at_date: "2026-09-07"
status_marker: >-
  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 1–4; 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 1–4 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.