audit-core/docs/approval-engine-source-registration.md

approval-engine source registration

AUDIT-WP-0009-T09 · intake AUDIT-IN-0001 · statute §9.4, §9.6

The registration inputs for approval-engine as a distinct audit source, onboarded under INTENT.md principle 4 — declared ownership, retention, access, export and evidence policy, not merely events arriving.

This file is the owner-side record. Everything in it is non-secret. No sender token appears here, in Git, in State Hub, or in a workplan.

Declaration

Field	Value
Sender name	approval-engine
Permitted source	approval-engine (exact; no wildcard)
evidence_kind	load-bearing (§9.4 — a control's soundness depends on the revocation event being present)
completeness_trade	none, and none is permitted — §9.6 requires emission atomicity of a load-bearing source
may_write	true
may_read	false — a source does not gain a read surface by emitting
secret_policy	redact (estate default; see below)
tenants	["tenant:platform"] — exact platform store tenant
Retention	no expiry set; recoverable history is the platform data.backup window, 30 days, measured
Custody class	operational — never archive, never WORM

Event classes

The four §9.4 classes, carried as distinct actions on one source:

Class	Why it matters
issuance	the approval came into being
use	single consumption, a state change owned by approval-engine
supersession	the prior approval stopped being current
revocation	the acute one — the most valuable event to suppress

Audit Core stores all four and derives nothing from them. It renders no verdict on whether an approval is still valid (§9.4), asserted by test in tests/test_approval_validity_prohibition.py.

Source return — 2026-09-08

approval-engine/docs/audit-source-registration.md now records the exact ["tenant:platform"] scope and explicit secret_policy: redact. The tenant choice follows the already accepted platform tenant decision and the Engine, production CLI and deployment defaults; no cross-tenant scope is needed. Both scope manifests now use that exact value. Tests prove that the overlay removes a stale wildcard tenant/source/read grant and refuses near-miss tenant spellings while retaining the accepted platform tenant.

redact retains a legitimate event with a secret-shaped field removed rather than turning it into a delivery failure. This does not permit credentials in producer payloads. The scope overlay deliberately does not override secret_policy: the protected sender registry entry must set it explicitly when platform provisioning occurs, and live admission must verify that value.

Applied in this repository

Input	Where
Non-secret scope	deploy/senders-scope.json + deploy/senders-scope.yaml (lockstep)
Receiver ingress	deploy/networkpolicies.yaml, audit-core-approval-engine-ingress
Evidence kind in the model	audit_core/senders.py, SenderIdentity.evidence_kind

The scope overlay only applies to a sender the Secret already carries, so this entry is inert until the token exists. That is what makes it safe to land ahead of the credential rather than in the same change.

The ingress rule is narrower than user-engine's: namespace and pod label in a single from peer, so both are ANDed. A new sender should not inherit an older rule's breadth. user-engine's sender and its policy are unchanged.

Original owner handoff (current delivery recorded below)

Input	Owner	Note
Token at approval-engine/approval-engine-audit, key audit-token	OpenBao (railiance-platform), routed via warden route	Audit Core never holds or transports it
Receiver registry custody and explicit secret_policy: redact	railiance-platform	Link protected registry and sender credential in the first-provision record; no token generated here
Applying the manifests to railiance01	operator	Audit Core does not apply cluster changes unprompted

What Audit Core will and will not claim about this stream

Stated here because §9.6 requires the bound to travel with the trail, and because a load-bearing source will otherwise be told less than it needs.

Will: every event it accepted is stored append-only, and the hash chain detects alteration or truncation of what it received.

Will not: that the archive proves an approval event occurred, or that the absence of one proves it did not. Completeness at the boundary is approval-engine's obligation and an archive cannot retrofit it.

Open gates, and which of them block what

Gate	Blocks admission?	What it actually bounds
T02 attestation scheduling	No	Evidence quality, not custody. See below.
T04 heartbeat / missing-heartbeat findings	No	Detection of adversarial omission for rare classes — the one that matters most for revocation
T06 reconciliation counts	No	The source's own ability to detect divergence
T05 declared cadence	No	Held deliberately on the §17 Taxonomy schema

T02 is an evidence-quality gate, not an admission or deployment blocker. Admission depends on identity, scope, ingress and a token. Attestation freshness governs what Audit Core may claim, not whether it accepts and durably stores. The append-only trigger and hash chain operate regardless; what a stale attestation removes is detection of a suffix rewrite by someone who owns the database. Since AUDIT-WP-0009-T01, /readyz reports tamper_evidence: false rather than overclaiming, and will keep doing so until T02 mounts a renewed attestation.

It also is not the gate that matters most here. §9.6 is explicit that the acute risk for approvals is omission, and tamper evidence does not address omission at all — T04 does. So a consumer waiting on T02 before trusting approval evidence would be waiting on the wrong control. Until T04 and T06 land, Audit Core cannot detect a suppressed revocation, and no reading of the chain, attested or not, changes that.

Native delivery return — 2026-09-11

The token is now independently held in OpenBao and delivered through its exact ESO projection. Namespace restrictions, sibling/full-registry/metadata/listing denials, wrong-SA/namespace refusals and the coding-agent boundary passed natively. Registry version 8 was compared exactly before Audit Core reloaded; receiver c82e0442 is Ready and operational/durable. The admitted manifests and sender ingress are applied. See the native receipt.

Remaining admission evidence is actual producer accepted/duplicate delivery, receiver source/tenant/read refusal, independent readback and audit bearer revocation. No native producer event or operational heartbeat is claimed by the custody receipt. Attestation/offsite operation remains a separate evidence quality bound in AUDIT-WP-0009-T12.