Curve blueprints prototype

The Qt app has the bootstrapping screens and the web has none. The workflows exist: the CurveBuilderWorkbench defines a recipe, builds it and publishes it from three tabs of one window, and the IrCurveBootstrapConfigController opens it. What the web has no answer for is the shape. The Record screen standard gives a record a list, a record page, tabs, dialogs and states; the Qt window is none of those, and copying it would put a desktop apparatus in front of a web session.

So the question this prototype answers is: does the bootstrapping job read as a record screen, with the same parts as every other record kind, and which of the Qt window's parts does it need?

The answer it draws is five tabs: the recipe, its pillars, its check, the sets it fed, and its history. The Qt window's three tabs map onto the first three; the last two are the record standard's.

Switch with the bottom bar, or with the query string.

The tab is in the address, so a link reopens the page where it was left: ?tab=check, ?tab=sets, ?tab=history.

The list follows the record standard: the breadcrumb Home › Market data › Curve blueprints, the plural as the title, one sentence, a search, two filters, the table and the pager.

Two filters stand beside the search: a currency select and a role select. The search covers the name, the currency and the output series. A row opens the record page.

RS-LIST-21 gives the list its states, and the prototype draws each one:

• No records. "There are no curve blueprints yet." It says what a blueprint is, and offers Add.
• Nothing matches. "No curve blueprints match the search." and a way to clear it.
• First load. "Loading…" in the body of the table.
• Error. The words of the server and Retry, and never a modal box.
• After a delete. One success notice, and the list without the row.

Two facts of the model shape the table. The blueprint has a name – a required column the record carries, such as USD-SOFR-ACME – so the list draws it and nothing parses the output series' oresmd URI for one. And the key is a UUID that RS-LIST-13 keeps out of a table, so the name is the readable handle the list has: the name is what a person searches by, sorts by and opens a row with.

The header carries the record's name as its title and in the breadcrumb, the lead line <currency> · index tenor <tenor> · <role> · version <n> and the access mark, and three actions: Copy blueprint, then Edit, then Delete. Copy is the kind's own action, in the place RS-PAGE-03 gives one, and it is the whole of the Qt window's New from Existing… button.

The tabs are Details, Pillars, Check, Published sets and History, in the standard's order: the record's fields, then a part, then the kind's own view, then a related plural, then the timeline.

• Details. The fields in the field table's order: name, currency, index tenor, role, discount curve, interpolation method, day count, tenor convention, split tenor, output series and Used by. The name is the first fact, because it is what the record is. A value that names another record is a link: the discount curve opens that blueprint, the output series is the market series' URI and opens the series, and Used by lists the projection blueprints that discount off this one, each by its name. A funding blueprint has no discount curve, and the field draws a dash. The tab ends with the last-changed line. A blueprint with no pillars says so in a notice that opens the Pillars tab. A blueprint whose sets have all ended says so in a notice that names the withdrawal and the account that took it.
• Pillars. The parts panel of RS-RELATED-04 to RS-RELATED-06: one row per pillar in maturity order, with the sequence, the start and end tenor, the curve role, the version, who changed it and when, and History, Edit and Delete on the row. Add stands beside the panel's title. The panel's one paragraph says what a pillar is, because the Qt window's paragraph is the only teaching either screen has, and that the order follows the end tenor rather than the order typed.
• Check. The recipe's own checks, what the market supplies, the points, two charts and the findings. It has a section of its own below.
• Published sets. The sets published from this blueprint, newest first: the published as-of, the party, the publisher, the published instant, the points and the state. A row opens the published record. A blueprint nobody published from says "None yet." and names the publish journey. The sets are read and never changed here: a withdrawal is its own act with a reason.
• History. The shared timeline, as the record standard states it: the blueprint's versions and every pillar's versions, newest first, each entry named by its part, with the field-level difference behind Details, the current version marked, and Revert on the older ones.

The tab carries the as-of, then the checks, then what the market supplied, then the points and the two lines, then the findings.

A recipe that fails its own check stops before the market is read: the tab says so, names every failed check, and draws no points. That is the validation failure state. A recipe that passes but whose market has no rate for one pillar still builds, and the points table draws a muted dash for the gap, the chart breaks its line, and one finding names the gap.

