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

deploy/networkpolicies.yaml

@@ -63,6 +63,36 @@ spec:
 ---
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
+metadata:
+  name: audit-core-approval-engine-ingress
+  namespace: audit-core
+spec:
+  podSelector:
+    matchLabels:
+      app.kubernetes.io/name: audit-core
+  policyTypes: [Ingress]
+  ingress:
+    # AUDIT-WP-0009-T09 / AUDIT-IN-0001. Load-bearing approval evidence
+    # (§9.4). Both selectors belong to one peer and are therefore ANDed:
+    # only the approval-engine workload in its own namespace reaches this
+    # port. Splitting them into two list items would turn AND into OR and
+    # admit every pod in either set.
+    #
+    # Narrower than user-engine's namespace-only rule on purpose: this is a
+    # new sender, and a new rule should not inherit an older rule's breadth.
+    # user-engine's policy is deliberately left unchanged.
+    - from:
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: approval-engine
+          podSelector:
+            matchLabels:
+              app.kubernetes.io/name: approval-engine
+      ports:
+        - {protocol: TCP, port: 8080}
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
 metadata:
   name: audit-core-operator-ingress
   namespace: audit-core

deploy/senders-scope.json

@@ -1,9 +1,25 @@
 [
   {
     "name": "user-engine",
-    "sources": ["user-engine"],
-    "tenants": ["*"],
+    "sources": [
+      "user-engine"
+    ],
+    "tenants": [
+      "*"
+    ],
     "may_write": true,
     "may_read": false
+  },
+  {
+    "name": "approval-engine",
+    "sources": [
+      "approval-engine"
+    ],
+    "tenants": [
+      "*"
+    ],
+    "may_write": true,
+    "may_read": false,
+    "evidence_kind": "load-bearing"
   }
 ]

deploy/senders-scope.yaml

@@ -2,6 +2,14 @@
 # audit-core-senders. This ConfigMap is the authority for tenants/sources
 # so an ExternalSecret refresh cannot revert user-engine to a single tenant.
 # Keep in lockstep with deploy/senders-scope.json.
+#
+# The overlay only ever applies to a sender the Secret already carries, so an
+# entry here for a sender with no token yet is inert. That is what makes the
+# approval-engine entry safe to land ahead of its credential.
+#
+# evidence_kind may be raised here (attributive -> load-bearing) but never
+# lowered: a ConfigMap refresh must not be able to drop a source's §9.6
+# atomicity and detection obligations without anyone deciding to.
 ---
 apiVersion: v1
 kind: ConfigMap
@@ -19,5 +27,13 @@ data:
         "tenants": ["*"],
         "may_write": true,
         "may_read": false
+      },
+      {
+        "name": "approval-engine",
+        "sources": ["approval-engine"],
+        "tenants": ["*"],
+        "may_write": true,
+        "may_read": false,
+        "evidence_kind": "load-bearing"
       }
     ]