Task: Tick-batch publishing and persistence for curve instruments

A proper swap par rate needs its fixed-leg payment schedule (a strip of periodic discount factors), not just its two endpoints — treating a Swap entry as a single-period deposit-equivalent (an early draft of this plan) was rejected as defeating the purpose of modelling a swap at all. This requires:

• A genuine, catalog-driven classification of "how do I price this instrument against a curve" (deposit / fra / swap), rather than inferring it from start_tenor_code = "SPOT"= (Deposit and Swap are both point instruments but need different formulas).
• A payment frequency for the swap's fixed leg, to build its intermediate payment dates between spot and maturity.

The payment_frequency consolidation described above is implemented:

• New ores.refdata.payment_frequency entity (full codegen facet set: API/core/service/Qt/SQL), seeded with the 9 canonical rows, badge on period_unit reusing tenor_unit's existing badge domain, DQ publish-from-dq wired.
• ores.trading.payment_frequency_type deleted entirely: modeling .org, all generated API/core C++, Qt list/detail/history dialogs + menu wiring, CLI entity registration, and its ores.trading.module.org catalog row.
• All four ores.trading consumer columns (swap_leg=/=credit_instrument=/=commodity_instrument=/=equity_swap_instrument) repointed to validate against the new entity, including the three that previously had no FK validation at all.
• Schema validated clean (253 tables, 0 warnings) after db recreate.

The producer side splits into two independent concerns, not one task:

