audit-core/workplans/AUDIT-WP-0010-tenant-engine-sender-admission.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	depends_on
AUDIT-WP-0010	workplan	Admit tenant-engine as an attributive sender	infotech	audit-core	ready	claude	railiance	2026-08-29	2026-08-29	AUDIT-WP-0005

AUDIT-WP-0010 — Admit tenant-engine as an attributive sender

Goal

Close AUDIT-IN-0002. tenant-engine emits mutation evidence through a local outbox and cannot land events in production until audit-core admits the sender. This is another repository's production blocked on ours, which is why it is a workplan of its own rather than a task inside AUDIT-WP-0009.

The request is well-formed and arrives with its own bound already declared: class attributive, drain non-blocking, documented at tenant-engine/docs/evidence-emission.md. Under §9.6 that is a legitimate trade — attributive evidence may deliberately trade away atomicity provided the trade is declared and completeness is never claimed. tenant-engine declared it. Nothing here needs renegotiating; it needs admitting.

Intake: AUDIT-IN-0002 (01a04d8f-b1c1-746a-8007-15221ebf0a48), origin TEN-WP-0011-T04. Onboarding follows INTENT principle 4 — a source is onboarded when ownership, retention, access, export, and evidence policy are declared and validated, not when events start arriving.

Non-goals

• Reclassifying tenant-engine as load-bearing. It declared attributive and the declaration is the emitter's to make; §9.6 obligations follow the class.
• Carrying any credential value in this repository, in a work record, in State Hub, or in chat. The intake says so and it is right.
• Blocking on AUDIT-WP-0009-T03. The evidence_kind field lands there; admission does not wait for it, and T04 below records the class in the meantime.

Tasks

id: AUDIT-WP-0010-T01
status: todo
priority: high

Register the sender identity: name tenant-engine, sources: [tenant-engine], may_write: true, may_read: false, secret_policy: redact, tenants scoped as the envelope requires. Follow the existing user-engine shape in deploy/externalsecret-senders.yaml and deploy/senders-scope.yaml. No token value in Git — projected only, per the established lane.

id: AUDIT-WP-0010-T02
status: todo
priority: high

Provide the token lane. Coordinate the projected credential with the owning credential operator through the ops-warden route, matching the custody pattern already used for user-engine. Verify field presence without disclosure. Do not transport a value through State Hub messages.

id: AUDIT-WP-0010-T03
status: todo
priority: high

Extend the NetworkPolicy. deploy/networkpolicies.yaml currently admits user-engine; add tenant-engine. tests/test_networkpolicies.py exists — extend it so the second sender is asserted rather than assumed, and so a future third sender fails the test rather than silently failing in production.

id: AUDIT-WP-0010-T04
status: todo
priority: medium

Validate the envelope against what tenant-engine actually sends: schema_version: audit-core.event.v1alpha1, tenant = affected tenant_id, action = domain event type, resource = tenant:<id>, duplicate event ids returning 200. Confirm the duplicate path reconciles rather than minting a second link (test_replay_reconciles_rather_than_duplicating). If the envelope needs a field this engine does not send, reply with the correction the intake invited rather than accepting a lossy record.

Record the declared class (attributive, non-blocking drain, trade declared at tenant-engine/docs/evidence-emission.md) alongside the sender registration, so the §9.6 trade is documented here and not only in the emitter.

id: AUDIT-WP-0010-T05
status: todo
priority: medium

Prove it end to end against the production receiver: a real event from tenant-engine accepted, attributed to the right tenant, redacted per policy, and linked into the chain. Record the evidence under docs/evidence/. Then close AUDIT-IN-0002 with outcome promoted citing this workplan, and reply to tenant-engine.

Acceptance

• tenant-engine events land in production, correctly attributed and redacted.
• The token never appears in Git, a work record, State Hub, or chat.
• The NetworkPolicy admits exactly the intended senders, asserted by test.
• The attributive trade is recorded on audit-core's side, and completeness is nowhere claimed for this stream.
• AUDIT-IN-0002 closed and the requester answered.

Notes

tenant-engine did this the right way round: it built the outbox, declared the class honestly, documented the trade, and asked before assuming it could emit. The correct response is to move quickly, not to make it wait behind AUDIT-WP-0009.