Story: Clean ores.trading to the component clean standard

check_component_drift.py --component trading-cpp --dry-run reports 1636 files that would change and 115 that would be created, 1751 in total. Every block was classified by cause:

The evidence file groups the banner and the root CMakeLists.txt into one bucket and reports 1435 marker-only files; the table above splits them. The two views are the same 1636 changes.

The 123 substantive changes are the 114 database scripts under ores.sql/create/trading/ plus the trade protocol, handler, registrar, repository and service. The 114 are the trigger and notify-trigger templates: the write-path version rule and the canonical change payload.

The 115 creates are 57 event headers, 9 per-family instrument protocols, 9 handler headers, 9 registrar headers, 9 registrar sources and 22 shell recipes.

The conclusion that matters: the generator already reproduces the tree for the modelled families apart from the banner. The sprint 25 design predicted that a regeneration would "flatten and drop tree semantics". That is no longer true. The bond pilot, the regenerable trade entity and later template work removed the semantic gap, and what remains is stale template output.

ctest -R "ores.trading.core.tests" reports 102 cases, 81 pass and 21 fail. ores.trading.api.tests and ores.trading.service.tests pass. All 21 failures are *_publishes_nats_changed_event cases in the eventing integration tests. The cause is already captured at Finish the eventing payload migration: 123 of the repository's 209 notify triggers emit {entity, timestamp, entity_ids, tenant_id}, the reader in postgres_event_source.cpp requires {event_id, entity, key, action, version, occurred_at, tenant_id}, the parse fails and the notification is dropped. Trading owns 114 of those trigger files, which is why its share of the drift includes them and why its suite fails.

Story Redesign ores.trading on data-oriented principles, ABANDONED 2026-09-23. Its design doc/agile/versions/v0/sprint_25/data-oriented-trading-model/design_trading_data_oriented_model.org scored the component 2 of 5 on the persisted-data regime and 2 of 5 on the wire regime, and named 13 findings. Its September 8 regeneration oracle produced 47 modified and 65 untracked files; the same check today produces 1751, but 88 per cent of the 1636 changes are the banner.

Landed: the bond relational family, a regenerable trade entity with five field groups and org-declared foreign keys, insert trigger and indexes (2478b1f879), its generated service layer (30a7cfbb2f), the generated-file marker (e7e9491467), the product identity document (e1ef999975, PR #2085), the untagged-variant fix, and the ORE import, export and round-trip shell verbs.

Abandoned and still open: 7B23DB0F collapse the instrument identity into the trade, 0C525D24 split the bond security from the trade, A3DA0BB5 keep stated but default-valued elements in the export, F628C22E product short code, 27FC1760 retire the rfl complexity flags. Two more, 3E14AEC0 and 5A01EEBC, are moot because the whole ores.qt tree was deleted at af67db3062.

The design question is already answered in the repository. doc/knowledge/architecture/trade_modeling.org, lines 152 to 166, states that the economics vary by product type, that they belong to one agreement, and then:

The relationship between trade and instrument is therefore one to one, and the trade id identifies both.

doc/knowledge/domain/trade.org repeats it: a trade is four entities, the product type, the security issue where one exists, the trade and the instrument carrying the economic terms.

The code carries three identities instead of two:

• instrument_identity_field_group.org declares instrument_id as a key and trade_id as an optional soft back-reference. Twenty-six models inherit the group.
• ores.trading.trade.org adds instrument_id to the trade, and trading_trades_create.sql declares it uuid null.
• The declaration carries 91 instrument_id columns, and no foreign key anywhere targets an instrument table. Two nullable pointers face each other and nothing can make them agree.
• There is no instrument table at all. The apparent instrument entity is type glue: a concept, an alias and a nine-alternative variant.

Two smaller defects sit on the same ground. trade_classification.hpp documents instrument_id as a soft foreign key to ores_refdata_instruments_tbl, which does not exist. That file also cites trade_identity_field_group.json, which does not exist either.

The independent investigation doc/agile/versions/v0/sprint_25/ore_trade_generator_trade_populations/trade_model_defects.org reaches the same place from the persistence side, as its defect 13: twenty-five instrument tables are keyed on instrument_id and five are keyed on id, together with trades, swap_legs, composite_legs, trade_identifiers and party_roles.

So 7B23DB0F and 0C525D24 are not an open design question. They are the implementation of a decision the knowledge base already records, and the abandoned split task left the reason to do the collapse first: doing the security split first reshapes the same tables twice.

The pilot proved its claim for the bond products and the trade envelope. The zero-loss gate read 0 lost and 0 unexplained over 1566 documents. The mapper is a hand-written 1694-line bond_instrument_mapper.cpp over a hand-written container of 241 and 425 lines. Forty-seven cases in six ores.ore test files cover it, plus eleven cases in service_bond_instrument_reader_tests.cpp.

What silently stopped, with no task and no decision recorded:

• The design's instrument_underlyings table was never built.
• bond_legs and its rate, amount and amortization children are still keyed by instrument_id, so bond static data is stored once per trade rather than once per security.
• No REFERENCES constraint exists in any bond script, so the design's foreign key for issue_id is a comment rather than a constraint.
• Eight bondData elements still have no column: CreditGroup, VolatilityCurveId, PriceQuoteMethod, PriceQuoteBaseValue, PriceType, Payer, CreditRisk and SubType.
• bond_futures is a pre-v17 table with 15 columns while the current instruments.xsd declares 5 members. ApplyConversionFactor and UseFuturePrice have nowhere to go. The zero-loss gate cannot see this because no ORE example contains a bond future.
• The corpus-wide sweep over the roughly 50 bond documents never ran. Two documents were checked live.
• Deleting a bond instrument over the shell removes the header row and leaves the facts and the issue behind.
• Adding a bond is three saves with no transaction.
• Default-valued but stated elements are still dropped on export.

trade_model_defects.org records sixteen defects found by loading every table rather than by reading the model. The story that would have consumed it, trading_model_cleanup, was scaffolded on the unmerged branch feature/trading-model-cleanup and never landed. The defects belong to this story:

Checked 2026-09-26. No worktree is working on ores.trading. The open pull requests are clean-marketdata, workflow-identity, clean-iam, clean-variability and clean-service. One remote branch touches trading, origin/feature/trading-model-cleanup, and it holds a single unmerged commit from 2026-09-08 that scaffolds the sprint 25 trading_model_cleanup story. This story supersedes it. The branch is not ours, so the PR 1 task records it rather than deletes it.

The backlog captures that touch this work are listed in the PR 1 task.