# Intake records

## AUDIT-IN-0002 — Register tenant-engine as an attributive audit-core sender

```yaml
id: AUDIT-IN-0002
kind: intake
title: 'Register tenant-engine as an attributive audit-core sender'
status: open
origin: cross-repo
origin_ref: TEN-WP-0011-T04
priority: high
owner: audit-core
requested_by: tenant-engine
description: >
  tenant-engine now emits mutation evidence through a local outbox
  (audit-core.event.v1alpha1, source=tenant-engine, POST /v1/events).
  The class is attributive and drain is non-blocking
  (tenant-engine/docs/evidence-emission.md). Production cannot land
  events until audit-core admits this sender: sender identity with
  source tenant-engine, a projected token (no secret in Git; warden
  route for custody), and NetworkPolicy if the current allow-list is
  still user-engine only.

  Envelope: schema_version audit-core.event.v1alpha1; tenant is the
  affected tenant_id; action is the domain event type; resource
  tenant:<id>. Duplicate event ids should 200. Credentials must not
  travel via State Hub messages.

  Requested: sender registration + token lane, or a correction if the
  envelope needs a field this engine is not sending.
created: '2026-08-29'
updated: '2026-08-29'
state_hub_intake_id: "01a04d8f-b1c1-746a-8007-15221ebf0a48"
```

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

```yaml
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
state_hub_intake_id: "01a04d8f-be67-75ed-a221-d50f99dbb78e"
```