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

Raise INFD-IN-0006: is §3's layer vocabulary closed, and what is surface?

Browse source 
The custodian's estate-wide sweep (2026-09-21), extending flex-auth's boundaries
review FLEX-WP-0030, found this repository declaring `layer: surface` against a
§3 vocabulary that does not enumerate it. flex-auth's validator admits only
{Staff, Engine, Tooling}, so this fails on the value rather than on casing or on
B1's precedence question. It was never raised here directly and it is not the
nine-repository defect: both our files say `surface`, in the same casing.

`surface` denotes the presentation-and-binding tier — the runtime a human
touches, where a decision rendered elsewhere is shown to a named person, that
person binds their identity to the act, and the evidence that the presentation
happened is produced. It was chosen by elimination on 2026-09-09 (f6376dd),
because GH-DEC-2026-012 R1 ruled us out of Engine and left the layer ours to
declare, and each remaining value is false of us: not Staff (deterministic by
construction, and holding state audit-core depends on at runtime, which §3.4
forbids Staff), not Tooling (we persist nothing another layer reads), not
Taxonomy (we are nothing but a runtime position). Faced with a false value that
satisfies a validator or the true word and a finding, the true word was written.

Position: `surface` names a real tier §3 does not enumerate. The sharpest form
is that a standing ruling plus a closed vocabulary leaves this repository no
conforming declaration available — the §9.1 defect applied to conformance that
§11 names against itself. But the ruling is gate-house's and we do not claim it
must go our way: if the vocabulary is ruled closed and a value named, both files
change the same day without argument. We ask only that such a ruling show how
§3's determinism cut reaches that value given GH-DEC-2026-012 R1, because the
next repository in this position will reason from it — and the tier a human
touches having no owner is exactly what produced approval-engine's unowned
inbox, key-cape's blocked client_id, and this repository.

Two observations offered: flex-auth's validator admits three values where §3
enumerates four, so railiance-master's `Taxonomy` fails the validator rather
than the standard and is separable without any ruling, leaving `surface` as the
only surveyed value outside §3 itself; and §3's row label is `Engines` while
declarations use `Engine`, which should be written out as declaration values if
the set is ruled closed.

The declared value is UNCHANGED on purpose. Changing it ahead of the ruling
would pre-empt gate-house and throw away the evidence of what was concluded.
layer.yaml, INTENT.md and AGENTS.md now say so in place, so the value is not
read as unexamined and no later agent silently "fixes" it. AGENTS.md's layer
section was also stale — it still said layer.yaml was unwritten.

28 layer conformance tests pass.

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
This commit is contained in:
tegwick 2026-09-21 02:11:59 +02:00
parent 836cc2a56d
commit 13ee949982
5 changed files with 283 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

180
docs/gate-house-decision-request-layer-vocabulary.md Normal file
View file

@ -0,0 +1,180 @@
# 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.md` and quotes `GH-DEC-2026-012`. It is derived from
> those bodies at `net-kingdom` v0.8 as published 2026-09-09 and
> `gate-house` `decisions/decisions.md` as 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 between `INTENT.md` and `layer.yaml`; `informed-decision` is
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-decision` has 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" and `GH-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. Two observations offered to the ruling
**(a) The validator's vocabulary is not §3's.** `flex-auth`'s validator admits
`{Staff, Engine, Tooling}` — three values. §3 enumerates **four**: Taxonomy,
Tooling, Engines, Staff. So the custodian's "two repositories declare values
outside the §3 vocabulary" resolves into two different findings:
- `railiance-master`'s `Taxonomy` **is** in §3. It fails the validator, not the
standard. That is a defect in the validator's enumeration, correctable without
any ruling on whether §3 is closed.
- `surface` is outside §3 itself, and is the only surveyed value that is.
Separating them narrows the question gate-house has to answer, and means the
`Taxonomy` case should not be read as evidence that repositories invent layer
names. (`railiance-master` has its own agent and speaks for itself; this is a
reading of the published standard, not a statement on its behalf.)
**(b) `Engines` versus `Engine`.** §3's table row is plural. Declarations and
the validator use the singular. If §3's vocabulary is ruled closed, the closed
set should be written out as declaration values rather than inferred from table
row labels — otherwise the same class of ambiguity B1 found between two files
reappears between the table and the key. This is offered alongside the
case-sensitivity question (boundaries-review question 2), which has the same
shape.
## 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
1. `surface` denotes 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.
2. It was chosen by elimination against §3, with Engine excluded by
`GH-DEC-2026-012` R1, and written in this repository's own voice because that
ruling said the layer was this repository's to declare.
3. `informed-decision` holds that this is a real tier §3 does not enumerate.
4. It will change the declared value without argument if gate-house rules the
vocabulary closed and names the value.
5. 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.