audit-core/intakes/intakes.md

Intake records

AUDIT-IN-0001 — Proposed: audit-core takes the approval evidence half (security layer model v0.3 §9.4)

id: AUDIT-IN-0001
kind: intake
title: 'Proposed: audit-core takes the approval evidence half (security layer model
  v0.3 §9.4)'
status: closed
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.3 §9.4
priority: medium
owner: audit-core
requested_by: gate-house
description: 'gate-house proposes that audit-core own the tamper-evident record of
  approvals: issuance, use, supersession, and revocation emitted as audit events.
  Rationale: principle 6 (signed or hash-chained manifests to prove a record set was
  not changed, omitted, or truncated) is exactly what authenticated approval entries
  need forensically, and audit-core independence is the property Canon core rule 13
  wants — audit evidence protected from the actor being audited. What is NOT proposed:
  the operative approval state. approval-engine owns the durable object, atomic supersession,
  single consumption, and revocation, because those need mutable in-path current-state
  semantics and audit-core operational custody is append-only Postgres by design;
  coupling decision-time approval reads to the audit fabric would also make an audit
  outage an authorization outage. Note audit-core INTENT lists policy decision making
  as out of scope — this proposal respects that: approval evidence is a record of
  what happened, never the authoritative answer to whether an approval is still valid.
  Requested: assent, revision, or rejection. If audit-core would rather not carry
  approval events as a distinct source, say so and gate-house will record the evidence
  half as unowned rather than assume it.'
created: '2026-08-28T20:35:09.148892Z'
updated: '2026-08-28T21:10:00Z'
outcome: assent-with-conditions
closed: '2026-08-28T21:10:00Z'
resolution: 'Assent. The split is right: approval-engine owns the operative state,
  audit-core owns the tamper-evident record of issuance, use, supersession, and
  revocation as a distinct source. Two corrections to the rationale and one
  condition. (1) INTENT principle 6 overstates the delivered guarantee;
  docs/integrity.md is authoritative — an in-database chain does not withstand a
  database owner without the external chain-head attestation, and even then it is
  not WORM. Approval events get exactly the guarantee every other source gets,
  no more; anything stronger is an engine gap to declare under §5.3. (2) The chain
  proves alteration and truncation, not omission at source. A suppressed
  revocation leaves the chain intact and verify reports intact; completeness at
  the boundary is the emitter''s property, not the archive''s. CONDITION:
  approval-engine must guarantee emission atomicity (transactional outbox or
  equivalent) so an approval cannot change state without the event being durably
  queued in the same transaction — a requirement on approval-engine, not a task
  audit-core can discharge for it. Boundary stated: no approval-validity query
  will ever be exposed; a verdict surface would be deciding early under §6.1.
  Also raised: audit-core declared no layer, contrary to §11 — now declared Engine
  layer, explicitly not a decision point.'
recorded_in: history/2026-08-28-approval-evidence-assent.md