Story: A trader screen that resolves a tenor to a date, before any editing
Table of Contents
This page documents a story in Sprint 28. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
The tenor journey is built the way an administrator needs it and not the way a
trader does. A trader's question is "what date does S/N give on 16 March, on
TARGET2?" and the screen cannot answer it: it asks them to author the rule,
and it has no field for the horizon date or the calendar that resolution needs.
The prototype resolves against exactly those inputs — its own query string
carries ?cal=GB.LOIOB&horizon=2026-03-16&roll=Following&schedule=ROLL_QUARTER
— and says so in its own words: SPOT is "the spot date: horizon plus the
currency pair's spot days, rolled on its calendar" and TODAY is "the horizon
date itself". With no horizon there is no date to give.
Capture the split for later:
- Resolve, the trader's screen: pick a tenor, a horizon date and a calendar, and read the date, the anchor it counted from and the schedule it rolled on. Read-only and immediate.
- Author, the administrator's path, reached deliberately from the resolve screen: the tenor, the convention, the set it resolves, its schedules, the review and the save.
Both need one operation, and it exists now:
refdata.v1.ops.resolve_tenor answers by tenor code and convention code with
the dates and the refusal it carries, and
refdata.v1.ops.preview_tenor_resolution answers about a rule that is not
stored. The resolve page asks the first, because a trader asks about the rules
as they are. The authoring journey keeps the second, because an author asks
about the rule they are typing. This story builds the first screen only.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 28 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-18 |
3. Acceptance
- The page answers the trader's question with the four inputs resolution needs: a convention, a tenor, a calendar and a horizon.
- It shows the anchor date, the date before the roll, the adjusted date, the roll rule and the calendar, which is the whole of what the server replies.
- The tenor picker offers only the tenors the chosen convention resolves, so a pair the server cannot resolve is not offered.
- A refusal shows the server's code, its message and the field at fault, and keeps every input the person set.
- Nothing on the page writes. There is no save, no change reason and no membership row.
- The authoring journey is reachable from it, so the two modes read as one screen's two halves rather than two unrelated pages.
- The BFF route and the page are tested, the workspace suites pass, and the local gate is green.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Resolve a tenor to a date from the tenors area | DONE | 2026-10-18 | 2026-10-18 | Task for: A trader screen that resolves a tenor to a date, before any editing |
5. Decisions
5.1. Resolve is the screen, authoring is a workflow on it
The capture says the resolve screen is read constantly and written never, and that one rail serving both is what made the previous screen confusing. The area now opens on the read-only screen, and the journey that authors the rules is a workflow card on it. A trader arrives and reads a date; an administrator takes one deliberate step to change a rule.
5.2. A spot-anchored rule asks for a spot date
The capture describes spot as derived, "horizon plus the currency pair's spot days". This page has no currency pair, and the engine will not assume a lag, so it refuses instead. Deriving one here would invent a number and print a date that is quietly wrong. The page asks for the spot date and requires it only when the chosen row measures from spot.
5.3. The reply reports three dates and the page draws three
The server walks the rule and knows each schedule step. The page does not repeat that walk: a second implementation of the arithmetic would be a second source of truth for the same date. The page draws the anchor, the date before the roll and the adjusted date, which is what the operation reports.
6. Out of scope
7. Promoted from capture
Captured 2026-10-16 in the product backlog; promoted preserving the UUID.
7.1. What
The tenor journey is built the way an administrator needs it and not the way a
trader does. A trader's question is "what date does S/N give on 16 March, on
TARGET2?" and the screen cannot answer it: it asks them to author the rule,
and it has no field for the horizon date or the calendar that resolution needs.
The prototype resolves against exactly those inputs — its own query string
carries ?cal=GB.LOIOB&horizon=2026-03-16&roll=Following&schedule=ROLL_QUARTER
— and says so in its own words: SPOT is "the spot date: horizon plus the
currency pair's spot days, rolled on its calendar" and TODAY is "the horizon
date itself". With no horizon there is no date to give.
Capture the split for later:
- Resolve, the trader's screen: pick a tenor, a horizon date and a calendar, and read the date, the anchor it counted from and the schedule it rolled on. Read-only and immediate.
- Author, the administrator's path, reached deliberately from the resolve screen: the tenor, the convention, the set it resolves, its schedules, the review and the save.
Both need the operation that resolves a tenor to a date, which the server does not serve: it is Resolve a tenor over the wire, with the refusal it carries. So this waits for that task, and nothing here should be built before it.
7.2. Why
A screen that cannot answer its own question is not a screen a person reaches for. The journey as built is merged, tested and correct at what it does — it edits tenors and the conventions that resolve them — but its name promises a resolution and its rail never draws one, so a person who arrives with the trader's question leaves without an answer.
Keeping the two apart matters because they serve different people at different frequencies: the resolve screen is read constantly and written never, and the authoring path is entered rarely and deliberately. One rail serving both is what made the current screen read as confusing.
7.3. References
doc/prototypes/tenors/define-how-tenors-resolve/prototype.js— the horizon, the calendar, the roll rule and the schedule the resolution reads, and theresolvestep the built screen does not carry.- Resolve a tenor over the wire — the operation both screens need and neither has.
- Build the tenor resolution screen — the screen as built.
7.4. See also
- capture — the inbox bucket this page belongs to.