Assent to AUDIT-IN-0001 — approval evidence half, with conditions

gate-house proposed (security layer model v0.3 §9.4) that audit-core own
the tamper-evident record of approvals while approval-engine owns the
operative state. Assented, with two corrections and one condition.

Correction 1: INTENT principle 6 overstated 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. Principle 6 now points at that bound.

Correction 2: the chain proves alteration and truncation, not omission
at source. A suppressed revocation leaves the chain intact.

Condition: approval-engine must guarantee emission atomicity, so an
approval cannot change state without the event being durably queued in
the same transaction. Not a task audit-core can discharge for it.

Boundary: no approval-validity query will be exposed — that would be
deciding early under §6.1.

Also declares audit-core's layer (Engine, not a decision point), which
§11 requires and INTENT.md was missing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WpeL68AWHqtqPQZEXY5kFe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4040362@bnt-lap001
Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1

INTENT.md

@@ -17,6 +17,18 @@ Audit Core must integrate cleanly with NetKingdom, Railiance, OpenBao,
 Kubernetes, identity providers, and application runtimes, but it must not depend
 on NetKingdom to exist or operate.
 
+## Layer
+
+Audit Core is **Engine layer** under the NetKingdom security layer model
+(`net-kingdom/canon/standards/security-layer-model_v0.3.md`): it exposes a
+deterministic API contract and holds operational custody of the records it
+accepts.
+
+It is explicitly **not a decision point**. Audit Core answers what was recorded;
+it never answers whether an action is permitted, and it exposes no surface that
+returns such a verdict. See `## Out Of Scope Initially` and
+`history/2026-08-28-approval-evidence-assent.md`.
+
 ## Problem
 
 Modern platforms generate audit-relevant events in many places:
@@ -111,9 +123,14 @@ The data plane owns:
 5. **Immutable archive and hot search are separate concerns.** Hot search can
    be short-lived and cost-tuned. Immutable archive is the evidence record.
 
-6. **Tamper evidence is explicit.** Audit Core should store signed or
-   hash-chained manifests for retained batches so operators can later prove
-   whether a record set was changed, omitted, or truncated.
+6. **Tamper evidence is explicit, and bounded.** Audit Core should store
+   signed or hash-chained manifests for retained batches so operators can later
+   prove whether a record set was changed or truncated. The delivered bound is
+   narrower than that aspiration and `docs/integrity.md` is authoritative on it:
+   an in-database chain does not withstand a database owner without the external
+   chain-head attestation, and the chain proves nothing about an event that was
+   never emitted. Completeness at the boundary is the emitting source's
+   property, not the archive's.
 
 7. **Least-privilege access.** Tenants may access their own audit records
    according to policy. Platform operators may access cross-tenant records only
@@ -225,6 +242,33 @@ NetKingdom must not be required for Audit Core's internal authorization model.
 Audit Core may accept NetKingdom OIDC claims when configured, but should also
 support a generic OIDC provider and local development auth mode.
 
+## Approval Evidence
+
+Audit Core carries the **evidence half** of approvals as a distinct source, per
+security layer model §9.4 and `AUDIT-IN-0001` (assented 2026-08-28).
+
+`approval-engine` owns the operative approval state — the durable object, atomic
+supersession, single consumption, and revocation. Audit Core owns the record of
+what happened to it: the four event classes **issuance, use, supersession, and
+revocation**.
+
+Terms Audit Core accepts this under:
+
+- `approval-engine` is registered as a distinct source, with its own sender
+  registration, tenancy mapping, retention profile, and `secret_policy`,
+  onboarded under principle 4 like any other source;
+- `approval-engine` guarantees **emission atomicity** — an approval cannot be
+  issued, consumed, superseded, or revoked without the corresponding event being
+  durably queued in the same transaction. Audit Core cannot detect a suppressed
+  emission and will not imply that what it received is everything that happened;
+- Audit Core exposes **no approval-validity query**. Records, yes; a verdict
+  answering whether an approval is still valid, never. That would be deciding
+  early under §6.1 and would couple authorization to the audit fabric, which is
+  what §9.4 exists to prevent. Callers needing current state ask
+  `approval-engine`.
+
+Full reasoning: `history/2026-08-28-approval-evidence-assent.md`.
+
 ## Tenant And Scope Model
 
 Audit Core should distinguish: