Corpus-validated cancellation policy type for policies[] — seeking Lodging TC feedback

[yairsabag]

Context

During the design discussion for policies[] in #572, I brought a services/bookings use case that is difficult to express as a single refund window: cancellation terms that are tiered, relative to a service anchor such as check-in or event start, and may produce partial refunds, fixed fees, or unit deductions.

The maintainer response described this as a useful stress test and a textbook extension over the generic policy primitive, with the guidance to prototype it independently, validate it against real policies, and bring implementation experience back if the shape held.

What is now available

Following that guidance, I validated the design against approximately 40 publicly available cancellation policies across lodging, events, tours/activities, transportation, services and an Israeli consumer-law reference set. The v0.2 shape fully represented 37 of 40 policies in that corpus; the methodology and the three partial cases are documented explicitly.

With policies[] now stable in UCP v2026-08-25, I have published policy.cancellation v0.3.0:

• io.github.yairsabag.policy.cancellation, an independent reverse-DNS policy type
• anchor-relative and purchase-relative tiers
• buyer cancellation, no-show, seller cancellation and postponement triggers
• percentage, fixed-fee and unit-deduction outcomes
• open discriminators and vocabularies following the current UCP schema-authoring guidance
• a deterministic reference evaluator and seven reusable test vectors
• policy-placement fixtures for Catalog, Cart, Checkout and Order
• automated schema validation and tests

Repository: https://github.com/yairsabag/policy-cancellation
Methodology: https://github.com/yairsabag/policy-cancellation/blob/main/docs/methodology.md
Compatibility notes: https://github.com/yairsabag/policy-cancellation/blob/main/docs/UCP-2026-08-25.md

Standardization boundary

This is not presented as an adopted UCP shared type. The generic policies[] envelope is stable UCP; the cancellation type remains independently versioned under io.github.yairsabag.*.

Feedback requested

1. Does this packaging match the intended model for a third-party policy type on UCP v2026-08-25?
2. What independent implementation or adoption evidence would the project want before considering a shared dev.ucp.shopping.policy.cancellation type?
3. Would members of the Lodging Technical Council, or other booking/services implementers, be interested in reviewing the schema and contributing policies that the current model cannot express?

The most valuable feedback is a real policy or workflow that breaks the model.