gate-house/intakes/intakes.md

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

```yaml
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'
```