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_typeorovernight_index_conventionsurvives as (or is replaced by) the newindexentity – not both continuing to exist as parallel catalogs. - A new
currency_indexjunction 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 fullfloating_index_type.codeas 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_conventionandibor_index_convention– both live destinations ofores.cli's OREconventions.xmlimport 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'sindex_familyenum 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 atype=curveoresmdURI – 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.