gate-house/intakes/intakes.md

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: 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'