Task: Analyse how a trade states its size
Table of Contents
This page documents a task in the Trade Blotter — the remaining work story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
Decide what the composition screens state about size, and on what rule, from the fact that a bond, a rate leg and an FX trade state size in three different ways.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Trade Blotter — the remaining work |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-11-01 |
3. Acceptance
- Every family that holds a size is named, with the table it lives in and what the number means.
- The composition screens state either a family's own fact or nothing, and never a column of dashes.
- A recommendation is recorded: whether a composition screen is about what is grouped or about exposure.
4. Plan
The question is answered from the store rather than from opinion: every column in the trading schema whose name says it is a size, grouped by the shape it takes. The screens are then read against that list, and the one place that draws a size unconditionally is fixed.
The scope was deliberately narrow. The alternative — deciding what a composition screen is for and rebuilding it around an exposure number — is a design of its own, and this task exists to settle the fact that a size is not one fact.
5. Measurements
The list below is information_schema, not a reading of the models: the store is
what a screen can state.
6. Measurements
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.
| What | Value | Command | Commit |
|---|---|---|---|
| The families with a size column | 47 columns across 30 trading tables, in four shapes | compass db sql -- -c "select table_name, column_name from information_schema.columns where table_name like 'ores_trading_%' and (column_name like '%notional%' or column_name like '%amount%' or column_name like '%face_value%')" |
this branch |
| A rate leg states no notional | the leg carries payer, index, currency and day count, and the amount is a schedule in ores_trading_swap_leg_amounts_tbl |
compass db sql -- -c "select column_name from information_schema.columns where table_name'ores_trading_swap_legs_tbl'"= |
this branch |
7. Notes
The question was raised by the structure screens: they drew a notional column because the prototype draws one, and the column stated a bond's convention for every family. The capture that holds the case for each family's own fact is What is a trade's size across asset classes?.
8. Test Scenarios
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.
| Scenario | State | Notes |
|---|---|---|
9. PRs
10. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
11. Result
There is no such thing as the size of a trade. The store states four shapes, and only one of them is a number a column can hold.
| Shape | Families | Where it lives | What the number means |
|---|---|---|---|
| One money amount | bond, FRA, equity notional products, bond future (as contract_notional), FX variance swap |
the instrument table's notional |
the amount the deal is struck on, in the trade's currency |
| Two amounts in two currencies | FX forward, FX vanilla option, FX barrier option | bought_amount and sold_amount |
what is bought and what is sold; neither is the deal's size alone |
| A quantity | commodity, equity forward, equity position | quantity |
units of the underlying, not money |
| A schedule | rate swaps and every amortising family | ores_trading_swap_leg_amounts_tbl (amount per leg per start_date), ores_trading_flexi_swap_lower_notionals_tbl, ores_trading_bg_swap_tranche_notionals_tbl |
the amount in force over a period; there is no single figure, and a bond's face_value is its convention rather than its size |
A structure makes this worse rather than better: its legs are trades of different families, so a structure's size would be a sum across a notional, a quantity and a schedule, in more than one currency.
12. Recommendation
A composition screen is about what is grouped, not about exposure. It states the legs, their roles, their families and their currencies, and the number of legs. It does not state a total, because a total across those shapes is not a number; exposure is valuation's question, which is Value a trade against a market snapshot.
Where a screen states one trade's own fact, it states that family's fact: the notional where the family has one, bought and sold where it has two, the quantity where it counts units, and nothing where the family holds a schedule.
13. What changed
The trade page drew "Notional" for every family, which is a dash for a swap, an FX trade and a commodity. It now states the family's own fact: the notional, the bought and sold amounts, or the quantity, and nothing where the family states a schedule.
14. What is left
Nothing in the composition screens draws a total today, so there is nothing to remove. A future screen that wants an exposure number should read this task's recommendation first.