The tab never shows an unrun check as passed. Before the test it says Not run on every check and Not checked yet above them.

The record dialog is the standard's: one dialog, no tabs, two columns, the fields in the field table's order, the label above the control, one line of small faint text under a value that needs it, Cancel and the primary button in the footer.

The name is asked first and is required: it is typed, and no control derives it.

One field the Qt window draws is absent, on purpose. Source series is not asked at all: the config names no input series, and each pillar reads the series its own tenor, role and index resolve to, so its picker is not needed.

Output series is asked, and the note was reversed on 2026-10-28 when the screen was built. The draft drew it as a value that follows from the currency, the index tenor and the role, so that the server could mint it and the dialog would not ask (RS-WRITE-07). It does not follow: a curve's oresmd URI carries the index name (DISCOUNT/RATE/USD/USD-SOFR-FOMC), and the config holds the currency and the index tenor and not the index, so no operation can compose the identity the record is keyed by. The field is therefore a record picker over the series the party holds, it is required, and it is the record's natural key, so one series names one blueprint and a copy names another.

The series is not the name, and the screen never makes one from the other. The record carries the name a person typed, in a column of its own; the series is the URI the curve is published into, which Details draws and no title uses.

The pillar dialog asks for three fields: the start tenor, the end tenor and the curve role, each a select over the codes the system keeps, and says that the sequence follows the end tenor. The copy dialog is the record dialog with the conventions and the pillar count carried over and the name, the output series, the currency, the index tenor and the role blank, because those are what make it another curve. The delete dialog says what is lost, and refuses in the server's own words when a projection names the blueprint as its discount curve.

A coded value is drawn one way and only one way, as the application's CodedValue does it: a pill in the label catalogue's own shape and colours when the catalogue paints the code, and the code itself when it does not. The prototype carries one renderer for that, coded(domain, code), and every coded value on the page goes through it. The pill is the app's Label: a filled pill, 11 pixels, the badge's background and text colour, the badge's own name inside it, and the badge's description on hover. The screen never builds a pill of its own, and it never paints a value the catalogue does not paint.

Six domains are proposed, and the note states them as proposals and not as fact: the seed holds no entry for any of the six. Until it does, the product screen draws the same codes plain, exactly as CodedValue does for a field the catalogue has not painted. The proposal is what the catalogue needs, and it is one row for each code:

The colours are the palette's own, not new ones: #22c55e is the catalogue's success, #3b82f6 its info, #7c3aed its primary, #14b8a6 and #0ea5e9 its other informational tones, #6b7280 its secondary, and #ef4444 its danger. One domain carries one colour except the curve family role, whose two codes are painted apart because the value says which curve a curve depends on.

Two things on the page are not coded values and are drawn as words: Observed and No rate say what the market holds for a pillar, and Built and Built with gaps say what the test returned. They are the screen's own sentences about a read, so they carry a semantic colour and no pill, and the screen invents no catalogue entry for them.

A dialog keeps its select's own text: a control shows the option the person chose, and the badge is for a value that is read, not for a control. The prototype draws both, and the note records the difference rather than leaving it to be found.

The screen is one card on the Market data area page, in the words and the shape the other cards carry. The area's cards are defined once in web/src/shell/cards.ts, listed in AREA_CARDS in the order the page draws them, and worded in web/src/i18n/locales/*.ts.

The prototype draws the area page at ?surface=area, with the card first and the four cards the area draws today beside it. Those four keep the words they already carry, so a reviewer reads the new card against them and not in isolation.

The card's words name the record and stop there, as the other cards do: a blueprint's pillars, its conventions and the sets it fed. It does not say bootstrap and it does not say config, because the screen says neither.

Switch with the bottom bar, or with the query string.

The prototype does not mirror the journeys step by step. It carries their intent, and this table says how each one lands on a screen, and what it does not draw.

Everything on the page is mock data: eight blueprints, their pillars, their published sets, their history, the currencies, the tenors and the accounts are hard-coded literals. There is no server, no session and no build step. The mock clock is 7 October 2026, 17:00 UTC, and every relative time is measured from it.

