AUDIT-WP-0009-T03/T09 — evidence_kind, and approval-engine's registration inputs

T03. §9.6 gives load-bearing and attributive sources different obligations, so
the archive must record which one a source declared rather than infer it from
traffic. evidence_kind and completeness_trade now sit on SenderIdentity, the
AUDIT_CORE_SENDERS schema, and the non-secret scope overlay.

Two asymmetries are deliberate. The default is attributive, because the other
default would have audit-core imply a completeness obligation no source ever
accepted. And the overlay may raise the kind but never lower it — the same
principle that stops an ExternalSecret refresh shrinking user-engine's
tenants: a ConfigMap refresh must not drop a source's atomicity and detection
obligations without anyone deciding to. A load-bearing source may not carry a
completeness trade at all, since §9.6 requires atomicity of it, and
evidence_declaration() reports completeness_claimed: false for both kinds.

T09 (in progress). approval-engine's registration inputs are prepared and
recorded in docs/approval-engine-source-registration.md: scope entry declared
load-bearing, and audit-core-approval-engine-ingress with namespace and pod
label ANDed in one `from` peer — narrower than user-engine's namespace-only
rule, which is left unchanged. The scope entry lands ahead of the credential
because the overlay only applies to senders the Secret already carries, so it
admits nothing until the token exists; a test asserts that rather than
trusting the reading.

Two inputs remain approval-engine's: a confirmed tenant scope, since senders.py
requires a missing tenant restriction be justified per sender and audit-core
cannot justify it on another repo's behalf, and an explicit secret_policy
choice. Applying the manifests is an operator action.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713962@bnt-lap001
Assistant-Session: 2718d99d-d3ff-478f-83a2-3a30f01a02fc

workplans/AUDIT-WP-0009-evidence-role-conformance.md

@@ -102,7 +102,7 @@ and proves nothing. Record the cadence in `docs/integrity.md`.
 
 ```task
 id: AUDIT-WP-0009-T03
-status: todo
+status: done
 priority: high
 state_hub_task_id: "acae6085-ada7-51b2-8dc0-4abac7f7e7b3"
 ```
@@ -114,6 +114,23 @@ deliberately traded away atomicity, carry the declared trade with it, because
 §9.6 requires the trade be declared where the trail is documented. Prerequisite
 for T04–T06.
 
+Done 2026-09-06. `evidence_kind` and `completeness_trade` on `SenderIdentity`,
+the `AUDIT_CORE_SENDERS` schema, and the non-secret scope overlay. Two
+asymmetries are deliberate and asserted:
+
+- **Default is `attributive`.** The other default would have audit-core imply a
+  completeness obligation no source ever accepted.
+- **The overlay may raise the kind, never lower it.** Same principle that stops
+  an ExternalSecret refresh shrinking `user-engine`'s tenants: a ConfigMap
+  refresh must not be able to drop a source's atomicity and detection
+  obligations without anyone deciding to. Downgrading raises.
+
+A load-bearing source may not carry a `completeness_trade` — §9.6 requires
+atomicity of it, so recording a trade would store a contradiction as policy.
+`evidence_declaration()` states `completeness_claimed: False` for **both**
+kinds, because neither licenses the claim that the archive proves an event
+occurred. Twelve tests in `tests/test_senders.py`.
+
 ```task
 id: AUDIT-WP-0009-T04
 status: todo
@@ -181,7 +198,7 @@ is worth asserting in `tests/`.
 
 ```task
 id: AUDIT-WP-0009-T09
-status: todo
+status: progress
 priority: high
 state_hub_task_id: "fd4a4ac3-e525-57c1-9179-e0fcd0226913"
 ```
@@ -213,6 +230,40 @@ Token provisioning goes by the approved custody path
 (`approval-engine/approval-engine-audit`, key `audit-token`) via `warden
 route`; no sender token passes through Git, State Hub, or a workplan.
 
+**In progress 2026-09-06.** T03 landed, so the registration inputs are now
+expressible. Prepared, non-secret, and recorded in
+`docs/approval-engine-source-registration.md`:
+
+- Non-secret scope in `deploy/senders-scope.json` and `senders-scope.yaml`,
+  `evidence_kind: load-bearing`, `may_read: false`, exact source match. Landed
+  ahead of the credential deliberately: the overlay only applies to a sender
+  the Secret already carries, so the entry admits nothing until the token
+  exists. A test asserts that inertness rather than trusting the reading.
+- `audit-core-approval-engine-ingress` in `deploy/networkpolicies.yaml`:
+  namespace **and** pod label in one `from` peer, so both are ANDed. Narrower
+  than `user-engine`'s namespace-only rule on purpose — a new sender should not
+  inherit an older rule's breadth. `user-engine`'s policy is unchanged, and a
+  test asserts it stays that way.
+- The four §9.4 classes, retention (no expiry; 30-day `measured` recoverable
+  window), custody class, and the claim bound.
+
+**Two inputs are owed by `approval-engine`, not by audit-core.** `tenants` is
+proposed as `["*"]` and needs confirmation with reasoning or a list —
+`senders.py` says a missing tenant restriction must be justified per sender,
+and audit-core cannot justify it on another repo's behalf. `secret_policy` is
+recommended `redact` (losing a revocation record is worse than storing it with
+one field redacted) but should be chosen explicitly rather than inherited.
+Applying the manifests is an operator action audit-core does not take
+unprompted.
+
+**T02 is not a gate on this.** Asked directly by `glas-harness`: attestation
+freshness governs what audit-core may *claim*, not whether it accepts and
+durably stores. The append-only trigger and hash chain operate regardless. And
+it is not even the relevant control — §9.6 is explicit that the acute risk for
+approvals is omission, which tamper evidence does not address at all. T04 does.
+A consumer waiting on T02 before trusting approval evidence would be waiting on
+the wrong thing.
+
 ```task
 id: AUDIT-WP-0009-T10
 status: todo