audit-core/docs/section-4-source-of-evidence.md

# Who is the §4 source of evidence

`AUDIT-IN-0005`. Statute: `net-kingdom` security layer model §4, §9.6, §11, §17,
companion profile `emission-cadence-security-profile_v0.1.md`.

This document is **not derived**. It states audit-core's own boundary in
audit-core's own voice, which is the only form §11 accepts for a declaration.

## The question

§11 requires every repository catalogued in §4 **as a source of evidence** to
declare an 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.

`access-engine` (the repository still answering to `flex-auth`) produces the
decision record, declares no emission guarantee, and raised the ambiguity itself
as B3 / G2: either it is a §4 source and is non-conformant today, or audit-core
is the source and `access-engine` is merely the producer of an artifact
audit-core is the source *of*. It declined to pick the second — the reading that
favours it — and asked audit-core which side of the line audit-core holds.

## The answer

**audit-core is not the source of evidence for the decision record. The emitter
is. For the decision record that emitter is `access-engine`.**

audit-core holds the custody half and the detection surface. It does not hold,
and will not accept, the emission guarantee for an event another repository
produces.

## Why, from audit-core's own record rather than from preference

**1. All three declared things are properties of emitting, not of holding.**
Class, cadence, and detection surface each describe the act of producing an
event. audit-core can declare none of them for an event it does not produce: it
cannot classify a stream it does not generate, cannot promise a rate or an
interval for it, and — stated to gate-house in `AUDIT-IN-0003` against
`GH-DEC-2026-014` limit 3, before this question existed — it **cannot detect
non-production**. audit-core performs no retrieval; its egress permits Postgres
and DNS only. A declaration audit-core made here would be a promise about
behaviour audit-core cannot observe, which is the same defect as an event
claiming an occurrence nobody watched.

**2. It is already audit-core's stated doctrine, twice, in writing.**
`AUDIT-IN-0001`: *"completeness at the boundary is the emitter's property, not
the archive's"*, and emission atomicity is *"a requirement on approval-engine,
not a task audit-core can discharge for it."* `AUDIT-WP-0009` lists *"emission
atomicity at the source, which is the emitter's obligation (§9.6)"* among its
non-goals. Taking the source role now would reverse a boundary audit-core has
held against gate-house and against approval-engine, for the one repository that
asked.

**3. The estate's operative shape already assigns it that way.** Every
obligation §11 names is carried on the **sender registration**, per source:
`evidence_kind` in `deploy/senders-scope.{json,yaml}`, and `heartbeat_classes`
per class rather than per source (`docs/stream-completeness.md`). Four sources
are registered today — `user-engine`, `tenant-engine` (attributive, with its
declared `completeness_trade`), `approval-engine` and `informed-decision` (both
load-bearing) — and each carries its own classification because §11 and the
cadence profile both say the classification is the **source's** published one and
MUST NOT be inferred by the observer. Reading `access-engine` out of that set
would make it the only producer in the estate whose emission obligation was held
by the archive.

**4. The archive-as-source reading makes §11 vacuous.** If custody conferred
source status, every emission obligation in the estate would land on the single
repository that can observe no emission, and no source could ever be
non-conforming under §11. A rule that assigns an obligation the holder cannot
discharge is the §9.1 defect §11 says it has now corrected four times; applying
it here would make the fifth.

**5. As a matter of fact, audit-core does not hold the record.** There is no
registered sender named `access-engine` or `flex-auth`, no token, no ingress and
no scope row. The decision record does not reach audit-core custody at all. A
repository cannot be the source of evidence it has never received, and could not
have been the source of it for the period in which the ambiguity stood.

## What audit-core does owe, and it is not nothing

The surface exists and is not a promise. §11 requires a **rare** load-bearing
class to carry a heartbeat **and** reconciliation and forbids rate monitoring
alone. audit-core built both, and built them in the shape a decision record
needs:

| Owed by the source | Owed by audit-core |
| --- | --- |
| The published class — load-bearing, and rare or volume | Accepting that classification as supplied and never inferring it |
| The cadence, per class | `heartbeat_classes` on the registration; `POST /v1/events` class `audit-core.heartbeat` |
| Reconciliation of its own counts | `GET /v1/reconciliation`, scoped to the caller's own sources, counts and never payloads |
| — | `GET /v1/stream-findings`, and the `means` field on every finding |

`access-engine`'s expectation — heartbeat plus reconciliation rather than rate,
because a decision record is bursty and a quiet period is normal traffic — is
correct and is the form already implemented. Registration goes through an intake
(`AUDIT-IN-0002`, `AUDIT-IN-0003` are the worked examples) and needs a token
lane, not a doctrine change.

**The bound, stated so no conformance argument rests on more.** Heartbeat and
reconciliation cover loss, outage, drain failure and accident. Neither covers a
compromised source suppressing an event and its own count together. §16 placed
the independent observer outside audit-core's scope. Nothing in this document
may be read as audit-core detecting adversarial omission by a source.

## What this ruling does not do

It binds audit-core. It does not rule §11.

§11 is `net-kingdom` canon authored by `gate-house`, and whether `access-engine`
is a §4 source is on gate-house's list along with five other §11 questions
(custodian survey, `the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md`,
2026-09-21). audit-core has removed the only alternative reading by declining it
on its own authority; the ruling itself is still gate-house's to make.

So `access-engine`'s **G2 does not close on this document alone.** flex-auth
holds it open until gate-house rules *and* audit-core confirms; this is the
second of those two and not the first. audit-core's position is that with the
alternative reading withdrawn by its holder, the remaining ruling has one
defensible outcome — but saying so is a prediction about gate-house, not a
substitute for it.

## audit-core's own emission

Asked which side of the line it holds, audit-core owes the same answer about
itself. audit-core is catalogued in §4 as the Evidence engine, not as a source,
and it emits no event into anyone else's custody. It does produce one artifact
others rely on: the **chain-head attestation**. Its class, cadence and detection
surface are now stated in `layer.yaml` under `emission_guarantee` rather than
only in `docs/integrity.md`, because a guarantee legible only by following a
document trail is the exact defect audit-core raised against flex-auth's
declaration in §11 — and leaving it in prose while charging another repository
with declaring theirs would be the flattering reading of an unruled boundary,
which is the thing both repositories keep objecting to.