The curves are computed from a formula, not from a market. Each blueprint carries a base rate, the pillars carry tenors, and the discount factor at each pillar is the compound of the base rate over the pillar's years; the forward rate is the ratio of two adjacent discount factors. That gives a smooth curve, which is what the tab needs to look sane, and it is not a curve anyone could price from.

Three of the eight blueprints exist for one state each: GBP-SONIA-1D has no pillars, SEK-STIBOR-6M fails two checks (a deposit that starts at 3M, and two pillars that both end at 10Y), and JPY-TONA-6M has a bumped discount factor so that its forwards jump and a finding has something to say. USD-SOFR-1D carries three published sets and is named by another blueprint's discount curve, so the Published sets tab and the Used by value both have something to hold.

The label catalogue on the page is a proposal and not a read: the six domains the curve screens need are not in the seed, so the prototype carries the rows the note sets out, and a product screen would draw the same codes plain until the catalogue paints them. The area page's five cards are the app's own words for four of them and this prototype's words for the fifth, and the four are drawn to show the new card in context.

The reviewer should know two assumptions. The role of a blueprint and the currency it is quoted in are drawn as the fields the model holds, and the curve code is a stand-in for the output series' URI: the model stores the series by id and the record does not hold the URI, so the screen reads it from the series. The name is not a stand-in for anything: it is the record's own column, and it is what the page titles the record by. And the party is always the session's, because the list read scopes by party and the page has no party filter of its own.

The prototype is doc/prototypes/market_data/curve-blueprints/. The directory holds one file, index.html, with its CSS and its JavaScript inline: no framework, no prototype.css, no prototype.js, and no build step. The site build copies the directory as it stands and adds nothing to it.

The product screens would live here:

Three reads are missing, and the note names them where the screen draws them: a filter by bootstrap_config_id on the pillars and on the published curves, and one operation that answers a blueprint's dependants.

Open. It is offered for sign-off as the shape of the two journeys' screens: the list with its state line, the record page with five tabs and no button that repeats one, the pillars as parts in maturity order, the Check tab with its six checks and its two lines, the published sets on the record, four dialogs with nine fields between them, the label catalogue's badges on every coded value, and the screen's card on the Market data area.

What sign-off settles is that the Qt window is not the web's layout: a record page is where a person acts on a blueprint, and the test is a tab a person arrives at rather than the third panel of an editor.

The badge catalogue. Six domains carry the codes this screen draws, and the seed holds none of them. Whether the seed gains all six, whether the curve family role keeps two colours where the other five domains carry one, and whether the three words of a published set state belong to this screen or to the published-curves one, are the catalogue's decisions. The prototype's rows are the proposal the note sets out, and a screen draws plain until the catalogue is seeded.

The place in the menu. The Menu structure gives Market data five entries and none of them is Curves. This page uses the journeys' word and stands at /market-data/curve-blueprints; whether the area gains a Curves entry, and whether the published curves of the published-curves prototype sit beside it, is the menu's decision and not this prototype's.

The key in the address. The record's key is a UUID and the readable handle is now the record's name. The prototype uses the curve code the published-curves screen already uses; the address still needs one of the two, and the journeys leave it open.

The name is settled, and it is settled in the database. ir_curve_bootstrap_config carries a required name that the person types in the Add and Copy dialogs, the list draws in its first cell, the record header and breadcrumb draw as the title, and Details draws as its first fact. The output series stays a property on Details, drawn as its URI and linked, and the screen makes no name out of it. The name is unique per tenant and per party among the active rows, by a declared unique index, so a party never holds two blueprints of one name.

The check's home. The Check tab is the kind's own tab, and the standard's tab table names field groups and related plurals. The published-curves prototype drew a comparison tab and left the same question open; the two should be settled together.

Retire. A status column, or nothing. The prototype draws the state a person can infer and names it in the standard's words rather than inventing a badge.

The pillars' edit. The pillar dialog is drawn in its Add state. Whether the parts panel edits a pillar in a dialog, as RS-RELATED-06 says, or in the table, is settled by the standard and not drawn here.

The channel of a finding. The screen derives the forward rate, the jump and the missing rate, because the server returns none of them. How much of a diagnostic a screen may derive is open.