Story: Audit the rates instrument family against the data-oriented design guidelines
Table of Contents
This page documents a story in Sprint 28. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
Establish, with evidence, whether the rates instrument family's data model meets the data-oriented design guidelines, and record the findings so the remediations can be planned.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 28 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-18 |
3. Acceptance
- Every rates entity model, its generated C++ and its table are walked against the Regime 2 decision checks, with evidence for each result. Done.
- The Regime 3 projection is walked over every carrier and protocol the family reaches, including the in-process variant the family still holds. Done.
- Each finding maps to a criterion and carries file-and-line evidence. Done: thirteen findings.
- A defect is told apart from a recorded decision. Done.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Review the rates family's data model | DONE | 2026-10-18 | 2026-10-18 | Walk the Regime 2 and Regime 3 checklists over the rates family header, its product fact tables, its shared children, the generated C++ and the ORE import and export seam, and record the findings as an investigation. |
5. Decisions
6. Out of scope
- The bond and FX families' remediations, which their own stories own.
- The shared reference-data work that would turn the family's nineteen soft references into real keys. It is the component's deferral, not this family's.
- The generated service read loops: 117 of 123 files loop per key, so the fix is a codegen question and not a rates finding.
- The
equity_instrument_variant, which another environment owns.