Task: Populate the inflation family

ACME's books hold inflation-linked trades. The refdata asset class names inflation, but the trade type catalogue carries exactly one inflation code, InflationSwap, and it routes to rate_instrument under the swap product type. The planner therefore selects by trade type and not by product type, and the class carries 3% of the population.

• The mapping from the inflation asset class to its trade types is declared, because the catalogue has no inflation product type.
• InflationSwap books a trade, and the index the trade names is one the tenant holds fixings for.
• The class share of the population matches its weight within tolerance.
• The family exports as the ORE portfolio the engine reads, and reverse-maps without loss.
• The report that prices the family runs against the inflation fixing curve and its seasonality, or the task states which pricing it cannot prove yet.

Route the one code, and state the rows the store's own writer already reads.

The catalogue sends InflationSwap to the rates family's table, so the trade is a rates header plus the product's own fact row, and the planner draws the code the router sends it. The family is planned by its own planner because the asset class is inflation and the class is the key the registry answers a planner by; the rate planner carries the nine other codes and does not draw this one.

The index is the tenant's own curve name. A curve definition in the InflationCurves section states its index in its curve id, so the population reads the definitions and draws from the ids, the way it draws a currency pair from the tenant's catalogue. A scope that names no curve refuses.

The swap states a fixed side and a CPI side. The CPI side's type is what the ORE projection reads the index, its base level and its lag from, so the trade exports as the InflationSwap element the engine prices. One thing the CPI leg must not state: its own index column. That column references the benchmark catalogue every floating leg names, and an inflation index is not a member of it — the store refused the row. The index is the product's own fact and the export reads it there.

ACME charters a sterling inflation book and one config for it. The family routes one code, so the config's slot count is its trade count.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

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

The inflation family books, and the tenant's books hold inflation swaps that name the curves the seed published.

Measured on a fresh tenant:

• Six inflation swaps over three indices, two on each, with a base level and a three month lag. The population is 184 trades, so the class is 3.3 per cent of it against the weight's three.
• Each swap is a rates header and the product's own fact row, with a fixed side and a CPI side, which is the shape the ORE projection reads back as an InflationSwap element.
• The provisioning run completes all nine steps.

Three things surfaced on the way and are fixed here rather than worked around:

• The tenant's curve.inflation_type value set holds ZC and YY, the codes the ORE document states, and the seed stated ZeroInflation. It got away with the invented spelling while the value set arrived empty; it is refused now that the set is populated, and it stopped the run in curve publication.
• The CPI leg cannot state the index in the leg's own index column: that column is the soft reference to the benchmark catalogue, and the store refuses an inflation index there. The index is the product's fact and the export reads it from the fact.
• A convertible security's conversion target was drawn from the trade's slot, so two trades of one security stated two targets and the store refused the second issue write. The target now comes from the security's name.

Two desks the configs name had also gone from the seeder's tree — equity and commodity — so every provisioning run stopped at the first config whose book no entity held. Both are restored, unstaffed, and the gap that let them go is captured as A seed profile's generate_trades config names a book by name, and nothing checks that name against the tree.