audit-core/deploy/senders-scope.json

[
  {
    "name": "user-engine",
    "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"
  }
]
Implement AUDIT-WP-0006 honest operational custody. Postgres now reports custody_class=operational with a cited 30-day recoverable window. Join ITC-CAP operations.audit at D4, publish the interface card, and overlay user-engine tenants [*] from Git so an ExternalSecret refresh cannot shrink it. 2026-08-16 00:24:33 +02:00			`[`
			`{`
			`"name": "user-engine",`
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 2026-09-06 22:31:37 +02:00			`"sources": [`
			`"user-engine"`
			`],`
			`"tenants": [`
			`"*"`
			`],`
Implement AUDIT-WP-0006 honest operational custody. Postgres now reports custody_class=operational with a cited 30-day recoverable window. Join ITC-CAP operations.audit at D4, publish the interface card, and overlay user-engine tenants [*] from Git so an ExternalSecret refresh cannot shrink it. 2026-08-16 00:24:33 +02:00			`"may_write": true,`
			`"may_read": false`
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 2026-09-06 22:31:37 +02:00			`},`
			`{`
			`"name": "approval-engine",`
			`"sources": [`
			`"approval-engine"`
			`],`
			`"tenants": [`
			`"*"`
			`],`
			`"may_write": true,`
			`"may_read": false,`
			`"evidence_kind": "load-bearing"`
Implement AUDIT-WP-0006 honest operational custody. Postgres now reports custody_class=operational with a cited 30-day recoverable window. Join ITC-CAP operations.audit at D4, publish the interface card, and overlay user-engine tenants [*] from Git so an ExternalSecret refresh cannot shrink it. 2026-08-16 00:24:33 +02:00			`}`
			`]`