Author a pricing engine configuration prototype

A pricing engine document is a long list of product types, each with a model, an engine and settings, and the names are ORE's own. The person knows what the party trades and has a view on how each product should be priced. They should not need to know which engines exist or which settings a model needs. The screen offers the usual pair for each product, narrows the engine to the ones known to run the model, says in words what each setting means, and checks the result against the product types the reports of the chosen cycle need.

• A, a table. One row for each product, with the model and engine in two combo boxes, Use the usual, a note on the pair and the order arrows. It is the densest, and a person reads the whole document at once.
• B, a card for each product. The same fields on a card with the product's description, two cards across. It gives the description room, so a person who does not know CMSSpread can read what it is.
• C, a guided walk. One product at a time, with Previous and Next. It suits a person who authors a configuration once and wants to be told what each product is.

• A pair that is not known to work is marked and never refused. The person may know better than the list, and the server checks none of it.
• Nothing in step 5 blocks a draft. A finding is a statement. The review step repeats it. The next step does not offer Submit for sign-off while a needed product type has no row, or a row has no model or engine. The screen is the only reader of this rule.
• Coverage follows the portfolios. A report needs a price for every product type in its portfolio, so the check lists what the reports of the chosen cycle need, and what is left unpriced for each report.
• The usual pair is a suggestion. It is the pair most product entries in the example files use for the product, and the page says where the suggestion comes from.
• A copy carries the products and settings. It carries no report binding and no sign-off, and it starts as a draft.
• The page names the official configuration of the cycle and says it stays in force until the sign-off completes.

Every value. The models, engines and pairs are counted from 110 ORE example files (123 product, model and engine triples; the page uses the 24 most common). The notes and usual values of the settings are this page's own wording, written for the Bermudan swaption pair, the risky bond and the swap, and a setting the page does not know is a text field. The traded product types are a fixture. The save writes to the page's memory only.

No operation returns the models, the engines, the pairs that work or the settings a pair takes, and no service checks a document when it is written. The document write is not one transaction. The party's book is not readable. Each is stated on the page where it bites.

doc/prototypes/reporting/author-a-pricing-engine-configuration/index.html. One file, plain HTML, CSS and JavaScript, with the style and the script inline, no modules, no fetch and no build step.

• The standard steps UI carries the journey: six steps, the last final, one computed rail.
• A pair that is not known to work is a mark, not a refusal.
• The checks are the screen's own, and the page says no server check stands behind them.
• A configuration made here is a draft. Becoming official is a sign-off, not a save.
• ?cycle=none|eod|intraday switches the purpose, so each way to finish is reachable.

None yet. This page is on the branch that proposes it and waits for review.

• Which of the three readings of step 3 is right. That is the question the variants exist to answer.
• Whether the models and engines should be two lookup tables, or one table of pairs. The page reads a fixture of pairs and cannot decide.