9000-product-def-authority

#	Message Name	Description
9009	CalendarDefinitionV3	One row per calendar: what its weekend looks like, which calendars it composes, and the settlement conventions anchored to it. HolidayCalendarV3 (9012) carries the exception dates for the same calendarId. A CALENDAR IS A NAMED RULE SET, NOT A DATE LIST. A weekend mask plus named holiday rules resolve to dates; per-date overrides carry the irregular facts - ad-hoc closures, half days. CALENDARS COMPOSE. A row with members is a UNION of them, derived rather than authored twice; a row with an empty member list is primitive.
9012	HolidayCalendarV3	The holiday calendar of record: one calendar's content - its weekend, the variance-time shape of its trading day and its dated exceptions - keyed by that content. THE KEY IS THE CONTENT. calendarKey is a ContentKey tagged Calendar over the SHA-256 of the canonical form (CALENDAR_CONTENT_KEY.md), byte 0 dropped for the tag. A loader hashes what it built and publishes; two producers building the same calendar publish the same row, and nobody mints an id. A row is immutable: a changed calendar is a new row under a new key, and a deleted row is content withdrawn. THE NAME LIVES ELSEWHERE. ScheduleDefinitionV3 (9057) points a product group at a key and carries the Manual / Loader / Bridge ladder; CalendarDefinitionV3 (9009) is the human registry of adopted names (XCME, USNY) pointing at their current key. The compiled tables are the floor beneath both and keep their names. desc is the producer's memo - 'union of XAMS, XEUR', 'XCME 2026 refresh' - readability, never identity.
9045	MaterialEventOccurrenceV3	one dated instance of a series. The pkey is DELIBERATELY date-free: the date is the field that MOVES (estimate -> published), so identity survives the Forecast -> Announced migration and a firmed-up date is a state change, never a delete/insert
9042	MaterialEventSeriesV3	one record per recurring series of date/time-definite repricing events: bank meetings, gov reports, inventory numbers, auctions, earnings, production policy
9057	ScheduleDefinitionV3	The trading schedule that applies to a group of products: which holiday calendar it keeps, which rotation window sets its trade-date boundary, and which venue lists it. One row per (ticker source, product family, product group). MarketHoursV3 (9142) holds the per-date session times for the same three-part key. RESOLUTION: look up the product's exact scheduleGroup; if there is no row, fall back to scheduleGroup '*'. THREE SOURCES, ONE LADDER. Every source publishes its own row and the reader takes the best one present: Manual beats Loader beats Bridge; a deleted or pending-delete row is that source declining. A Manual row that names a corrected HolidayCalendarV3 (9012) content key is how a late announcement lands without displacing the loader's row; withdrawing it falls back to the loader. An empty key means the group keeps the compiled default calendar for its source.
9015	TradingPeriodDefinitionV3	THE ROTATION RULE: how a timestamp becomes a trade date. One row per TradingPeriod value. A timestamp at or after cutoffTime, read in timeZone, belongs to the NEXT trade date. ORDER MATTERS. Rotate FIRST, then test the trade date against the calendar. 'Is today a trading day? no -> reject' drops CME's Sunday evening session; 'which trade date is this? -> Monday; is Monday a trading day? -> yes' keeps it. Same two facts, opposite answers. WHICH PERIOD APPLIES is on the product: tradingPeriod on CCodeDefinitionV3 (165), RootDefinitionV3 (223) and TickerDefinitionV3 (279). THE NAME tradingPeriod IS OVERLOADED. Here and on MarketHoursConfig (4485) and ExpiryDateRiskCounter (4640) it is enum:TradingPeriod - this rule. On SpdrChildOrderSummary (2055), SpdrChildExecutionSummary (2050), OptionPrintSetSummary (2820) and SpdrParentBrokerSummary (4075) it is tradingPeriod:DateKey - the ROTATED DATE itself. Check the type before joining.