tegwick
0a1d1d942a
informed-decision filed three rulings before writing any architecture, with candidate answers, their costs, the self-dealing objection argued against itself, and a list of what it was not asking for. That order is what section 17 exists to produce, and KEY-WP-0013-T02 is blocked today, so it is answered now rather than queued. R1 — PEP-shaped, confirmed as proposed, not an Engine. It holds no state another layer reads at runtime for a verdict, which is the test. Its layer stays its own to declare; this settles its shape, which is what was blocking. It should build to v0.8's obligation 3 rather than v0.7's and inherit GH-DEC-2026-010's attribution gap knowingly rather than describe its validation as complete. R2 — yes, and no second catalog row. PEP and PIP are shapes a repository has; the catalog records layers it occupies. Obligation 5 forbids a PIP republishing the PDP's decision, which is a prohibition on republishing a decision, not on holding two shapes. Three limits carry the permission: the claim carries presentation and nothing else, it must never be an input to the decision it presents for, and its evidence copy reaches audit-core independently of the emitter. The last is the one that matters here, because the actor and the source are the same component. R3 — candidate (b). The binding digest is authoritative for what the request is; view_hash only for what was shown; a disagreement between them is a finding against the presenting surface, never a fact about the request. (a) is refused doctrinally rather than on the cost given: merging the two makes one repository the authority on what another layer computes over a request, which is GH-DEC-2026-008's objection to translation. (c) is refused because nesting the binding digest inside view_hash reproduces the hash cycle that made GH-DEC-2026-008 unimplementable — we paid for that lesson once this quarter. The two link by co-reference instead: the presentation record names the binding identifier and never recomputes the other layer's digest. The residual is not closed and the ruling says so, as they asked. A compromised surface can present X and attest Y. Attestation covers accident and later tampering, never a compromised source — the same disposition approval-engine's equivalent takes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm Assistant: claude-code Assistant-Model: opus Assistant-Process: 1754332@bnt-lap001 Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0
8.2 KiB
8.2 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"