From d62d48aba2ee885424f90d23462d89d357929109 Mon Sep 17 00:00:00 2001 From: repo-manager Date: Fri, 28 Aug 2026 22:50:02 +0200 Subject: [PATCH] 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 --- intakes/intakes.md | 113 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 intakes/intakes.md diff --git a/intakes/intakes.md b/intakes/intakes.md new file mode 100644 index 0000000..4aef306 --- /dev/null +++ b/intakes/intakes.md @@ -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' +```