Tenor and Curve Bootstrapping Architecture

The boundary is clean: refdata describes (codes, conventions, schedules), marketdata executes (resolves, looks up quotes, solves). The resolver is the bridge — it is the only place a tenor code becomes a date.

The domain concept is in Tenor; here is the persisted shape.

Seed data (populate scripts): O/N (SPECIAL/NONE, no multiplier) and SPOT (PERIOD/DAY/0) are tenors; RATES_SPOT_FORWARD and FX_SWAP_NEAR_LEG are ANCHOR_OFFSET conventions; CREDIT_CDS_IMM is the IMM convention.

tenor_resolution.cpp implements ores::refdata::api::domain::resolve_end_date(): given a tenor, a convention, a resolution row, a horizon date and a spot date, it returns the maturity date. Two branches:

• ANCHOR_OFFSET (implemented): resolved date = anchor + n × unit. The anchor comes from the resolution row's anchor_override if set, else from the convention's measured_from; resolve_anchor_date() handles SPOT, TODAY, TOMORROW (NEAR_LEG and IMM_ROLL need convention-specific handling). The offset is the resolution row's offset_unit=/=offset_multiplier if set, else the tenor's own unit=/=multiplier — so a bare 1M resolves as "spot + 1 month" under RATES_SPOT_FORWARD.
• SCHEDULE_STEP (decided, to be implemented): resolved date = walk(anchor + calendar offset, schedule, steps). The calendar offset uses the same offset_unit=/=offset_multiplier columns; the schedule axis is schedule_code + schedule_step_count. The resolver walks the schedule's date set from (anchor + offset) forward, taking the n-th date on-or-after it.

Today the resolver throws for IMM_ROLL and for ROLL_QUARTER offsets (std::logic_error) — the seeded rows document the gap. Under the unified model, SCHEDULE_STEP implements both; see the schedule section below.

The domain model is in Calendars, Holidays and Events and Calendar Events; here is the persisted shape.

The architectural split: holidays keep their recurrence machinery (calendar_rules, calendar_exceptions) and feed the calendar_date grid; calendar_event holds the non-holiday kinds. The holiday entry type stays in the vocabulary so the whole classification lives in one place. Events are diary entries with no downstream effect modelled — the Diary/Effects split (The Diary/Effects Model) keeps calendar_event stable regardless of future effect types.

Template/Instance recurrence: an event row is an instance; its template is the (calendar, diary_entry_type, name) triple. Formulaic recurrence (e.g. Non-Farm Payrolls) is deferred; calendar_rules's grammar can later feed a template link.

tenor_schedules (new, decided) is the schedule-axis vocabulary:

Two seeded schedules:

• ROLL_QUARTER (CLOSED_FORM): the IMM rule — first business day after 20 Mar/Jun/Sep/Dec. Derivable by rule; the closed form stays code-side in the resolver. This is the schedule the CREDIT_CDS_IMM convention walks: offset YEAR × 1 + schedule ROLL_QUARTER 1 step = "1Y 1RQ" (one year, one roll quarter).
• FOMC_MEETING (EVENT_LOOKUP): the FOMC meeting dates, read from calendar_event rows on the US.FOMC calendar (diary_entry_type = central_bank_meeting). Externally announced — data, not formula. This is the axis the RATES_SPOT_FOMC convention walks.

The two are the same mechanism: "the n-th date in a schedule, on or after the anchor". They differ only in where the dates come from. The old IMM_ROLL algorithm row and ROLL_QUARTER unit are superseded — one algorithm (SCHEDULE_STEP), one schedule vocabulary, no special cases.

The domain concepts are in Pillar and Interest Rate Curves; here is the code path.

1. Config. ir_curve_bootstrap_configs names one curve: output series, party, source series, curve_family_role (FUNDING / PROJECTION), discount_curve_config_id, interpolation_method, day_count_convention, and split_tenor_code — the tenor at which the short-end and long-end methods divide.
2. Pillars. ir_curve_bootstrap_pillars holds one row per pillar: start_tenor_code, end_tenor_code, curve_role_code (DEPOSIT/FRA/SWAP), sequence_index. Order is the fixed-leg schedule: a SWAP pillar's fixed-leg dates are the end dates of all prior pillars plus its own.
3. Resolve + quote. curve_republish_resolver.cpp sorts pillars by sequence_index and, per pillar: resolves both tenor codes to dates via the tenor resolver, and looks up the observed rate. The end tenor code is the point id into the raw grid (market_observations) — bp.point_id = p.end_tenor_code — and a pillar whose end code has no quote fails loudly.
4. Solve. curve_bootstrap_engine solves discount-factor-by- discount-factor from the short end, honouring interpolation_method and day_count_convention. The engine already accepts FLAT_FORWARD_THEN_LOG_LINEAR; CUBIC_SPLINE throws today.

The decided model (story * Decisions D1–D4) in one chain:

1. US.FOMC is a row in calendars (calendar_type central_bank_meeting, country_code US, source federalreserve.gov); currency_calendars links USD ↔ US.FOMC.
2. The 2025–2027 FOMC meeting dates are calendar_event rows (diary_entry_type central_bank_meeting) on US.FOMC, transcribed from the Fed's published calendar.
3. tenor_schedules carries FOMC_MEETING (EVENT_LOOKUP on that calendar); tenors carries 1F..=nF= (SPECIAL/NONE, multiplier n); RATES_SPOT_FOMC convention pairs measured_from SPOT with algorithm SCHEDULE_STEP and resolution rows schedule_step_count = n.
4. ir_curve_bootstrap_configs names the curve with interpolation_method FLAT_FORWARD_THEN_LOG_LINEAR and split_tenor_code marking the boundary; ir_curve_bootstrap_pillars lists SPOT→1F, 1F→2F, …, nF→split.
5. curve_republish_resolver resolves each end tenor (a lookup into the FOMC event set), finds the quote at that point id, and the engine solves — flat forward between meetings, continuous beyond.

No engine change, no new table per calendar, no special case: the FOMC short end is data plus one configuration.