# Intake records

## AUDIT-IN-0003 — Register informed-decision as a load-bearing sender; commitment-only payload doctrine

```yaml
id: AUDIT-IN-0003
kind: intake
title: 'Register informed-decision as a load-bearing sender, and answer GH-DEC-2026-014
  limit 3'
status: closed
origin: cross-repo
origin_ref: INFD-WP-0001-T08 / GH-DEC-2026-012 / GH-DEC-2026-014
priority: high
owner: audit-core
requested_by: informed-decision
description: >
  informed-decision is the browser-facing approver surface approval-engine
  deliberately does not contain, ruled PEP-shaped by GH-DEC-2026-012. Limit 3
  of that ruling requires its evidence copy to reach audit-core independently
  of the emitter, because the actor being audited and the evidence source are
  the same component.

  Requested: (1) sender registration — source informed-decision exact, tenants
  [tenant:platform], write true, read false, evidence_kind load-bearing,
  secret_policy redact; (2) whether reconciliation per class as primary plus
  heartbeat for the low-volume classes is the right cadence form for a
  mixed-volume source; (3) whether commitment-only content is one event class
  or two, and whether it belongs in the same class as other evidence.

  GH-DEC-2026-014 attached a condition addressed to audit-core: non-production
  of committed content must be detectable as a FINDING rather than present as
  an absence, so the record must carry an assertion that committed content
  exists and where custody sits. Gate House asked audit-core to say plainly
  whether the record shape can express that, rather than have a rule written
  that the storage cannot meet.
created: '2026-09-09'
updated: '2026-09-10'
outcome: registered-with-a-stated-bound
closed: '2026-09-10'
resolution: 'Registration accepted on every proposed field; the proposal was
  correct and the substance is in the bounds. Prepared and inert pending token,
  protected-registry entry and operator apply —
  docs/informed-decision-source-registration.md, deploy/senders-scope.{json,yaml},
  audit-core-informed-decision-ingress. (1) GH-DEC-2026-014 limit 3: the fabric
  CAN carry the declaration — data is stored verbatim into details.data and
  hash-chained, so content_exists and custody need no schema change and become
  as tamper-evident as the commitment they accompany. It CANNOT detect
  non-production: audit-core performs no retrieval and its egress permits
  Postgres and DNS only. Detection happens at retrieval by the reviewer, and the
  stored declaration is what makes non-production attributable rather than a
  blank. Residual: a custodian that never held the content can emit a false
  content_exists; audit-core validates the declaration shape, never its truth —
  same class as omission at source, not closed by chain, attestation or T04/T06.
  (2) Cadence: reconciliation plus heartbeat is right, with both scoped PER
  CLASS rather than per source — a per-source heartbeat is satisfied by the
  high-volume presentation stream and says nothing about a quiet month of
  dispositions. Bound: a compromised emitter suppresses the event and its own
  count together, so neither control covers the limit-3 residual. Depends on
  T04/T06; declare now, do not describe as operating. (3) One source, distinct
  type values per class, following approval-engine four-class shape; a second
  sender would split one residual into two smaller-looking ones. (4) Tenant
  provenance is recorded in the registration document, not the envelope:
  audit-core does not resolve the tenant claim, it checks a value the credential
  is permitted to write, and restating an unobserved route in an event is the
  same error as claiming an event occurred. (5) Stated for all documents:
  commitment-only satisfies non-alteration and never reconstructability, and no
  audit-core document or conformance claim may describe it otherwise.'
recorded_in: docs/informed-decision-source-registration.md
work: AUDIT-WP-0009-T11
state_hub_intake_id: "01a08b76-05b9-7a53-8359-9cda50755f28"
```

## 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-09-10'
outcome: registered-with-a-blocking-correction
resolution: 'Registered attributive with the declared completeness_trade
  recorded receiver-side, tenants ["*"] justified per sender, source pinned
  exact, ingress added — all inert pending the token
  (docs/tenant-engine-source-registration.md, AUDIT-WP-0010 T01/T03/T04).
  Taking the correction the intake invited: the envelope does not match.
  envelope_for sends five required fields under other names (event_id, action,
  resource, observed_at, details) and omits correlation_id entirely, so
  normalize() raises invalid_event and every event would 400 and dead-letter.
  Because the drain treats 400 as terminal, the outbox row is marked handled
  while audit-core holds only a dead letter — lost on both sides, silently,
  presenting as a working integration. normalize() is not being relaxed to
  accept the alternate spellings: guessing which sender key means which stored
  field would make the mapping audit-core''s rather than the sender''s, and
  correlation_id cannot be synthesized at all. Root cause is audit-core''s —
  the wire envelope was documented nowhere a sender could read it, and
  schema_version audit-core.event.v1alpha1 selects nothing here. Contract now
  published at docs/event-envelope.md. Stays OPEN until tenant-engine corrects
  the emitter and T05 records live evidence.'
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"
```

## AUDIT-IN-0004 — Repair SQLite import into chained PostgreSQL custody

```yaml
id: AUDIT-IN-0004
kind: intake
title: Repair SQLite import into chained PostgreSQL custody
status: open
origin: residual
origin_ref: AUDIT-WP-0005
priority: medium
owner: audit-core
requested_by: codex
created: '2026-09-11'
updated: '2026-09-11'
description: >
  The 2026-09-11 receiver release rehearsal enables real PostgreSQL tests.
  Five tests in tests/test_migrate_store.py fail because _import_event omits
  chain_hash/chain_prev, now NOT NULL. This predates the receiver release and
  is not used by the native PostgreSQL receiver or its unchanged schema.
  Design the historic accepted_at versus chain ordering rule before fixing
  the importer: do not disable append-only protection or rewrite existing
  event timestamps to make tests pass. Cover empty and populated destinations,
  concurrency with live append, idempotent replay, conflict preservation, and
  an intact chain. Also evaluate repeated dead-letter/finding import counting.
  Run the full PostgreSQL suite with no migration exclusions for closure.
  No native import is authorized or attempted by this release.
```