Model & actors

ABP’s vocabulary is registry-shaped (mapped from EPP). The terms carry meaning — use them exactly, capitalized.

Term	Role	EPP analog
Registry	authority of the commercial state; owner of the Buckets (the single writer per Bucket)	Registry
Channel	who books/sells	Registrar
Repository	aggregates Buckets; the event container (in a match, the game)	zone / TLD
Bucket	the finite contested availability you draw a seat from; carries a BucketKind	namespace
Unit	the bookable unit — exists only in a QUALITATIVE Bucket	object / domain
Allocation	a slot plugged to a holder (a concrete Unit, or a quota in a quantitative Bucket)	result of create
Booking	the aggregate with the FSM (N Allocations; = the Order / cart)	—

BucketKind: QUALITATIVE vs QUANTITATIVE

A Bucket is of one kind only (XOR). This is a protocol concept, domain-agnostic.

• QUALITATIVE — addressable availability: the Bucket has distinct Units (each with its own lock/uniqueness). The resolution axis applies (ANONYMOUS ↔ CONCRETE).
• QUANTITATIVE — fungible availability: capacity only (an atomic counter), no addressable Unit. Resolution is N/A — an Allocation is a quota.

Seat/GA are domain vocabulary

BucketKind replaces the old UnitKind{SEAT, GA_SLOT}. Seat (qualitative) and GA (quantitative) are Tickets-domain words — like a numbered space vs a yard (Parking), or a named credential vs a pool (Accreditation). They live in the Catalog, not the protocol.

Hierarchy

Repository (event / game)
└── Bucket (sector × Unit type)         ← single-writer partition
    └── Unit (only if QUALITATIVE)
        └── Allocation (Unit / quota plugged to a holder)

A Channel books against a Bucket → an Allocation; the aggregate is the Booking.

Bucket = sector × type. Not just the sector: “regular seats of the Upper East” is one Bucket; “wheelchair / companion of the Upper East” is another. The type maps directly to who may book (the product’s auth layer). Finer partition = more parallelism.

Booking = Order

The aggregate that Hold creates (N allocations, 1+ Buckets/domains) is the Order / cart. Booking is the canonical term; Order is the colloquial synonym. The cart is incremental via AddItems / RemoveItems while still HELD.

Registry-shaped principle

Every command is issued by a Channel against a Bucket, even when in v1 all Channels are internal to one Account. This keeps the league-owned registry thesis open for free — an external club/ticketing site later becomes “one more credentialed Channel” against the same authoritative Bucket. Hooks are designed, not implemented in v1: external registrar credentials, prepaid credit, registrar poll/message-queue.

Domain (Catalog) vs Reservations

CATALOG (domain)                       RESERVATIONS (ABP, agnostic)
────────────────                       ────────────────────────────
Tickets       → Seat=QUAL / GA=QUANT ┐
Accreditation → credential nom/pool  ├──►  owner of the COMMERCIAL state (FSM)
Parking       → numbered space/yard  ┘     knows only Bucket(Kind) + Booking FSM
identity + physical + materializes     Hold / Confirm / Settle / Fulfill / Refund

Strong consequence: a cross-domain batch is a cross-Bucket batch. Reserving “3 tickets

• 1 parking space” in one Booking is just allocating Units from different Buckets — and since all Buckets live in Reservations after Open, there is no cross-module dance.