• Phase 1 (this task's actual scope): the family feed. One ir_curve_feed, mirroring fx_spot_feed, where one short-rate process step fans out to N curve_instrument_pricer calls (one per ir_curve_template_entry) and publishes N ticks synchronously, sharing one observation_datetime – exactly this task's original Acceptance.
• Phase 2 (not this task): per-point disaggregation/staggered timing. Making each tenor in a family tick independently, at its own arrival time, rather than all N points landing together. This is not IR-specific: it is the same concern as the existing BACKLOG story Stochastic tick arrival times for synthetic feeds, whose arrival_profile_config abstraction is designed to wrap any feed. Applying it per point_id instead of per source for curve feeds is that story's future work, not a bespoke IR disaggregator – so Phase 1 does not need to anticipate any special interface for it. No task filed here for Phase 2; tracked via the link to that story instead.

The family feed publishes on its own namespace, synthetic.v1.curve_family.<source>, distinct from the plain-tick namespace synthetic.v1.tick.<source> scalar feeds already use – still N individual NATS messages (not one aggregate payload), so ingest stays a dumb per-message consumer. When Phase 2 eventually lands, the disaggregation adapter would subscribe to curve_family.* and republish onto tick.*, so from ingest's point of view a disaggregated IR point looks identical to any other tick (already carries point_id) – no ingest-side special-casing needed either now or later. A consumer wanting the raw family (e.g. a future bootstrap-testing consumer) subscribes to curve_family.*; a consumer simulating live market consumption subscribes to tick.*. This is a producer/subject-routing decision, not a per-config "family vs individual" toggle.

Considered and rejected: publishing one large JSON object containing the whole curve per generation step, so a UI could "open it up and plot the curves" directly. Rejected because market_observation is already row-per-point (series_id, observation_datetime, point_id) – the same shape non-scalar series (vol surfaces) already use – and an aggregate wire object would either force ingest to explode it back into rows anyway, or require a new non-relational storage shape outside this story's scope. It would also break Phase 2 cleanly, which needs to peel off individual points to re-time them independently – an aggregate object is strictly worse for that than row-per-tick. "Open it up and plot it" is a read/query-side concern instead – see the new curve-snapshot-builder-viewer task.

Raised: since a tick batch's points may one day be published at staggered times (Phase 2), how does a consumer know which points belong to the same coherent draw, if not by matching observation_datetime? Considered adding a generation_id=/ =batch_id column to market_observation, stamped once per process draw and carried by every point derived from it, so grouping survives staggered publish times.

Rejected after checking how this actually works in the real world (no vendor feed exists in this codebase to check against – ores.bloomberg is an unstarted BACKLOG story – so checked the market data protocols instead):

• FIX MarketDataSnapshotFullRefresh (W): always one instrument per message, even when a single MDReqID groups a request for many instruments – responses are still separate messages per instrument. No message-level construct ties multiple instruments' data together as one coherent unit.
• Refinitiv/LSEG RIC records: each instrument (e.g. USSW10Y= for a 10Y swap rate) is its own independent real-time record, ticking on its own schedule. A "curve" is not a wire-level object at all – it is many independently-updating RICs a downstream consumer groups by naming convention.

Conclusion: no batch/generation identifier exists in real market data feeds, and none is added here either. Vendor feeds never assert "these N points are mutually consistent, published together" – a curve is reconstructed downstream, by taking the latest tick <= an as-of time independently per point. Adding a synthetic-only batch_id would have been exactly the kind of source-specific extension the architecture (see Market Data Architecture) is meant to avoid. The correct pattern is a read-side as-of query – SELECT DISTINCT ON (point_id) ... WHERE series_id = ? AND observation_datetime < ? ORDER BY point_id, observation_datetime DESC= – which degenerates correctly to "all points share one timestamp" in this task's Phase-1 synchronous-publish case, and keeps working unmodified once Phase 2 staggers publish times. No schema change. Tracked as its own task: curve-snapshot-builder-viewer.

1. Add folder_id to ir_curve_generation_config (org spec + regenerate: SQL table, C++ domain struct, repository, JSON I/O), mirroring fx_spot_generation_config.
2. Update synthetic_publish_from_dq_create.sql's IR insert to store the v_folder_id it already computes but currently discards.
3. Rewrite buildTree() to fold IR curves into the same generic folder walk as FX (now that folder_id exists) instead of the separate flat-group special case – one tree-building path for both asset classes, extensible to future asset classes without a new parallel branch each time.
4. Fix the flag icon in buildIrCurveFeedItem() to the single-flag overload.
5. Add IR curve summary/hero support: extend showSummaryForCurrent()'s Feed case to check irCurves_ too, add showIrCurveSummary() (single-flag hero, reusing the existing tick chart subscription machinery keyed by irCurveSourceName()).
6. Build, restart services/client with --open-scenario, re-verify live in Market Simulator.

Confirmed live: folder_id regenerated across all codegen layers (SQL/domain/repository/JSON I/O), synthetic_publish_from_dq_create.sql now stores the v_folder_id it resolves, and after a DB recreate + Barclays re-provision the IR curve configs' folder_id correctly points at the real Root -> Realistic -> Rates -> "IR Curves" folder (ba1e1e67-...) – queried directly, not guessed. buildTree() now folds IR curves into the same folder walk as FX (irCurvesByFolder=/=pairsByFolder are structurally identical). Flag icon fixed to the single-currency overload. Naming uses idiomatic rates convention (space-separated, e.g. "USD SOFR"), not FX's slash-separated pair notation.

Confirmed reusable without duplication (checked, not assumed):

• ores.synthetic.api/domain/curve_template_validation.hpp/.cpp (validate_curve_template) is a pure function in the api layer (linked into Qt already via domain structs) – the tenor-overlap check can run client-side in the Curve Template tab exactly as written, no server round-trip needed for that part.
• yield_curve_process_type, ores.refdata.instrument_code, ores.refdata.payment_frequency, ores.refdata.tenor all have full protocol/repository codegen already – every combo box in the wireframe below is backed by an existing request, none new.
• curve_instrument_pricer (ores.analytics.quant) and IYieldCurveProcess::discount_factor() are service-layer only – confirmed Qt has no dependency on ores.analytics.quant or ores.synthetic.service, so the curve-shape chart genuinely needs a new preview request, not a missed existing one.

┌─ IR Curve: USD SOFR ──────────────────────────────────────── [Save] [Cancel] ┐
│ [Instrument] [Process] [Curve Template] [Provenance]                         │
├────────────────────────────────────────────────────────────────────────────┤
│ INSTRUMENT TAB                                                               │
│  Currency:        [USD        ▼]      Index Name: [SOFR________]            │
│  Fixed leg freq:   [Annual     ▼]      Enabled:    [x]                      │
│  New tick every:  [1____] sec   (from ticks_per_hour)                       │
│  Source:  ir_curve.usd.sofr   (read-only, derived)                          │
└────────────────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────────────┤
│ PROCESS TAB                                                                  │
│  Engine: (•) Vasicek  ( ) CIR  ( ) Hull-White                               │
│                                                                                │
│  Initial rate r0  [====|=========] 3.25 %                                   │
│  Mean level  θ    [======|=======] 3.50 %                                   │
│  Reversion   κ    [===|==========] half-life ≈ 45 days   (log-scale slider) │
│  Volatility  σ    [==|===========] 0.80 %                                   │
│                                                                                │
│  ┌─ Sample short-rate paths (5 draws) ──────┐ ┌─ Curve shape preview ──────┐ │
│  │      ╱‾╲___                              │ │  rate                      │ │
│  │  ___╱    ╲___╱‾╲___                      │ │   │      ╱‾‾‾‾             │ │
│  │ ╱                  ╲___                  │ │   │   ╱‾╱                  │ │
│  │______________________________  ticks     │ │   │__╱____________ tenor   │ │
│  └───────────────────────────────────────────┘ └─────────────────────────────┘│
└────────────────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────────────┤
│ CURVE TEMPLATE TAB                                                           │
│  # │ Start Tenor │ End Tenor │ Instrument         │                        │
│  0 │ SPOT        │ 1M        │ Deposit         ▼  │  [↑][↓][Remove]        │
│  1 │ SPOT        │ 3M        │ Deposit         ▼  │  [↑][↓][Remove]        │
│  2 │ 3M          │ 6M        │ ForwardRateAgree ▼ │  [↑][↓][Remove]        │
│  3 │ SPOT        │ 2Y        │ Swap            ▼  │  [↑][↓][Remove]        │
│                                                     [+ Add tenor entry]      │
│  ⚠ warning banner here if tenor windows overlap (validate_curve_template)   │
└────────────────────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────────────────────┤
│ PROVENANCE TAB — shared DetailDialogBase widget, same as every other entity │
└────────────────────────────────────────────────────────────────────────────┘

1. Simple/Advanced toggle: FX uses two checkable/auto-exclusive QPushButton's, explicitly QSS-styled into a joined accent-colour pill (min-height: 30px, bold, filled when checked), placed at the right end of the header row. The shipped editor used two plain QRadioButton's with no styling, which is why it read as "no toggle button at all". Decision: copy FX verbatim – no IR reason for this affordance to look different.
2. Simple-mode sliders: FX has no spinbox beside the slider – a title + gray value-echo label sits above a full-width slider; precise entry is Advanced-only. The shipped editor paired every slider with an adjacent spinbox in Simple mode. Decision: copy FX – drop the paired spinbox, echo the value in a label instead; Advanced's table remains the only precise-entry surface.
3. Three-zone tab layout: FX is header row (engine + frequency + toggle) / middle row (controls left + compact chart right, capped ~380px) / bottom row (prominent full-width chart in its own titled QGroupBox). The shipped editor stacked both charts full-width below the controls – no side-by-side zone at all. Decision: copy FX's structure, but invert which chart is compact vs prominent – FX's compact side chart is the supporting stat (return distribution), prominent bottom chart is the hero view (sample paths). For IR the priority is reversed: curve shape is the "what will I actually publish" hero view (curve shape is a genuine IR-only chart FX has no equivalent of), sample paths is the supporting/exploratory view. So: middle row = controls + compact sample-paths; bottom row = prominent full-width curve-shape. Same structural pattern, content assignment flipped for a stated reason.
4. Currency combo: FX's baseCombo_=/=quoteCombo_ are editable with a QCompleter (PopupCompletion, MatchContains, case-insensitive) over the typed OreCurrencyComboBox class. The shipped editor used a plain non-editable QComboBox. Decision: copy FX – same ~180-row ISO currency list, same "pick 1 of many quickly" use case, no IR reason to make this worse.
5. Index name combo: Decision: deliberately not like FX's currency combos – post-filter (currency-scoped, two-segment codes only) this list is typically 1-3 items, not ~180; a completer would solve a problem that doesn't exist here. Stays a plain non-editable combo.
6. Fixed-leg-frequency / engine combos: short fixed enumerations (9 and 3 rows) – matches the codegen "standard" (Portfolio's purposeTypeCombo=/=statusCombo, also plain non-editable, no completer anywhere in the codebase for combos this short). No change – already correct.
7. Instrument tab framing: every codegen .ui dialog (Portfolio, Book) wraps its QFormLayout fields in a titled QGroupBox (e.g. "Basic Information"); the shipped editor put the form directly on the tab with no framing. Decision: add one ("Curve Identity").
8. insertPolicy: every codegen .ui combo explicitly declares QComboBox::NoInsert; the shipped editor never sets it (functionally inert since none are editable except the currency combo post-item-4, but cheap to match literally). Decision: set it explicitly.
9. Curve Template table combos: already the only precedent in the codebase for inline table-cell combos (FX's component table); already matches it. No change.