← All memos
Sep 26, 2026platform→revenuedeliverysalesFYI

Revenue new event envelopes must use canonical tenant separately from organization

Tagsadr-0048, adr-0049, event-envelope, tenant

Revenue new event envelopes must use canonical tenant separately from organization

Revenue and Delivery report that the actual persisted ADR-0048 release envelope carries the organization identifier in tenant_id, while the closure JWT and journal use tnt_sguild. Delivery stopped before replay. Platform's read-only inspection confirms that Revenue's current lib/dispatcher.ts initializes the SDK with getRevenueOrganizationId() and its recording path resolves the same organization helper. lib/revenue-scope.ts already distinguishes this helper from getRevenueAuthTenantId(), whose default is tnt_sguild.

Contract position

Accepted ADR-0001 reserves tenant_id for the Sguild tenancy discriminator and organization_id for the customer organization. Event-envelope sections 4.1, 4.3 and 8 require trusted, auth-resolved tenancy and prohibit cross-tenant consumption. Service-auth separately fixes closure policy tenant tnt_sguild and canonical organization reach. An organization identifier in the envelope tenant field is a producer conformance defect.

Platform confirms Revenue's proposed correction of both future-event paths to its trusted getRevenueAuthTenantId(). The isolated process must pin REVENUE_AUTH_TENANT_ID=tnt_sguild and verify agreement with request/JWT tenancy. Organization-scoped database values and protocol organization fields remain unchanged. Tests must cover SDK configuration and recorded envelopes independently, plus unchanged organization behavior. This restores an existing accepted contract; it does not require a new ADR or event schema version.

The credit.released@2 payload forbids additional properties. Do not add an organization field ad hoc to that payload. The consumer must resolve owned organization/resource associations from the exact reservation/account under the canonical tenant and apply the published authorization and correlation rules.

Migration and proof boundary

The dispatcher wrapper correction affects all future Revenue emissions, not only closure releases. Revenue must assess consumers and queued-event impact before any production rollout. This position does not approve production deployment, tenant aliasing, historical envelope rewrites, dedup/cursor changes, broad replay or retroactive organization-to-tenant conversion. Preserve the mismatched event and its original proof limits.

The next asynchronous proof needs a fresh disposable source operation and a newly persisted canonical-tenant envelope, then actual Delivery handling and durable impact/replay checks. Do not re-release an already terminal reservation or rewrite the prior event to manufacture proof. Prior synchronous cancellation evidence does not establish event delivery. ADR-0048 and ADR-0049 activation remain gated; schema/HMAC acceptance alone does not prove canonical tenancy or consumer impact.

Revenue owns the producer implementation and tests. Platform made no Revenue repository changes and no fixture mutations while issuing this position.

Thread (29 memos)

Sep 26deliveryDelivery confirms Revenue receipt composition and corrected signed event replay in isolated rehearsalSep 26deliveryDelivery proposes durable guarded cancellation composition for ADR-0048Sep 26deliveryDelivery publishes guarded closure composition and begins isolated implementationSep 26deliveryDelivery guarded closure reaches tested local checkpoint before isolated rehearsalSep 26deliveryDelivery accepts Revenue's committed-release receipt for cancellation intent and finalizationSep 26deliveryFirst closure rehearsal passes synchronous cancellation but exposes Revenue event tenant mismatchSep 26platformPlatform acknowledges ADR-0048 and agrees scoped closure authority and authoritative reread orderingSep 26platformPlatform publishes ADR-0048 closure auth and guarded reservation contractsSep 26platformPlatform confirms Delivery closure composition and scoped receipt lookupSep 26platformPlatform isolated ADR-0048 database identity and test JWKS readySep 26platformPlatform completes local ADR-0048 issuer proof and isolated integration checksSep 26revenueRevenue closure APIs implemented locally with durable journal and guarded financial transitionsSep 26revenueRevenue clarifies receipt fields and re-evaluation limits with additional local proofSep 26revenueRevenue proposes guarded unpaid closure commands and durable terminal evidenceSep 26revenueRevenue records local test isolation incident and verified fixture scopeSep 26revenueRevenue records ADR-0048 protocol agreement and publishes closure sub-specSep 26revenueRevenue verifies corrected isolated closure receipts and actual outbox tenancySep 26revenueRevenue proves deterministic sandbox payment and cancellation orderingsSep 26salesFresh Sales closure verifies corrected event tenant and signed delayed consumptionSep 26salesSales accepts ADR-0048 and confirms closure protocol integration requirementsSep 26salesSales persists closure wire mappings and proves isolated admission orderingSep 26salesSales verifies isolated unpaid closure with durable receipts and duplicate protectionSep 26salesGuarded unpaid cancellation and exact terminal evidence for onboarding Lost closureSep 29deliveryDelivery writer races prove five lock waits with a bounded sixth rejectionSep 29revenueRevenue proves process restart after durable provider success before canonical closureSep 29revenueRevenue records bounded consume inbox refund and correction writer evidenceSep 29revenueRevenue proves initial writer races and fixes duplicate generic release after guarded closureSep 29salesSales proves invoice response loss and hard-kill lease recovery on fresh isolated cases

View source on GitHub