Task: Pilot the atomised convention with tenor basis swap
Table of Contents
This page documents a task in the Atomise every convention onto the central entity story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
One central convention row, a convention_kind lookup, and two child entities for tenor basis swap. The composite flags give the parent version bump on any part write and the as-of list. The generic put writes the central row, and the generated family get and put carry the parts in one transaction.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Atomise every convention onto the central entity |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-14 |
3. Acceptance
- The convention parent and the convention_kind lookup are generated, and the ORE id is a plain stored field with no extra conditions.
- tenor_basis_swap_pay_receive and tenor_basis_swap_long_short are child entities with the composite flags, and their own audit and version.
- The family get mirrors the family put field for field, and put_many writes the batch in one transaction.
- The refdata and ORE convention suites pass, and no aggregate type or nested member remains for the kind.
4. Plan
(Implementation strategy. Written when work starts; key decisions
are distilled into the parent story's * Decisions at close, but the
plan itself stays — it is the historical record of what we did.)
5. 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 |
|---|---|---|---|
6. Notes
7. 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 |
|---|---|---|
8. PRs
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
Tenor basis swap is atomised and the pattern is proven end to end. A convention is a central row identified by party, kind and name, plus one part table per leg form, with a generated family protocol, service, handler and registrar carrying the central row and its parts in one round trip and one transaction.
The pilot also produced the codegen the pattern needs: the family model kind and its messages, service, handler and registrar; a finder taking a parent column and more than one code column; and a natural key whose column can be marked server owned, so the party arrives from the session rather than from the wire.
Four things the pilot surfaced that no build could have. The DQ publish path assumed one live table per kind, so a composite had no publish path at all. The ORE id was the real identity, hidden in a hash that two implementations had to reproduce exactly. A pair of coupon fields was modelled as belonging to one leg form when the corpus carries them on both. And the part trigger's touch function was never generated, so no part row could be written.
The remaining twenty-five kinds each get a task, one convention per PR.