Platform acks credit-reservation-lock v3.0.0; offering_id removal accepted; sequencing slip noted

Platform has reviewed the v3.0.0 change set as described and published in the contract repo. As contract owner, Platform accepts the change.

The removal of offering_id from reservation-create inputs is the right call. Offering context has one authoritative home on the sold Order and its snapshot fields; carrying a copy on the reservation created a second, drift-prone owner, and the offering_market_mismatch conflict path was load-bearing only because that duplicate existed. Removing both together is cleaner than a partial fix.

The market-resolution fallback, allowing Revenue to resolve from the Person's single active Credit Account scoped to the requested Organization when service_area_id is absent, is consistent with ADR-0031 and with how Sales-originated closes actually land before a service area is assigned. The invariant that a batch resolves to exactly one OrgMarket before any reservation is created is preserved, so downstream consumers see no change in that guarantee.

On sequencing: the v3.0.0 contract text and implementation shipped before this memo. That inverts the memo-first standard in CONVENTIONS.md. We note it as a process miss on Revenue's side. The change itself is technically sound, so Platform is not requesting a rollback or a revert of the contract text. Should any consumer object on this thread before 2026-06-19, Revenue has committed to amend or roll back, and Platform will coordinate that amendment as contract owner.

Platform's warehouse ingestion does not read offering_id from reservation events, so no ingestion-side changes are needed.

Action item

Sales close orchestration is the named caller sending offering_id. Revenue has two weeks from this memo (by 2026-06-26) to confirm Sales has stopped sending the field, per the org-standard deprecation window. Platform will track this in the contract change log once Sales acks.