Story: Make every configuration screen follow one standard

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.

The story closes on the tasks it finished:

• Apply the standard to the pricing engine configuration.
• Author the documentation of every product type.
• Correct the value sets against the ORE code.
• Export a pricing engine configuration as ORE XML.
• Extract the shared parameter list, control and edit lifecycle.
• Fix the second value the parameter history test writes.
• Import a pricing engine configuration as ORE XML.
• Investigate the two engine-facing configurations.
• Make the parameter data model the source of valid values and rules.
• Manage the sensitivity templates.
• Model the valid values of a parameter.
• Move the curation out of the Python literals.
• Move the engine settings groups out of code.
• Move the pricing engine documentation onto the one contract.
• Validate a saved document on the server.
• Put the numbers-changing engine run settings through sign-off.
• Record the sourcing and curation methodology.
• Rename the configuration screens and their words.
• Serve the history of the whole pricing engine document.
• Show every party's configurations on the list.
• Update the configuration journeys and prototypes.
• Write the configuration screen standard.

• The screen words, decided by the owner on 2026-10-24. The configuration that selects the model and the engine for each product type is a Pricing engine configuration. The configuration that holds the Setup choices of a run is Engine run settings. The pricing page's Settings tab is Parameters. The model names, the configuration type codes and the API routes are unchanged. The analysis is in Investigation: the two engine-facing configurations.
• The lifecycle attaches to a section, not to a kind, decided by the owner on 2026-10-24. A write to a section that changes the numbers a run computes is a proposal and needs the kind's sign-off. A write to an operational section lands directly with a reason and a history entry. One record may hold both.
• A configuration no report binds is a draft and changes in place, following the draft rule the pricing engine configuration already has. It becomes governed the moment a report binds it. Decided with the section rule on 2026-10-24.
• The journeys and prototypes come first. The owner signs them off before the standard is written and before any code changes. Decided by the owner on 2026-10-24.
• A value set is the one statement of a parameter's control and its rule. A parameter's allowed values, bounds, pattern and catalogue live in the value set tables and nowhere else. The per-pair kind and options columns are gone, and so are the four control columns of the group settings table. A screen draws its control from the set, and the write path refuses a value by the same set.
• The set states a number's bounds, and one function enforces them. The parameter trigger and the sign-off proposal path call the same function, so a proposal cannot ask a person to sign a value the store would refuse.
• The engine run settings join the contract through the Setup scope. Each of the fifteen settings links to a set by its ORE name, and the screen reads the same fields the pricing screen reads.
• A link is keyed by scope and name, not by pair. A setting that two engine families read differently states the union of the two lists and says so in the set's description. A per-pair difference needs a model change, and no screen needs one today.
• A gate keeps the model true. check_parameter_value_sets.py fails when a drawn parameter has no set, when a set breaks its own rule, when the seed is stale, or when a per-pair override column returns.
• The set contents are verified against the ORE code, not the guide, and that work is separate. An audit of the seeded sets against ORE 1.8.17 found 31 disagreements: wrong kinds, wrong bounds, and lists that refuse a value ORE accepts. The report is Investigation: Verify the value sets against the ORE code, and the correction is its own task. A set that states a stricter rule than ORE is not yet a correct set.
• Closed on 2026-11-08 at sprint 29 close with its done tasks. The open tasks and the original acceptance moved to Make every configuration screen follow one standard — the remaining work.

• 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 Setup choices that the model does not hold; whether to add them is an open question in the investigation.