Story: Make every configuration screen follow one standard — the remaining work
Table of Contents
This page documents a story in Sprint 30, carried unfinished from Sprint 29 at close. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
One screen standard covers every configuration that comes off an ORE XML document: the same list, the same record page, the same sections, the same documentation, the same reach, the same history, the same import and the same lifecycle. A person who learns one configuration screen knows them all.
Two configurations carry the word "engine" and a person confuses them today. The standard gives each one a name that says what it decides, and every page says what the configuration is and which other configurations the same report binds.
2. Status
| Field | Value |
|---|---|
| State | BACKLOG |
| Parent sprint | Sprint 30 |
| Now | Not yet started. Split from Make every configuration screen follow one standard, which closed in sprint 29 with its done tasks. |
| Waiting on | Nothing. |
| Next | Triage into a sprint. |
| Last touched | 2026-11-08 |
3. Acceptance
- One knowledge page states the standard for every configuration screen, and the UX hub and the screen review checklist point to it.
- The screen words are fixed for every configuration kind, and no two kinds share a head noun.
- Every configuration page says what it decides and lists the other configurations the same report binds.
- The engine run settings keep the pattern they set, and the pricing engine configuration follows it.
- A change that alters the numbers a run computes goes through a proposal and a sign-off, whichever kind it is.
- The two configuration prototypes follow the standard and the owner signs them off before any code change.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Carry provenance on every parameter | BACKLOG | Add source, source reference, curation note and review fields to the ore parameter contract, and make the generator fail on a row without them or without a text. | ||
| Carry the methodology and coverage on the DQ dataset | BACKLOG | Record on the pricing DQ dataset: the ORE source commit, the curation file version, the methodology link, and the coverage counts (types mapped, exempt, settings and globals documented, rows authored). The generator writes them and the publication carries them, so a consumer reads coverage without running the generator. | ||
| Drive the screen labels, controls and tabs from data | BACKLOG | Read asset class names from refdata, map a value domain to a control through a registry, and carry the section and tab metadata instead of hard-coding them in the page. | ||
| Map every product type to its instrument | BACKLOG | Fill instrument_type_code from the guide's used_by for the added types, decide whether a cross-currency product maps to SWPTN or XCCY, and record the decision. | ||
| Reclassify the leg, coupon and pricer entries | BACKLOG | Decide whether the leg, coupon, cashflow and pricer subsections belong in the pricing engine types or in a separate catalogue, and move them. |
5. Decisions
- Split from Make every configuration screen follow one standard on 2026-11-08 at sprint 29 close. The acceptance above is copied from that story; its done tasks are recorded there.
6. Out of scope
- Renaming a table, a configuration type code or an API route. The screen words change; the model does not.
- Changing the pricing engine model. The analysis found six live
Setupchoices that the model does not hold; whether to add them is an open question in the investigation.