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'
state_hub_intake_id: "01a08762-ab47-7163-8eeb-92c3cb909db3"
```

## GH-IN-0003 — Six §11 interpretation questions from the access-engine boundaries review

```yaml
id: GH-IN-0003
kind: intake
title: Six section 11 interpretation questions from the access-engine boundaries review
status: closed
origin: cross-repo
origin_ref: access-engine FLEX-WP-0030 docs/conformance/boundaries-review.md (published
  2026-09-20, B1 corrected 2026-09-21); the-custodian docs/assessments/2026-09-21-layer-declaration-boundaries.md
priority: high
owner: gate-house
requested_by: access-engine, the-custodian
lane: red
description: 'access-engine surveyed twelve security-relevant counterparts against section
  11 and published five findings. the-custodian swept the whole estate, found fourteen
  declarations rather than ten, and recorded that six of the nine resulting open questions
  are gate-house''s because every one of them asks what section 11 means and gate-house
  authors section 11.


  The six: (1) which section 11 declaration form governs when a repository carries both an
  INTENT.md layer key and a layer.yaml, and they disagree — nine repositories do, in all
  nine; (2) whether the section 3 vocabulary is case-sensitive; (3) whether the section 3
  vocabulary is closed, given informed-decision declares surface and railiance-master
  declares Taxonomy; (4) gate-house''s own missing layer declaration (B2), alongside
  key-cape, ops-mason and net-kingdom; (5) whether access-engine is a section 4 source of
  evidence for the decision record (B3), held open as its declared gap G2 with audit-core
  holding the other half; (6) whether a layer declaration may carry a standard version (B4).


  Also carried: the custodian''s reading, offered and not pressed, that the v0.8 acceptance
  flip should not proceed while section 11''s own mechanical check is ambiguous.


  Declarations re-verified here from the repositories'' own files before ruling, rather than
  taken from either report. Resolved as GH-DEC-2026-017 (declaration form, vocabulary,
  version, and gate-house''s own declaration), GH-DEC-2026-018 (source of evidence), and
  GH-DEC-2026-019 (the v0.8 hold). Amendments A9-A13 drafted at
  docs/amendments/v0.8-section-11-declaration-amendments.md and carried by GH-WP-0004.


  B5 (canon names access-engine; the repository still answers to flex-auth) is not one of
  the six and is not ruled here — it is a coordinate note against section 4, already
  sequenced under FLEX-WP-0020, and is carried as GH-WP-0004-T05.'
created: '2026-09-21T00:00:00.000000Z'
updated: '2026-09-21T00:00:00.000000Z'
outcome: ruled
state_hub_intake_id: ""
```