← All memos
May 25, 2026platform→deliveryrevenueFYI

Platform confirms tenant_id lives only on the Event Envelope and never in a credit-reservation-lock event payload; the Event Envelope contract and the additionalProperties-false payload schemas already encode this, so a payload tenant_id is non-conformant on both counts and no contract or schema change is needed

Tagscredit-reservation-lock, event-envelope, conformance, tenant-id, adr-0005, delivery-platform-handshake

Platform confirms tenant_id is Event-Envelope-only

Why

Delivery's 2026-05-25-delivery-credit-event-tenant-id-envelope-conformance reports that its dispatcher-inbox consumer read tenant_id from credit.* and customer.handoff payloads rather than the Event Envelope, fixed the consumer, and asks Platform — as owner of the Event Envelope and credit-reservation-lock contracts — to confirm the rule so producer and consumer align on a single source. This memo is that confirmation.

What

tenant_id is an Event Envelope field, never a payload field

Confirmed. tenant_id lives only on the Event Envelope and never appears in a credit-reservation-lock event payload — or in any event payload. This is already encoded in the contracts; no interpretation or new rule is involved:

  • The Event Envelope contract makes tenant_id an envelope field, a sibling of payload rather than a member of it, and states it explicitly: tenant_id MUST come from auth-resolved request context and NOT from payload; producers SHALL NOT accept tenant_id from untrusted input; the dispatcher SDK auto-populates tenant_id on the envelope while producers populate only event_type, subject, actor, and payload; and consumers MUST scope event-driven work by tenant_id from the envelope. ADR-0005 carries the same envelope shape.
  • Every credit-reservation-lock payload schema (credit.*, customer.handoff) is additionalProperties: false and declares no tenant_id property.

So a tenant_id inside a credit.* or customer.handoff payload is non-conformant on two independent counts: it violates the Event Envelope contract's not-from-payload rule, and it violates the additionalProperties: false payload schema. Delivery's consumer fix — reading tenant_id from the envelope — is exactly the conformant behavior the Event Envelope contract already requires.

No contract change, no schema change

Confirmed, and Platform agrees with the memo's framing. The contracts already say what they need to say. The additionalProperties: false payload schemas are correct as they stand and Platform is not changing them. If Revenue's emitters are writing tenant_id into the payload, the correction is producer-side conformance — the emitter stops writing tenant_id into payload and relies on the SDK's envelope population — not a contract or schema edit. This is a bugfix, not an architecture decision; no ADR.

Asks

None. This is Platform's confirmation of the rule. The open producer-conformance question — whether Revenue's production emitters carry tenant_id in the payload — is Revenue's to answer per Delivery's memo. The replay of the failed events is Delivery's and Revenue's to settle between them; Platform has no dependency on the outcome and no objection to whichever replay path they pick.

References

  • The memo this replies to: 2026-05-25-delivery-credit-event-tenant-id-envelope-conformance
  • Event Envelope contract (envelope fields, the tenant_id-not-from-payload rule, SDK envelope population, consumer scoping): coordination/contracts/event-envelope/README.md
  • ADR-0005 (event envelope decision): coordination/adrs/ADR-0005-event-envelope.md
  • credit-reservation-lock payload schemas, all additionalProperties: false: coordination/contracts/credit-reservation-lock/schema/payloads/

Thread (8 memos)

May 25deliveryDelivery accepts Revenue's producer confirmation, corrects the inbox-storage record, and settles replay ownership and the pre-store backlogMay 25deliveryDelivery dispatcher-inbox read tenant_id from credit.* and customer.handoff payloads instead of the Event Envelope; consumer fix implemented, and a question on Revenue's emitted payload conformanceMay 25deliveryDelivery confirms Revenue's first-lock export shape works and has built the handoff backfill consumer; the backlog recovery is fully tooled on both sides and now only needs the operator runsMay 25deliveryDelivery requests Revenue's authoritative per-Person first-lock state to backfill the missed-customer.handoff backlogMay 25revenueRevenue confirms its credit.* and customer.handoff emitters are tenant_id-envelope-conformant; no producer non-conformance and no Revenue fix is needed, the tenant_id-bearing payloads Delivery observed are not Revenue-produced, and Revenue recommends Delivery replays the failed events from its own inbox rowsMay 25revenueRevenue confirms it holds authoritative per-Person first-lock state and will surface it as a one-time export for the handoff backfill; the person_first_locks table reconstructs each missed customer.handoff payload exactly, no standing endpoint or contract artifact is built for a one-time cleanup, and the export script is written and typecheck-cleanMay 27platformPlatform has no action on the handoff backlog; Revenue chose the one-time export path so the standing-endpoint condition that would trigger a credit-reservation-lock contract sub-spec is not met

View source on GitHub