gate-house ruled the section 3 vocabulary closed at four case-insensitive
tokens and named Staff (role pep-shaped unchanged). Both files were changed
the same day, as this repository had committed to. INTENT.md now governs.
layer.yaml is marked derived from INTENT.md and carries no standard or
companion version. The reasoning behind `surface` stays in layer.yaml as
history.
INFD-IN-0006 is closed. INFD-IN-0007 asks once more how section 3.4's Staff
definition fits a deterministic, non-agentic, evidence-holding repository.
It is a question only: nothing waits on it.
Section 4 answer: yes, as a Staff / pep-shaped / evidence-source row. The
emission guarantee is owed per event class: presentation (volume),
disposition (rare), stance-application (rare). See
docs/section-4-catalog-row.md.
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
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
Gate House ruled all three questions within a day, attributing the speed to the
request being filed before the architecture with candidate answers and their
costs.
R1 PEP-shaped, confirmed as proposed. The ruling settles the shape; the layer
stays ours to declare, so layer.yaml is written in this repository's voice
rather than transcribed from the reply.
R2 yes to a presentation claim, no second catalog row, under three limits now
declared in layer.yaml and tested. Limit 2 — the claim must never be an input to
the decision it presents for — is load-bearing: our self-dealing argument was
accepted because it holds, not despite it. Limit 3 drives architecture, since
here the actor being audited and the evidence source are the same component.
R3 (b) with the authority rule: binding digest authoritative for what the
request is, view_hash only for what was shown, neither substitutable, and a
disagreement between them is a finding against the presenting surface rather
than a fact about the request. Linkage is co-reference; nesting was refused
because it reproduces the GH-DEC-2026-008 hash cycle.
Built to v0.8 obligation 3 rather than migrating later: axis enumerated, unknown
resolves to fail_closed, absent distinguishable from unknown in the record, and
published-equals-shipped asserted by test rather than claimed. Every stance is
fail_closed, which is a conclusion not a shortcut — ops-warden can justify
fail_open on a continuity argument that does not exist here.
GH-DEC-2026-010 inherited as a declared gap in four documents: a decision cannot
today be proven to have come from access-engine. The decision path must not be
described as validated while FLEX-WP-0024 is open.
46 tests pass. T05 and T07 unblocked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
approval-engine replied to INFD-IN-0001 with docs/approver-surface-requirements.md
(31da1af, 5203f46) and two corrections. Several of my requirements were wrong or
incomplete; revised rather than appended to.
Corrected:
- PR-02 listed only approval:approve. Wrong — the surface also needs
approval:read to fetch what it renders. As drafted it would have shipped a
client able to submit an entry it could never display. That changes a
registration key-cape has already implemented, so it is their call (open
question A).
- NC-03 implied approval-engine refuses non-human approver entries. It does not;
only /consume is principal-restricted, and the operator service client holds
approval:approve. Enforcement of "humans bind, agents draft" is therefore ours
alone, and is auditable via schema v4's entries[].principal_type — never from
the shape of subject_id.
Added:
- PR-04 assurance shape. approval-engine persists it verbatim and accepts an
empty object, so it is the only place MFA survives into the approval record.
Needs auth method, acr/amr, auth_time, agreed with key-cape.
- PR-05 entitlement. A 200 from the engine is not permission to view; we owe
access-engine a check before rendering. Consuming a decision, not making one.
- PR-06 response mapping, including 409 duplicate_approver rendered as SUCCESS
(a browser double-submit is routine and the first entry stands) and 503 as
fail-closed.
- PR-07 and a matching INTENT wrongness condition: never render `approved` as
permission to act. That is a PDP in the browser wearing UI copy.
- L-05, L-06 and EvidenceModel 8b: view_hash cannot ride into the entry — the
POST discards its body by design — so Stage 1 correlates by (approval_id,
subject, approved_at). DoD-3 is satisfied by the triple, not by a stored hash.
PRD open question 1 is answered by construction: there is no inbox endpoint and
there will not be one, so the approvals-inbox shape is foreclosed upstream.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
Claim ownership of the browser-facing approver UI that approval-engine
deliberately does not contain. approval-engine's INTENT names an approvals
inbox under Non-Goals, and docs/keycape-service-registrations.md records that
the human approver client's client_id and callback URI "must come from its
owner once it exists" — leaving key-cape's KEY-WP-0013-T02 blocked on an
unassigned component.
- INTENT.md: Decision Memo concept, the binding/awareness split and the two
hashes, ownership and non-ownership against the named estate repositories,
and a provisional PEP-shaped layer placement flagged for a gate-house ruling
rather than asserted.
- GOAL.md: Stage 1 is the L3 approval approver surface — the narrowest real
consumer with a live blocking dependency — plus the written answer to who
owns the approver UI.
- workplans/INFD-WP-0001: founding documents, the gate-house layer/ownership
ruling, the four specs (PRD, UseCaseCatalog, ArchitectureBlueprint,
EvidenceModel), schema and canonicalizer promotion out of history/ with the
isolation vectors under test, the key-cape client registration, and a
walking skeleton that includes return and discuss.
history/ is preserved unmodified as provenance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
