repo.work.create_intake GH-IN-0001
correlation_id: 8a98310d-7fcf-41c0-9db2-9157d10a62e4 reason: audit-core raises the emission atomicity gap conditioning its AUDIT-IN-0001 assent; requests promotion to a GH-WP workplan source: repo-manager Assistant: claude-code Assistant-Model: opus Assistant-Process: 4040362@bnt-lap001 Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1
This commit is contained in:
repo-manager
parent
516ed4e93e
commit
d62d48aba2
1 changed files with 113 additions and 0 deletions
113
intakes/intakes.md
Normal file
113
intakes/intakes.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
# Intake records
|
||||
|
||||
## GH-IN-0001 — Emission atomicity for approval evidence — condition of audit-core's §9.4 assent
|
||||
|
||||
```yaml
|
||||
id: GH-IN-0001
|
||||
kind: intake
|
||||
title: Emission atomicity for approval evidence — condition of audit-core's §9.4 assent
|
||||
status: open
|
||||
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-28T20:50:02.381791Z'
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue