A booking can only point at a tier, so every session of every tariff needs a row that says nothing

A tier, the slot tariff, exists to do three things: carry a quota for one session, carry a price override for one session, and give a booking something to point at. Only the third is always needed, because the booking has a slot tariff reference and no tariff reference, so a tariff can only be booked on a session that has a row joining the two.

The consequence is that generation creates one row per tariff per session whether or not anything differs. A season of two hundred sessions selling four rates is eight hundred rows, and most of them repeat what the tariff already said. They are not free: they are what the availability feed groups over, what the placement queries join through, and what a policy walk has to load. They also make a tariff level change unable to reach anything, since the numbers were copied into the rows at generation.

The alternative

A booking names the slot and the tariff, and names a tier as well only when one exists. The tier stops being the mandatory intermediary and becomes the exception that carries an override for one session. Nothing has to be created to make a rate sellable, so a resource with four rates and no per session differences has four rows in total rather than eight hundred, and the sessions that do differ still get a row saying how.

That is the common case, and it is why this is worth doing rather than merely tidy: most resources price the same way all season, so most tiers carry no information at all.

Capacity resolution reads in the same order it does now, most specific first: the tier quota when a tier exists, the slot capacity otherwise. Consumption is counted by slot and tariff rather than by tier, which is what lets a session without a tier be counted at all.

An untiered slot then stops being a separate mode and becomes the ordinary case with no tariff named, which is one less branch in the feed, in capacity resolution and in the held overlay, all of which currently carry a slot token for the tariffless case.

What it costs

This is an engine storage change, not a refactor. Thirty three files outside tests mention the slot tariff, including the booking entity and its storage schema, the availability feed, the transaction summary, the venue map builder and the place selection controller, the views integration, the api client and the manager. Every query that counts consumption joins through it, and capacity is governed by the tier quota when one exists and the slot capacity otherwise, so the resolution order has to be restated rather than moved.

Alpha releases are reinstall only, so there is no migration to write, which is the one thing making this affordable at all. It gets much more expensive after a stable release.

Why it matters beyond the row count

Several things filed separately are the same observation wearing different clothes. Policy attachments cannot be queried because they live in a json blob, so finding the resources in an exclusivity group loads and decodes every one. A policy walk climbs the tier to the tariff to the resource to the type on every line. The constraint model, see #3614532: Constraint policies should declare what they need rather than when they run, and stop assuming a tariff, keeps treating the tariff as the axis everything hangs off because the booking cannot name anything else. Giving a booking a tariff of its own shortens all of those chains.

Not yet decided

Whether a tier keeps its own entity at all or becomes a per session override attached to the tariff, and what happens to the place grade mapping in placement, which is expressed per tier today. Both want thinking through before anything is written.