Story: Populate the ACME books with a realistic trade population — the remaining work

ACME's books hold a realistic trade population: every asset class the platform can price, in the proportions a dealing institution holds, dated relative to the day the tenant is provisioned, and referencing the parties, books, counterparties and staff the tenant already holds.

The synthetic trade generation machinery produces it. That machinery is scoped by tenant and by party and is driven by a trade generation config, so ACME is the first tenant it serves and Northwind is the next. No task in this story may name a tenant, a party, a book or a counterparty. Those arrive from the config row. The only place that names ACME is the ACME seed data.

The investigation this story commissioned is Investigation: Populating ACME with a trade population. It is the record of what was measured and which mechanism was chosen. It is a snapshot, not a description of the system.

The story closes on the tasks it finished:

• A generated date is a real date.
• A security is named by its product.
• Charter a book and a config for the commodity population.
• Construct every bond product by name.
• Draw every bond code and state its facts.
• Expose the population's size and mix in the provisioning UI.
• Factor out the shared planner loop.
• Give the system a legal entity.
• Make the trade population plan family-neutral.
• Name a bond security by its issuer.
• Populate the commodity family.
• Populate the credit family.
• Populate the equity family.
• Populate the FX family.
• Populate the inflation family.
• Populate the interest rates family.
• Populate the scripted family.
• Publish the commodity catalogue.
• Record where a trade came from.
• Trade Population Weights states a trade-count mix: interest ….
• Seed a commodity catalogue.
• Seed an inflation curve the tenant holds.
• The bond population books one product of ten.
• The population never draws the products past its slot count.

