Reporting prototypes

Table of Contents

1. Summary

The reports a party runs, what each produced, what went wrong, and when the next one starts. Seven journeys describe that work, and there is no reporting surface in the application at all today, so nothing here has prior art to copy.

19 prototypes answer to this group: one for each of the nine journeys of a run, one that two of them hand the analytics to, one that reads a report with its scope, analytics, conventions and history on tabs, five for the pricing engine configuration, one for the engine run settings, one for the published curves the run settings name as its market, and one for the curve configurations of a document. Each is a static page under doc/prototypes/, opens with no build and no session, and reads mock data only. The table below opens each one and says what it argues. Where a prototype carries a Gemini review, the last column opens it.

The conventions have no prototype of their own. They are named convention sets, and the report chooses one: Create a report and Change what a report runs each carry that choice on one page. Authoring a set is its own UX, addressed outside this work, and the prototype that used to argue a per-kind interaction inside the reporting group has been retired.

Prototypes is the top page and the only inventory.

2. One decision, an axis for each journey

The journeys are not a screen plan. Reading them one to one would give nine screens for one job, and nobody would build it that way.

The decision this set exists to inform is what the reporting surface is, and how many screens own it. Each prototype offers three structural variants of its own journey, and each turns on the question that journey actually poses rather than one frame forced onto all nine. Forcing a single axis was tried first and it broke down: the question a catalogue asks is not the question a result asks.

What is shared is the method. Three variants, one switcher, the same chrome, and the same rule that the variants disagree about structure and not colour.

Prototype The axis its three variants turn on
See the reports a party runs What the front door is: the catalogue of reports, a ledger of runs, or only what needs a human.
Run a report and watch it finish Where waiting happens: a strip that reports itself while you work, a dedicated view you stay in, or a queue you watch together.
Read what a run produced What the result is: the numbers and the trade rows under them, the archive of files, or a sentence about the numbers.
See a report's results by counterparty How a result is read by counterparty: a ranked list of names, a tree through the group each one nests under, or a map of how concentrated the run is.
Find out why a run went wrong Whether errors are a place you go, a panel beside the run, or a ledger across runs.
Choose when a report runs Where scheduling lives: on the report, in a schedule list, or on a calendar.

The prototypes are not meant to be read as one design with nine parts. They are nine answers to nine different questions, drawn in one voice so that the answers can be compared.

3. The prototypes

