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.