Task: Normalize floating-rate index reference data

Table of Contents

This page documents a task in the IR Rates synthetic data: dataset seeding, index cleanup, dual-curve, quoting conventions story. It captures the goal, current status, acceptance, and any notes or results.

Goal

Replace the two existing flat "CCY-INDEX" floating-rate index catalogs – ores.refdata.floating_index_type.code and ores.refdata.overnight_index_convention.id (both encode currency and index atomically, e.g. "USD-SOFR", and both carry overlapping convention fields) – with a properly normalized model: a standalone index entity (ESTR/SOFR/SONIA/EURIBOR etc, carrying the fixing calendar/day count/settlement lag/description conventions currently duplicated across the two existing tables) plus a currency_index junction table that asserts which currencies use which index as real data, not as a naming convention baked into a string code.

Raised while building the IR curve editor's index-name combo in Market Simulator (Tick-batch publishing and persistence for curve instruments): that task's ir_curve_generation_config.index_name currently stores the full floating_index_type.code as a deliberate stopgap (reusing the entity's existing single-argument FK validator rather than inventing a composite one) – this task is where that stopgap gets replaced with a real FK to the normalized model.

Status

Field Value
State ABANDONED
Parent story IR Rates synthetic data: dataset seeding, index cleanup, dual-curve, quoting conventions
Now Nothing.
Waiting on Nothing.
Next Nothing – superseded, see Result.
Last touched 2026-07-28

Acceptance

  • A decision is made and documented on whether floating_index_type or overnight_index_convention survives as (or is replaced by) the new index entity – not both continuing to exist as parallel catalogs.
  • A new currency_index junction table (or equivalent) exists, asserting the currency(ies) each index applies to as data.
  • A decision is made on how term-rate indices with tenor variants (e.g. EURIBOR-3M/6M/12M) fit the junction shape, or whether they need their own modeling – not silently dropped or ignored.
  • Every existing consumer of the two old catalogs is migrated to the new model, including ir_curve_generation_config.index_name (currently storing the full floating_index_type.code as a stopgap – see this task's Goal).
  • Schema validated clean after the migration (validate_schemas.sh).

Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Notes

Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

PRs

PR Title
#1713 [agile] Abandon floating-index normalization task, supersede by oresmd

Review

# Comment summary File Decision Notes
1 Both automated reviews confirmed the two filed findings against the codebase; no blocking issues - Accepted (cosmetic) Fixed Status table cell padding in c7a5d7b2c

Result

Abandoned in favour of a broader, already-designed replacement: oresmd, ORE Studio's canonical market data URI, merged to main after this task started. oresmd's index_family enum + tenor query key close exactly the free-text index_name gap this task set out to fix, but as one field combination of a single scheme spanning every asset class, not a new standalone index=/=currency_index refdata model – building the latter would have created a third competing scheme alongside oresmd, the "no three competing schemes" anti-pattern the oresmd migration capture's own Why section warns against.

An implementation attempt got far enough to surface two real findings before being abandoned, both filed on the migration capture rather than here:

  • floating_index_type's 25 rows are a flattened mix of two other real tables, overnight_index_convention and ibor_index_convention – both live destinations of ores.cli's ORE conventions.xml import command, not orphaned scaffolding (a first pass wrongly concluded "zero consumers" from grepping only SQL soft-FK references, missing this CLI import path entirely). oresmd's index_family enum design needs to account for both.
  • ir_curve_generation_config's (currency_code, index_name) pair is exactly what the migration capture's own per-field plan already names as migrating onto a type=curve oresmd URI – confirming this task's own scope is a subset of that capture's, not independent work.

The index=/=currency_index codegen model, seed data, and consumer migration built during the implementation attempt were not committed (stashed, then discarded) – floating_index_type=/ =overnight_index_convention remain as-is pending the oresmd migration.

Follow-on work tracked on Migrate to oresmd, delete market_series qualifier and ore_key, not a new task here.

Emacs 29.3 (Org mode 9.6.15)