Prototype What it argues Open it Review
See the reports a party runs The front door of reporting: which reports this party runs and how each one last went, with a run that completed while carrying errors told apart from a clean one without opening it. prototype none
Run a report and watch it finish A run is six phases and seven workflow steps, and the person waiting needs to know when to stop waiting. The three variants disagree about whether watching is a place you go or a strip that reports itself while you work. prototype none
Read what a run produced What "the result" is: the numbers with the per-trade rows beneath them, the archive, or a sentence about the numbers. The drill-down runs from a run's figures to one trade's NPV and its error. The result also rolls up as a book tree: a portfolio, a nested sub-portfolio, a book, and a trade, with a trade booked to no book shown as an unbooked node. The gap is stated rather than drawn round, because no operation lists the files inside a run's archive, none parses them, and none returns a result grouped by book. It also plots the result in the form each set of numbers asks for, from a stated vocabulary and a stated rule that picks between them: sorted bars of NPV, Delta and Gamma by book, a donut of each book's share of the run and a donut of the run's problems by scope, grouped bars of Delta against Gamma, a scatter of Gamma against Delta, stacked bars of the problems of the two runs the comparison pairs, a signed bar chart of the change against the baseline, and a line of NPV across the runs of the definition with the current run and the baseline marked. A plot whose figure the errors left partial carries the same partial marking the figure carries, a donut draws the excluded part as a hatched slice named excluded, and a count with no magnitude to compare stays a table. prototype review
See a report's results by counterparty One run read by counterparty rather than by book, which is the question a credit reader or a limit conversation starts with. It ranks names by their aggregate NPV, notional, trade count and exposure, keeps a group above its members because counterparties nest through the parent, opens one name to its trades, netting sets and errors, and draws a counterparty with no result and a trade naming no counterparty as stated cases. The gap is stated on the page, because nothing parses the run's archive and npv.csv names the counterparty instead of identifying it by id. prototype none
Find out why a run went wrong The sharpest question of them: are errors a place you go, a panel beside the run, or a ledger across runs. It renders twenty real error rows, including one trade failing in two analytics with the same message. prototype none
Choose when a report runs Where scheduling lives: on the report, in a schedule list, or on a calendar. It keeps run now, pause, play and unschedule apart, and states that the schedule has no time zone, that no scheduler read exists for this screen, and that pause and play have no operation. prototype none
Look back over a report's history The runs of one report newest first, each with its timestamp, the newest marked latest, the last five fire times, and a notice when the run being read stops being the newest. A trend line of the report's exposure sits above the list, with the latest run's point marked and named, every point a run's errors left partial drawn hollow and dashed, and a run that produced no figure breaking the line. Beside it sits the page's plot vocabulary and the rule that picks a form: a donut of the latest run's problems by scope, stacked bars of the problems by scope across the runs, grouped bars of the errors against the warnings, and a scatter of how long a run took against how many positions it placed. prototype none
Create a report Creating a report on the standard steps UI: seven fixed steps (what it is, one step for each of the five configurations it binds, and the analytics that configuration carries), then a final review that states every value and reads the row back. Step 7 is the entry point to the analytics and not a second implementation of them: it reads the set the bound configuration holds, with the count that is on, the display order, the rows kept off and the incompatibility state, and it hands the work to Manage the analytics. Step 2 is one page of named convention sets: a row per set with its name, its purpose, the kinds it covers and whether this report uses it, a radio to choose the set the report binds, and one link out to the convention authoring UX marked as not in this MR. It draws no per-kind table, and every name, purpose and count in it is a fixture, because no table stores a set's name or purpose, nothing marks the document a run reads for a kind, and the conventions configuration carries no children. prototype none
Change what a report runs A wizard over three panels: the definition and the configurations it binds, with where each one's data lives, then the analytics of the bound configuration as a read-only summary, then what a change to that set reaches. It draws no analytic control: the switchboard and the add-analytic flow are gone, and step 2 hands the analytics to Manage the analytics and states what the change reaches. A conventions configuration is a named convention set, so its row shows the set chosen on the card below, and that card is the same one page of sets the create flow draws: name, purpose, kinds covered, whether this report uses it, a radio to bind one, and one link out to authoring marked as not in this MR. Incompatibility is a visible state, so pfe without simulation is marked and the rule is named. prototype none
See a report and everything it runs One page for a report definition on six tabs: the definition with its report currency and flag, the scope, the analytics with the engine settings, the market and pricing, the conventions, and the standard history. Each tab says what a change on it reaches, because the run settings and four of the five configurations a report binds are shared. It carries the regulatory book type and the rule that refuses a scope of the other type, with a refusal that names the book and the report. The conventions tab shows the system as it is, where a run reads all 11,027 convention documents whatever the binding says, and the proposal, where the report chooses a named set. It replaces the first panel of Change what a report runs. prototype none
Manage the analytics The one prototype that owns the analytic interaction of a run settings configuration: a switchboard of the fourteen types with the on/off control, the display_order and a one-line summary, a rail step for each analytic that is on in display_order, and a final step that reads the set back. Turning one off asks first and sets active false rather than deleting the row. pfe without simulation is a state with both rows marked, the refused toggle and a final step that refuses to read the set back. Three readings of the per-analytic step behind =?variant=A B C=: a document, two columns, and a guided walk one parameter at a time. prototype none
Product pricing The list of pricing engine configurations, and the page of one with Properties, Products, Reports and History. The Products tab is a tree by asset class beside the product itself: a definition and a select for the model and for the engine, each with its description and its parameters, and one documentation disclosure for the product, its instrument and its asset class. The status, the cycle, the counts and the reports are fixtures. prototype none
Curve configuration sections The curve configuration record screen in the product pricing shape, because one tab per section does not work: a curveconfig.xml declares nineteen sections and a real document fills between one and sixteen, so the page keeps Details, Used by and History as tabs and draws the whole document in one Curves tab, as a searchable rail of curves grouped by the section that declares them with the chosen curve's parameters in a workbench beside it. The sections that hold nothing sit behind one disclosure that names them. Three fixtures: a one-section document, a four-section one and a sixteen-section one, measured against the 89 curveconfig*.xml files ORE ships, whose median is three sections and whose largest is sixteen. The nested collections of a curve are named and not drawn. prototype none
Market bindings The market a report prices from, as rows: one row per market role, each naming a published curve and not a name. The bindings are a collection of the run settings configuration, so they are a tab of its record page, changed in the picker per row and saved once for the document. The picker is the published-curve read with the state drawn, so a candidate is refused where a person picks it, and an ended set is refused too unless the person pins its as-of — the only route past the refusal, and the only way a rerun reproduces an earlier result. The run's own page then names the publish record it priced from, and the report's Market and pricing tab is the door. It draws a role that binds nothing, a published binding, a candidate refused, an ended set pinned at a historical as-of, the run refused, and the run that names its set. prototype none
See the engine run settings a party holds The list of engine run settings configurations and the page of one, drawn beside the pricing engine configurations. A configuration holds three sections of documented settings, each its own part with its own version and its own tab, and each section says whether it changes the numbers. A section that changes the numbers, on a configuration a report binds, is proposed and signed off; an operational section writes directly. The Details tab names the pricing engine configuration as the other configuration and links to it. The Used by tab names the reports a change reaches, and History is the shared timeline. The report names are real, and the counts and the history are fixtures. prototype review
Author a pricing engine configuration Authoring a configuration in six steps on the standard steps UI: the name, what it is for and the starting point, the products, a model and an engine for each, the parameters, a check against what the reports of a cycle need, and a review. The result is a draft, or a candidate for the official intraday or EOD configuration. Submit for sign-off is not offered while a needed product type has no row. A pair not known to work is marked and never refused, and the page says no server check stands behind any finding. Three readings of the model and engine step behind =?variant=A B C=: a table, a card for each product, and a guided walk. The pairs are counted from 110 ORE example files. prototype none
Change how a product is priced One product row changed in the record dialog, with the reach, the difference before and after, and the choice between proposing a new version of the approved configuration and trying the change in a draft copy that no official report can bind. Nothing changes until the sign-off completes, and the dialog says which version stays in force. A draft changes in place. A setting the new pair does not take is shown as will be dropped, and nothing is dropped until the person ticks it. It draws the stale-version refusal and the History tab with Propose a revert. prototype none
Bring in a pricing engine configuration file An ORE pricing engine configuration file brought in over five steps: what the file holds, what the system does not know, the target, the difference and the review. The difference lists the products the file removes first, with Keep it as the default, then what it changes and adds. A product type with no code is skipped, an element with no column is dropped and named, and a duplicate is resolved by the person. A new file is saved as a draft, and a file put into an approved configuration is a proposal for sign-off. The parse and the difference are mocks, and the page states the operation that is missing. prototype none
Sign off a pricing engine change The queue of proposals to change an official pricing engine configuration, and one proposal's page: the sign-off by approval part, the changes against the version it was written on, the reach, and the history. The person who proposed a change cannot sign it off, even when they hold one of the parts, and the page draws that refusal. It draws an approval, a refusal with a reason, a proposal that every approval part approved and is made official, a proposal that is out of date and must be rebased, and a withdrawal. The approval parts are those of the inbox, and the names of the two new ones are assumed until model risk confirms them. No pricing engine configuration operation holds a proposal or a decision. prototype none

4. What none of them settle

Whether the seven journeys become one area, one screen, or two. That is the decision this set exists to inform, and it is taken after the review rather than here. Each prototype argues one journey; the area they share is drawn only far enough to judge the journey inside it.

Two things are settled. Analytic management has one screen: Create a report and Change what a report runs used to draw the same switchboard, the same parameters and the same incompatibility state, in two vocabularies for the same three states — on, off, and a type with no row. Both now read the set and link to Manage the analytics, which owns it.

And the conventions are chosen, not assembled. A convention set carries a name, a purpose and a description, a system holds few of them, and a report binds one by choosing it. Authoring a set is its own UX, deferred to its own work, so no prototype here draws a per-kind table, an alternative per kind, a provenance card or a migration state.

5. Adding a prototype

Follow Prototypes, which has the one way. A prototype here is a static page, never a route in ores.web, and it carries a design note at doc/prototypes/reporting/<name>.org that this page links.

6. See also

Emacs 29.3 (Org mode 9.6.15)