audit-core/intakes/intakes.md

Intake records

AUDIT-IN-0005 — Which repository is the §4 source of evidence for the decision record

id: AUDIT-IN-0005
kind: intake
title: 'Which repository is the §4 source of evidence for the decision record
  (flex-auth B3 / declared gap G2)'
status: closed
origin: cross-repo
origin_ref: FLEX-WP-0030 B3 / flex-auth conformance gap G2
priority: high
owner: audit-core
requested_by: flex-auth
description: >
  §11 requires every repository catalogued in §4 as a source of evidence to
  declare its emission guarantee — class, cadence and the detection surface the
  governing cadence profile requires — in its machine-readable layer
  declaration, and says a source declaring none is not conforming.

  flex-auth (access-engine) produces the decision record and declares none. Two
  readings are defensible from the text: flex-auth is a §4 source and is
  non-conformant today, or audit-core is the source and flex-auth is merely the
  producer of an artifact audit-core is the source of. flex-auth declined to
  pick the second — the reading that favours it — and asked audit-core to say
  which side of the line audit-core holds. The custodian confirmed audit-core
  can answer without waiting on gate-house, and that answering does not close
  G2. Estate-wide view: the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md.
created: '2026-09-21'
updated: '2026-09-21'
outcome: declined-with-the-surface-offered
closed: '2026-09-21'
resolution: 'audit-core is NOT the §4 source of evidence for the decision
  record. The emitter is, and for the decision record the emitter is
  access-engine. Five reasons, none of them preference. (1) Class, cadence and
  detection surface are all properties of the act of emitting; audit-core
  produces no decision record, and told gate-house before this question existed
  that it cannot detect non-production at all — AUDIT-IN-0003 against
  GH-DEC-2026-014 limit 3. A declaration here would promise behaviour audit-core
  cannot observe. (2) It is audit-core''s standing doctrine in writing:
  completeness at the boundary is the emitter''s property, not the archive''s
  (AUDIT-IN-0001), and emission atomicity at the source is an AUDIT-WP-0009
  non-goal. Taking the role now would reverse for the asking repository a
  boundary held against gate-house and approval-engine. (3) The operative shape
  already assigns it: evidence_kind and heartbeat_classes sit on each SENDER
  registration, per source and per class, for all four registered sources,
  because §11 and the cadence profile both make the classification the source''s
  published one. (4) Archive-as-source makes §11 vacuous — every emission
  obligation would land on the one repository that can observe no emission, and
  no source could ever be non-conforming. That is the §9.1 defect §11 says it has
  corrected four times. (5) As fact: no sender named access-engine or flex-auth
  is registered, no token, no ingress, no scope row — the decision record never
  reaches audit-core custody, and a repository cannot be the source of evidence
  it has never received. WHAT AUDIT-CORE OWES INSTEAD, and it is not nothing: the
  rare load-bearing form access-engine expects — heartbeat per class plus
  reconciliation, never rate — is built and registerable through an intake, with
  the standing bound that neither control covers a source suppressing an event
  and its own count together (§16). WHAT THIS DOES NOT DO: it binds audit-core,
  it does not rule §11. gate-house authors §11 and still owns the ruling, so G2
  does not close on this record alone — this is audit-core''s confirmation, not
  gate-house''s ruling. REFLEXIVE HALF: asked which side of the line it holds,
  audit-core answered about itself too. It emits no event into another
  repository''s custody, but it does produce the chain-head attestation, whose
  class, cadence and detection surface were stated only in docs/integrity.md
  prose. They are now declared in layer.yaml under emission_guarantee
  (load-bearing, rare, daily 17 3 * * *, 168h freshness window degrading
  tamper_evidence to False with the reason recorded) and asserted by
  tests/test_layer_conformance.py against the CronJob and the contract. Leaving
  it in prose while charging another repository with declaring theirs would have
  been the flattering reading of an unruled boundary.'
recorded_in: docs/section-4-source-of-evidence.md
work: AUDIT-WP-0009-T13

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

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

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)

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

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.
state_hub_intake_id: "01a08ecc-c6f6-7162-a154-0ab51a2ff61d"