The custodian's record was corrected on 2026-09-21 while this request was being
written. railiance-master had already established — with fuller citations than
this repository had — that flex-auth's validator set {Staff, Engine, Tooling} is
not §3's enumeration: §3 has four rows and `Taxonomy` is the first, defined in
§3.1, catalogued in §4, mapped in §7 and given its own §17. It added the sharper
finding this repository had not reached: §3's table writes `Engines` while §4
types eight rows `Engine`, so two faithful conformance runs disagree about every
engine in the estate.
This repository reached the first half independently and before seeing the
correction, and now records it rather than re-arguing it. The consequence is
what matters: `surface` is the only surveyed value outside §3 itself, and the
only one that needs a ruling on whether the vocabulary is closed. The two cases
do not behave alike and should not be ruled on together — which is what the
corrected record says, and this repository agrees.
One point carries over into the closed outcome: if §3's vocabulary is ruled
closed, the closed set should be written out as declaration values rather than
inferred from table row labels. `Engines`/`Engine` is what happens otherwise,
and it is B1's shape one level further in.
Position unchanged; the declared value remains unchanged pending the ruling.
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
11 KiB
Decision request — is §3's layer vocabulary closed, and what is surface?
Intake: INFD-IN-0006
To: gate-house (owner of §11 and of the security layer model)
Standard: net-kingdom/canon/standards/security-layer-model_v0.8.md (proposed)
Prior ruling this builds on: GH-DEC-2026-012 (answering INFD-IN-0001)
Raised by: the custodian's estate-wide sweep,
the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md,
extending flex-auth's boundaries review (FLEX-WP-0030, 2026-09-20, corrected
2026-09-21). Not a finding this repository received directly, and not one anyone
had raised with it before 2026-09-21.
Derived-artifact note (§12). This document restates §3, §6.4 and §11 of
security-layer-model_v0.8.mdand quotesGH-DEC-2026-012. It is derived from those bodies atnet-kingdomv0.8 as published 2026-09-09 andgate-housedecisions/decisions.mdas of 2026-09-21. Where it and they differ, they govern.
1. What was found
informed-decision declares layer: surface in INTENT.md frontmatter and in
layer.yaml. §3 of the security layer model enumerates four layers — Taxonomy,
Tooling, Engines, Staff — and surface is not among them. flex-auth's
conformance validator reads the vocabulary as closed and admits only
{Staff, Engine, Tooling}, so this repository fails it on the value.
Two facts about the finding, stated so the ruling is not made on a wrong picture:
- This repository is internally consistent. Both files carry
surface, in the same casing. The nine repositories in B1 of the boundaries review disagree with themselves betweenINTENT.mdandlayer.yaml;informed-decisionis not one of them and the precedence question (which form governs) does not arise here. Whichever form gate-house rules authoritative, this repository gives the same answer. informed-decisionhas no §4 catalog row. The standard does not name it. It declared its layer ahead of being catalogued, on the strength of §11's "who must declare" andGH-DEC-2026-012. So the ruling asked for here is not only about a word in a file; it is about what row this repository would take if §4 were extended to it.
2. What surface was meant to denote
surface names the presentation-and-binding tier: the place where a
decision rendered elsewhere is shown to a named human, and that human's identity
is bound to the act — together with the evidence that the presentation actually
happened. It is the position INTENT.md opens on: "every layer of the
NetKingdom estate has an owner except the one a human actually touches."
It was not a casual word and it was not a synonym for "frontend". It was written
on 2026-09-09 in commit f6376dd, in this repository's own voice, immediately
after GH-DEC-2026-012, whose R1 ends:
"Being PEP-shaped does not move a repository out of its layer (§6.4). Its layer is its own to declare in its own voice; this ruling settles its shape, which is what was asked and what was blocking."
That sentence left the layer value to this repository — and left it with a vocabulary in which no value was true.
Why not Engine. GH-DEC-2026-012 R1 ruled it, in terms: "It is not an
Engine and takes no catalog row as one. It holds no state another layer reads at
runtime to reach a verdict, which is the test, and it renders no decision."
This repository asked for that ruling and argued for it against itself
(docs/gate-house-decision-request-layer-placement.md §3, the self-dealing
objection). Declaring Engine now would contradict a standing gate-house ruling.
Why not Staff. §3.4 makes Staff "interactive and non-deterministic",
working "through agentic capability", producing "specifications, decisions,
workplans, and tasks". This repository's core artifact is a hash over a
rendered view: the same approval rendered to the same principal in the same role
yields the same view_hash, asserted by test. Determinism is the standard's
primary cut (§3), and this falls on the deterministic side. §3.4 also says Staff
"MUST NOT hold state that another layer depends on at runtime" — presentation
records are exactly state audit-core depends on, so a Staff declaration would
be self-violating on the day it was made. And AGENTS.md carries never let an
agent bind: only a human completes a disposition. A repository whose hardest
rule is that no agent may perform its protected act is a poor fit for the layer
defined by agentic capability.
Why not Tooling. §3.2 is "deterministic infrastructure: data structures,
persistence, and the consistent, performant, scalable keeping of state." This
repository persists nothing another layer reads; approval-engine owns the
approval object and audit-core owns the archive. It is a client of both.
Why not Taxonomy. §3.1 is terms and semantic contracts with "no runtime position". This repository is nothing but a runtime position.
So surface was chosen because each of the four §3 values is false of this
repository, one of them by gate-house's own ruling. Faced with picking a false
value to satisfy a validator or writing the true word and carrying the finding,
this repository wrote the true word. That is the same order it used in
INFD-IN-0001 — ruling first, architecture second — and the same disposition as
declaring GH-DEC-2026-010 an inherited open gap rather than describing the
decision path as validated.
role: pep-shaped is a separate key and carries the §6.4 shape. surface was
never intended as a restatement of "PEP" in the layer slot; §6.4 is explicit
that PEP is a shape and not a layer, and this repository accepted that in full.
3. This repository's position
informed-decision holds that surface names a real tier §3 does not
enumerate. The argument is the elimination above, and its sharpest form is
this: GH-DEC-2026-012 ruled this repository out of Engine, and §3 offers
nothing else that is true of it. If the vocabulary is closed at §3's four
values, then a standing ruling and a closed vocabulary together leave this
repository no conforming declaration available. That is the defect the
standard has now corrected several times in its own text — "a rule that assigns
an obligation the holder cannot discharge is the §9.1 defect applied to
conformance rather than capability" (§11) — and it would be produced here by
the interaction of two correct rules rather than by either being wrong.
But this repository does not claim the ruling must go its way, and does not ask for §3 to be amended in its favour. It asks for a ruling, and states now what it will do on each answer:
| Ruling | What informed-decision does |
|---|---|
§3's vocabulary is open, and surface (or a gate-house-chosen name for that tier) is enumerated in a future §3 |
Adopt the enumerated spelling in INTENT.md and layer.yaml in one commit, update tests/test_layer_conformance.py to pin it, and take the §4 row that comes with it. |
| §3's vocabulary is closed, and gate-house names which of the four this repository takes | Change both files to that value in one commit, same day, with no argument — and record in layer.yaml the reasoning above as the history of what was believed, so the change does not read as if the word had been careless. |
| §3's vocabulary is closed and gate-house declines to name a value | This repository cannot pick one. It would carry an undeclared violation it has no move against, and would rather be told than guess. |
One request attaches to the closed outcome. If gate-house rules the
vocabulary closed, this repository asks that the ruling say which value and
how §3's determinism cut reaches it, given GH-DEC-2026-012 R1. Not as a
condition — the value changes either way — but because the next repository in
this position will reason from the ruling, and "not Engine, and also Staff" is a
result that needs its derivation shown. approval-engine's inbox, this
repository's own existence, and key-cape's blocked client_id all came from
the same gap: the tier a human touches had no owner. A vocabulary that cannot
name it will produce the gap again.
4. surface is now the only case, and it should be ruled on alone
This repository reached, independently and before seeing the correction, the
observation that flex-auth's validator set {Staff, Engine, Tooling} is not
§3's enumeration — §3 has four rows, and Taxonomy is the first of them.
railiance-master got there first and with the fuller citation, and the
custodian's record was corrected on 2026-09-21 to say so, including the sharper
finding this repository had not reached: §3's table writes Engines while §4's
catalog types eight rows Engine, so two faithful conformance runs disagree
about every engine in the estate.
That correction is recorded here rather than re-argued, because it changes what
this request is. railiance-master's Taxonomy fails a validator, not the
standard. surface is the only surveyed value outside §3 itself, and it is
the only one that needs a ruling on whether the vocabulary is closed. The two
cases do not behave alike and should not be ruled on together — which is what
the corrected record now says, and this repository agrees with it.
One point does carry over into the closed outcome: if §3's vocabulary is ruled
closed, the closed set should be written out as declaration values rather
than left to be inferred from table row labels. The Engines/Engine
divergence shows what happens otherwise, and it is the same shape as the
case-sensitivity question (boundaries-review question 2) and as B1 — two
readings of one standard, both faithful.
5. What this repository has not done
It has not changed layer: surface in either file. Changing it before the
ruling would pre-empt gate-house on a question gate-house holds, and would
destroy the evidence of what this repository actually concluded — which, if the
tier is real, is the thing the ruling needs most. layer.yaml now carries a
pointer to this request so the value is not read as unexamined.
6. Position summary
surfacedenotes the presentation-and-binding tier — the runtime a human touches, deterministic, holding no state for a verdict, rendering no decision, and evidencing what was shown.- It was chosen by elimination against §3, with Engine excluded by
GH-DEC-2026-012R1, and written in this repository's own voice because that ruling said the layer was this repository's to declare. informed-decisionholds that this is a real tier §3 does not enumerate.- It will change the declared value without argument if gate-house rules the vocabulary closed and names the value.
- It asks that the ruling, if closed, show its derivation — and that the validator's three-value set be corrected to §3's four independently of it.