• One config row per tenant, party and asset class. The config already carries asset_class_code from the refdata catalogue: interest_rates, fx, equity, credit, commodity, inflation and bond. Coverage is therefore a row per family, and not a branch in the code.
• The plan is the seam, and not the writer. Today trade_population_plan and trade_population_slot are bond-shaped, holding security_id, issue_id, issuer_id, tenor_years, calendar and reference_curve_id, and plan_population refuses every asset class but bond. The plan must carry a payload that belongs to its family, each class must sit behind one planner interface, and one writer must execute any plan.
• The population size is an input. trades_per_book is a compile-time constant of 8 today. Move it into the config, so a tenant sizes its own population.
• The order follows Trade Population Weights: interest rates 42%, FX 25%, equity 12%, credit 6%, commodity 5%, inflation 3% and scripted 3%. Bonds are 4% and are already delivered. Commodity is the exception to the order. It lands inside the seam task, because it is the only class every declared type of which routes, so it is the only one that tests the plan alone and not also the routing work.
• Unrouted trade types are in scope per class. 30 of the 121 catalogue types route nowhere: equity 13, FX 10, interest rates 3, credit 2, bond 1 and scripted 1. The task for a class either routes its holes or names them out of scope.
• Each class states the market data it prices on. A class whose curves or surfaces are absent still books and exports, and its task says which pricing it cannot prove yet.
• A trade that must export states a header, one product fact row and its children. The store rebuilds an instrument from the header and one fact row per product, so a trade with children and no fact row books, reports and exports as its type alone — the engine has nothing to price. The interest rate family found this with an exporter test, and every later family states its fact row.
• A type ORE models as its own instrument and the store holds no fact row for is out of scope, with the reason named. Routing it to a shared table is not enough on its own: RateDigitalOption, SwaptionStraddle and ForwardVolatilityAgreement each have an ORE element and no fact row here, so each needs a table, an array, a writer and an export mapping before it can book.
• The class share is a check for the whole story, not for one task. A class's share of the population is a property of every family at once, so a family task reports the share it measured and does not inflate its own config to reach the weight.
• A generated date is a calendar date, and the day it was drawn from holds. Adding a month to the 31st states the last day of a month that has no 31st rather than spilling into the next one, because a window that ends a day after the terms the product means is a silent change of terms. The year arithmetic does the same for the 29th of February.
• The wire states absent dates one way and refuses everything else. The empty string is the absent date and reads back as the default value; a date that is neither absent nor real is refused where it is written, because a reader has no way to tell an invented date from an absent one, and a run that lost a date quietly is worse than one that stops.
• The seed states what the vocabulary states and invents none of it. An inflation curve names a <INDEX>_INFLATIONSWAP convention the tenant already holds, and states no extrapolation, because the curve.flag value set arrives empty and the guard refuses every value: a curve that states none takes the engine's default, which is a known state, where a guessed word is a refusal.
• A class's fixings are the class's own market data, and this seed is not where they come from. The curve is what a trade names; the fixing series and the seasonality factors are what the engine prices from, and the family's task states that it books without them. Recorded as the capture The seeded inflation curve states its index, its conventions and no fixings.
• A family that routes to another family's table is planned by its own planner and states that family's header. Inflation is the case: the catalogue sends InflationSwap to the rates table, so the trade is a rates header, and the asset class is still the key the registry answers a planner by, because the population a class asks for is a fact about the class and not about the table it lands in.
• A trade names an index the tenant resolves, and the resolution is the curve's own name. The population draws the ids of the tenant's InflationCurves definitions rather than a list of its own, so a trade can only name a curve that exists and a tenant that holds none books none.
• The product's index is not the leg's index. The leg column references the benchmark catalogue, so an inflation index there is refused; the product's own fact row states it, and the export reads it from the fact.
• A payoff the taxonomy has no class for gets one, in the catalogue, and not a class that stands for something else. The taxonomy is the list a config may name and the store's validator is generated from it, so a family that files itself under another class both lies about the trade and puts two planners on one class.
• A family books the codes its export can carry, and names the rest out of scope. The scripted family books three of its four routed codes because the projection writes no element for the autocallable's data; booking it would produce a trade that reports as its type and exports as nothing.
• A generated row's parameters are the document's own members. The projection writes an unrecognised key as an element the schema does not hold, so the population states the document's names and a round-trip case holds it to them.
• The population's total is not a free choice: it is the smallest number where every class can be its weight and keep one trade per routed code. A class's count cannot fall below its code count, and its share cannot fall below that floor, so the class with the worst floor-to-weight ratio sets the total. At a thousand trades every class states its weight exactly; at a hundred and ninety commodity was twice its weight and rates a third of it.
• The population's size and mix are profile parameters, not a screen's own form. The provisioning form renders every parameter a profile declares, so a knob the profile declares costs no screen code and the arithmetic has one home on the server. A run that states no size keeps the seeded counts; one that states a size and no mix keeps the seeded mix.
• Closed on 2026-11-08 at sprint 29 close with its done tasks. The open tasks and the original acceptance moved to Populate the ACME books with a realistic trade population — the remaining work.

ACME's books hold a realistic population, and an operator can size it.

Every class the refdata taxonomy states has a planner, and a fresh tenant holds a thousand trades: interest rates 420, FX 250, equity 120, credit 60, commodity 50, bonds 40, inflation 30 and scripted 30 — the weights page's own mix, exactly, with every routed code appearing between two and sixteen times. The population exports as the ORE portfolio, and each family's round trip is proved in the ORE suite.

Four things the arc settled, and one it exposed:

• A class's count cannot fall below the codes its planner cycles, and its share cannot fall below that floor, so the total is the smallest number where every class fits both. At 190 commodity was twice its weight; at 1000 every class is its weight exactly.
• A payoff the taxonomy cannot classify gets a class in the taxonomy, not a class that stands for something else.
• A family books the codes its export can carry and names the rest out of scope.
• The population's size and mix are profile parameters, so the provisioning form states them and one place computes what they mean.

What it exposed and did not fix here: the seeded inflation curve states no fixings, so an inflation swap books and exports and cannot price. That is the capture The seeded inflation curve states its index, its conventions and no fixings, and it belongs to the market-data surface rather than to this story.

• Intraday reports. They belong to the report inputs story.
• Draft reasons, structure holds and structure completion. They belong to the Trade Blotter.

• Split from Populate the ACME books with a realistic trade population on 2026-10-24 at sprint 28 close. The done tasks of that story are recorded there.