Task: Populate the interest rates family

The work is smaller than the family's size suggests, because three layers are already in place.

• The routing. trade_type_routing.hpp sends ten types to rate_instrument: Swap, CrossCurrencySwap, ForwardRateAgreement, CapFloor, Swaption, FlexiSwap, BalanceGuaranteedSwap, CallableSwap, KnockOutSwap and InflationSwap. Routing decides which array a trade type may carry, so those ten can book a rate instrument today.
• The writer, service side. write_instrument_batch already writes rate_instruments, swap_legs, swap_leg_amounts and swap_leg_rates. No trading service change is needed to store a swap.
• The vocabulary. The legs draw on codes that are seeded: twelve day count fractions, seven business day conventions, nine payment frequencies, 33 benchmark rates and the currency set.

What is missing is the synthetic side: a rate payload, a planner and a writer arm. It has neither.

• D1 — the ten. They are the routed ten, and InflationSwap is among them. Booking it here as a rate-shaped swap keeps the count true and stops this task and the inflation task from both claiming it; the inflation task adds inflation_swap_instruments and the inflation market data on top.
• D2 — the leg shape. Every routed type books a rate_instruments header with two swap_legs, and each leg one swap_leg_amount and one swap_leg_rate: a fixed leg against a floating one, whatever the type. The plan originally said the specialised arrays could stay empty until a pricing need justified them, and an exporter test proved that wrong — the store rebuilds an instrument from the header and one fact row, so the writer states the fact row its trade type needs. The fields that fact row carries are the ones the type requires and no more: a settlement lag, an exercise style, a barrier, a reference security.
• D3 — the unrouted types. RateDigitalOption, SwaptionStraddle and ForwardVolatilityAgreement appear in the routing table not at all, so a request carrying any instrument array for them is refused as misrouted. Two are rate products whose option data the instrument_option arrays already hold, so routing them to rate_instrument is a table change; the third is named out of scope here, and the reason is recorded.
• D4 — CashPosition. The weights page gives it 1.5% of the class, and the catalogue holds the trade type, but no instrument table routes it and it is not a rate derivative. It is named out of scope, and the weight it carries leaves the class share this task can meet. That has to be stated rather than silently absorbed.

Each step ends in a state that can be checked on its own.

1. The payload. Add rate_terms to trade_population_plan.hpp: the currency, both legs' convention codes and economics, the notional, and the start and maturity dates. Add it to the trade_terms variant. It carries codes and numbers only, so nothing is invented downstream.
2. The scope. The plan needs the currencies and the floating indices to draw from, resolved from refdata by the caller, as commodities already are. Add them to trade_generation_scope.
3. The planner. rate_trade_planner in the registry under interest_rates, cycling the routed types over the scope's currencies and indices, and banding notional and tenor from the scope.
4. The writer. Fill rate_instruments, swap_legs, swap_leg_amounts and swap_leg_rates from rate_terms in the population writer.
5. The routing. Route RateDigitalOption and SwaptionStraddle to rate_instrument, and record ForwardVolatilityAgreement and CashPosition as out of scope with their reasons. Resolved the other way: routing alone does not make a type bookable, because a product with no fact row cannot be rebuilt for export. All three are out of scope, each with the reason stated in the Notes.
6. The profile. Give ACME's seed profile a rate population, so a provisioning run produces the family without a hand edit.
7. The proof. Run a generation, then measure: every routed type present at least once, every trade with two legs and their economics, the class share against the weight, and the export and reverse map.
8. The record. Measurements, Result, and the gaps this task cannot close.

Both were found by a provisioning run and neither by a compile.

• The leg group. The first run failed on ores_trading_swap_legs_tbl_leg_group_check: the column accepts null or the groups a credit linked swap states, and the writer stated "main". An ordinary swap leaves it null.
• The wrong catalogue. The second run failed with Invalid floating_index_type: AMERIBOR. A leg states the FpML name of an index, GBP-SONIA, and the store holds a closed set of those; the scope was loading benchmark rate names instead. It now loads the floating index types and the planner prefers the indices of the book's own currency.

The plan said the specialised fact arrays could stay empty until a pricing need justified them. That was wrong, and an exporter test caught it.

The store rebuilds a rates instrument from a header and one fact row per product: rebuild_instrument looks for the header in rate_instruments and then for a leaf in fra_instruments, vanilla_swap_instruments, or one of the seven others. A trade that states a header and legs and no leaf rebuilds nothing, and the exporter writes it as its trade type alone — no SwapData, no legs, no index. The trade books, queries and reports, and the engine would have nothing to price.

Two exporter cases now hold both sides of that. One states a header and legs and asserts the document carries no instrument; the other adds the fact row and asserts the legs and the index come out. The writer states the fact row its trade type needs, and a query over a live population counts twelve fact rows for twelve rate trades.

Its fact row states an inflation index code, and this generator has no vocabulary for one. Booking it here would have meant inventing a code the store does not hold. The inflation task owns it, and this family books the other nine.

The measured share is 27%, against a weight of 42%. That is expected and not a defect: the share is a property of the whole population, and only bonds and rates are populated. Bonds carry 32 trades because four entity configs each book eight; the two families' ratio is therefore bond-led. The share can only be measured once the other six families are populated, and rebalanced then.

ORE states each of them as its own instrument: external/ore/xsd/instruments.xsd holds SwaptionStraddleData, RateDigitalOptionData and ForwardVolatilityAgreementData, and the generated portfolio reader maps all three. This repository holds no correspondings fact row: the instrument batch has no straddle, rate digital or forward volatility array, and the database has no table for any of them.

Routing a type to rate_instrument is not enough on its own, which is what the fact row finding already showed: a trade whose product has no fact row cannot be rebuilt for export, so it would book and then fail to price. Each of the three therefore needs a table, a batch array, a writer and an export mapping — a schema feature with its own task, not a line in the routing table.

• The export, partly. Two exporter cases hold both sides: a rate trade with a header and legs and no fact row writes nothing but its trade type, and the same trade with its fact row writes SwapData, its index and its legs. A live population counts twelve fact rows for twelve rate trades. What remains unproven is the whole portfolio the ORE service gathers for a run, because no shell verb drives that path.
• The report. The shell runs no report, so the family has not been priced against its discount and forward curves. Nothing here claims it has.
• The class share. Measured at 27% against a 42% weight, which is expected while only bonds and rates are populated. It is a story-level check.