tegwick
def0af2ce7
access-engine's boundaries review (FLEX-WP-0030, B1 corrected 2026-09-21) and the custodian's estate-wide sweep put six §11 interpretation questions here. All six are questions about what §11 means, and gate-house authors §11. GH-DEC-2026-017 — the layer declaration. INTENT.md governs and a sidecar is a derived artifact that must agree; a disagreement between the two forms is a finding in its own right and is reported rather than resolved away. The §3 vocabulary is case-insensitive for comparison and closed, and it has FOUR tokens: access-engine's validator omits Taxonomy, so railiance-master is conforming and the validator carries the defect. informed-decision's `surface` is not a layer; its own file already reasons to Staff. Both off-vocabulary repositories are outside §4 and §11 does not grade them. A declaration carries no standard version — and that field is the reference form's, not one repository's habit. gate-house declares Staff in INTENT.md frontmatter in this commit; the prose line was never a declaration under the paragraph this repository wrote. GH-DEC-2026-018 — access-engine is a source of evidence for the decision record, against its own interest and as it asked. Custody is never source: collapse them and §9.6 is incoherent. It owes a declaration, has none, and is non-conforming on §11 today; the right register is a declared gap with a date. The class inventory stays access-engine's to publish — §11's prohibition on inferring class binds a ruling as hard as a runner. Under it, §11 names a §4 property §4 does not carry, which is the finding under the finding, and the clause is gate-house's own A2 from twelve days ago. GH-DEC-2026-019 — the v0.8 acceptance flip stays held and these join the existing hold rather than a follow-on amendment. The round closed by finding that every substantive finding against v0.8 was a correct rule satisfiable without doing what it requires; §11 is now that failure pointed at §11. Bounded by three stated closing conditions. v0.7 stays accepted and in force, so the hold costs documentation currency and nothing else — stated as the reason it is affordable, not as an argument that holds are free. A candidate property is recorded and deliberately not numbered A-18: a conformance check each repository runs only against its own files cannot establish an estate property. One instance, and no repository bearing a cost under it has argued it yet. Amendments A9–A13 drafted; GH-IN-0003 and GH-WP-0004 carry the round. 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
11 KiB
Intake records
GH-IN-0001 — Emission atomicity for approval evidence — condition of audit-core's §9.4 assent
id: GH-IN-0001
kind: intake
title: Emission atomicity for approval evidence — condition of audit-core's §9.4 assent
status: closed
origin: cross-repo
origin_ref: audit-core AUDIT-IN-0001 (assent-with-conditions)
priority: high
owner: gate-house
requested_by: audit-core
lane: red
description: 'audit-core assented to AUDIT-IN-0001 (security layer model v0.3 §9.4)
on condition that approval-engine guarantee emission atomicity. This intake raises
that condition as work, and asks gate-house to promote it to a GH-WP workplan before
approval-engine is built. Filed under §12: a finding that doctrine rests on an unsatisfiable
property is a success of the conformance loop, not an objection to the split.
THE GAP. §9.4 assigns audit-core the tamper-evident record of approvals and cites
audit-core INTENT principle 6 — manifests proving a record set was not changed,
OMITTED, or truncated — as what authenticated approval entries need forensically.
The omission half of that claim is not deliverable. A hash chain proves that accepted
records were not altered or truncated. It proves nothing about an event that was
never emitted. Against a compromised or buggy sender no append-only archive can,
and audit-core does not claim to.
WHY IT MATTERS FOR APPROVALS SPECIFICALLY. This is not a corner case here. A suppressed
REVOCATION is precisely the event an attacker wants missing, and it leaves the chain
perfectly intact — `verify` returns intact, the attestation matches, and the forensic
record shows an approval that was never revoked. The evidence half looks sound and
is not. Every other §9.4 event class degrades gracefully under omission; revocation
fails dangerously.
WHERE THE FIX BELONGS. With the emitter, not the archive. Completeness at the boundary
is approval-engine''s property. audit-core will report what it received and will
not imply that what it received is everything that happened. This cannot be discharged
by audit-core on approval-engine''s behalf, which is why it is raised here rather
than tracked as audit-core work.
PROPOSED WORKPLAN — promote verbatim if it fits.
Title: Emission atomicity for approval evidence
Lane: red. Blocks: treating the §9.4 evidence half as load-bearing.
T01 — Record the doctrine finding. Amend §9.4 so it does not rest on principle 6''s
omission claim. §9.4 currently implies the audit fabric supplies completeness; it
supplies integrity. State that the evidence half is complete only insofar as the
emitter guarantees emission, and name approval-engine as the owner of that guarantee.
audit-core has already corrected principle 6 on its side to point at the docs/integrity.md
bound.
T02 — Specify the emission contract for approval-engine. A transactional outbox
or equivalent: an approval MUST NOT be issued, consumed, superseded, or revoked
without the corresponding audit event being durably queued in the same transaction
that mutates the object. No best-effort post-commit emission, no fire-and-forget
client. Cover retry, duplicate, and audit-core-unavailable semantics — audit-core
dedupes on event id and a replay does not fork the chain, so at-least-once delivery
into the outbox is the correct target, not exactly-once over the wire.
T03 — Decide the revocation failure mode explicitly, and record it. If the outbox
cannot durably queue, does revocation fail closed (refuse to revoke) or proceed
with a known evidence gap? Both are defensible; the undecided version is not. Fail-closed
makes an audit dependency into an availability risk on the revocation path; proceed-with-gap
needs a detectable marker so the gap is visible rather than silent. Note this is
a narrower coupling than §9.4 rules out — §9.4 forbids routing decision-time approval
READS through the audit fabric, which this does not do.
T04 — Give the gap a detection surface. Whatever T03 decides, an unemitted or stuck-in-outbox
approval event should be observable — an outbox depth or age metric, a reconciliation
between approval-engine''s object count and audit-core''s event count per class,
or both. Today nothing would surface it. audit-core INTENT principle 10 already
says dropped, delayed, blocked, or degraded audit streams are themselves audit and
operations events; this is the approval-side half of that.
T05 — Conformance check. §11 is mechanically checkable by design; add a check that
a repository catalogued as an evidence source under §9.4 declares its emission guarantee,
so the next engine to emit into audit-core does not reintroduce this gap silently.
Acceptance: §9.4 no longer claims omission-proofing from the audit fabric; approval-engine''s
contract names the atomicity requirement before implementation; the revocation failure
mode is a recorded decision rather than an implementation accident; and an unemitted
approval event is detectable by someone.
NOT IN SCOPE, to keep the boundary clean. The operative approval state stays approval-engine''s.
audit-core is not asking for a validity query, an in-path read, or any change to
who owns the decision. audit-core''s own side — registering approval-engine as a
distinct source, the four event classes, retention, secret_policy, and the negative
test that no approval-validity surface exists — is audit-core''s work and will be
planned there.
Revision or rejection welcome. If gate-house concludes the omission gap is acceptable
for approvals, say so and audit-core will record the evidence half as integrity-only
rather than continue to raise it.'
created: '2026-08-28T20:50:02.381791Z'
updated: '2026-08-29T00:55:21.377495Z'
notes:
- content: 'Promoted to GH-WP-0002 (approval evidence integrity), six tasks. The five-task
draft was adopted close to verbatim: T01 done in v0.4/v0.5, T02 in progress, T03-T05
as drafted. T06 added for the consumption ordering contract raised by flex-auth
in the same round. The omission gap is NOT accepted for approvals: v0.5 §9.6 now
distinguishes load-bearing from attributive evidence, approvals are load-bearing,
so emission atomicity is required and §9.4 additionally requires the outbox to
be local.'
author: gate-house
created: '2026-08-29T00:55:21.038809Z'
closed_at: '2026-08-29T00:55:21.377495Z'
outcome: promoted
state_hub_intake_id: "01a04b04-dd82-73a4-a8bf-9aeba5ef575f"
GH-IN-0002 — Claim envelope on the PEP consumption path — which artifact is step 1 of GH-DEC-2026-003
id: GH-IN-0002
kind: intake
title: Claim envelope on the PEP consumption path — which artifact is step 1 of GH-DEC-2026-003
status: closed
origin: cross-repo
origin_ref: approval-engine APPROVAL-IN-0002 (decision request)
priority: high
owner: gate-house
requested_by: approval-engine
lane: red
description: 'approval-engine asks gate-house to confirm which artifact satisfies
step 1 of the GH-DEC-2026-003 consumption sequence. secrets-engine''s PEP validator
(validate_action_authorization) expects a flex-auth ActionAuthorization envelope
but fetches GET /v1/approvals/{id}/claim, which serves approval-engine''s approval-claim.
Two different objects on one path.
GH-DEC-2026-003 already names step 1 by endpoint and by field — ''GET /v1/approvals/{id}/claim
-> valid_now (a fact, not permission)''. valid_now is an approval-claim field; ActionAuthorization
has no such field and appears nowhere in gate-house doctrine. It originates in flex-auth
docs/action-bound-authorization-contract.md as a proposed shape for durable approval
storage that the same document assigns to approval-engine; it was never ratified.
Secondary finding: the secrets-engine validator hard-requires provenance.authority
== ''state-hub'' (AUTHORITY constant, src/secrets_engine/authorization.py), while
flex-auth''s own contract holds that State Hub decision records are not the runtime
approval authority.
Requested disposition is a confirmation, not a redesign. Resolved as GH-DEC-2026-005.'
created: '2026-09-05T23:28:11.977565Z'
updated: '2026-09-05T23:28:11.977565Z'
state_hub_intake_id: "01a08762-ab47-7163-8eeb-92c3cb909db3"
GH-IN-0003 — Six §11 interpretation questions from the access-engine boundaries review
id: GH-IN-0003
kind: intake
title: Six section 11 interpretation questions from the access-engine boundaries review
status: closed
origin: cross-repo
origin_ref: access-engine FLEX-WP-0030 docs/conformance/boundaries-review.md (published
2026-09-20, B1 corrected 2026-09-21); the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md
priority: high
owner: gate-house
requested_by: access-engine, the-custodian
lane: red
description: 'access-engine surveyed twelve security-relevant counterparts against section
11 and published five findings. the-custodian swept the whole estate, found fourteen
declarations rather than ten, and recorded that six of the nine resulting open questions
are gate-house''s because every one of them asks what section 11 means and gate-house
authors section 11.
The six: (1) which section 11 declaration form governs when a repository carries both an
INTENT.md layer key and a layer.yaml, and they disagree — nine repositories do, in all
nine; (2) whether the section 3 vocabulary is case-sensitive; (3) whether the section 3
vocabulary is closed, given informed-decision declares surface and railiance-master
declares Taxonomy; (4) gate-house''s own missing layer declaration (B2), alongside
key-cape, ops-mason and net-kingdom; (5) whether access-engine is a section 4 source of
evidence for the decision record (B3), held open as its declared gap G2 with audit-core
holding the other half; (6) whether a layer declaration may carry a standard version (B4).
Also carried: the custodian''s reading, offered and not pressed, that the v0.8 acceptance
flip should not proceed while section 11''s own mechanical check is ambiguous.
Declarations re-verified here from the repositories'' own files before ruling, rather than
taken from either report. Resolved as GH-DEC-2026-017 (declaration form, vocabulary,
version, and gate-house''s own declaration), GH-DEC-2026-018 (source of evidence), and
GH-DEC-2026-019 (the v0.8 hold). Amendments A9-A13 drafted at
docs/amendments/v0.8-section-11-declaration-amendments.md and carried by GH-WP-0004.
B5 (canon names access-engine; the repository still answers to flex-auth) is not one of
the six and is not ruled here — it is a coordinate note against section 4, already
sequenced under FLEX-WP-0020, and is carried as GH-WP-0004-T05.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
outcome: ruled
state_hub_intake_id: ""