Story: See and change everything a report runs

The report page is one scroll. A record card holds the definition's fields and offers Edit. A Latest run card follows. A Configurations card lists the bindings, each by kind and name, and each name opens a configuration page that is read-only. There are no tabs.

The only thing a person can change on it is the nine fields of the definition itself.

Each of the 22 definitions of ACME Corporation HK Ltd binds five configurations:

So four of the five belong to the party, and a change to one reaches every report of it. Only the run settings are close to the report, and even they are shared by two or three reports in eight cases. A page that offers a change must say who the change reaches.

Three facts, and each blocks the change on its own.

1. A convention set does not exist. The conventions configuration a report binds is a name. It holds no document. The 26 convention kinds are 26 tables, and no table stores a set, a set's name or its purpose.
2. A run ignores the binding. The packaging reads every convention row of the party's 26 kinds (read_family in run_configuration_operations.cpp). Binding another configuration would change nothing a run reads.
3. No document is marked as the one that counts. The party holds 11,027 convention documents in 26 kinds. The largest kind, commodity futures, holds 3,950. A run reads all of them. The journey "See the conventions a party uses" states the same gap.

A convention document can be changed on its own screen, /refdata/conventions, and that change reaches the whole party. What cannot be done is to choose, for one report, which documents it reads. The journeys already name the answer: named convention sets, one document of each kind, chosen by the report. The set, and a run that reads it, are the work. The tab is the small part.

See a report and everything it runs draws the page on tabs. The owner reviewed the first version on 2026-10-21 and decided the layout and four changes.

The tabs are Definition, Scope, Analytics, Market and pricing, Conventions and History. Each states what a change on it reaches.

1. The layout. Decided on 2026-10-21: tabs, with the scope and the analytics apart. See the table above.
2. The conventions model. Named sets chosen by the report, as the journeys say. The alternative is a per-kind override on the report, which the journeys retired. The prototype assumes sets.
3. A kind a set does not cover. The run could fail with a message that names the kind, or fall back to every document of that kind. The prototype shows failure, which is the stricter choice.
4. Who changes a shared configuration. A change to a configuration read by 22 reports is a change to a party. The choices are: allow it with the reach stated, require the approval a convention change already needs from Market Risk, or fork the configuration for the report on edit.
5. Where the scope is edited. On the Scope tab, or on the configuration's own page. The prototype draws it on the tab, marked as proposed, because that is where the book type rule is read.

Why the History tab needs the server first. The report page has no history tab today, and its test says the versions cannot be read by id. That is true, for two reasons found in the code on 2026-10-21:

1. The service has a history provider for report definitions, register_report_definition_history_provider, and nothing calls it. The reporting service does not answer the generic history read for a definition.
2. The provider reads by the definition's name (get_definition_history sets key.name). A name is unique within a party only, so two parties that run a report of one name would read each other's history. The generic request names the entity by its own id, and the definition's id is what the page holds.

So the step is: register the provider, key it by the definition's id, and test that two definitions of one name in two parties read their own versions. Then the BFF route and the shared history panel follow the pattern the other records use.

The word report currency. The screen calls base_currency the report currency. The column keeps its name for now. Renaming it touches the model, the generated code, the seed and the shell, and is a separate change if the owner wants it.

Step 1 can start at once and delivers the page the owner described, without the history. Step 5 is what makes "change the conventions" real.

ores_reporting_risk_report_configs_tbl has 28 value columns in four groups, and four families of child rows.

The 46 rows hold 7 distinct engine setting tuples. Three parties have 12 rows with one tuple and 2 rows that differ only in n_threads (4 instead of 1). The fourth party has 4 rows with one tuple. Each party's 14 rows hold 14 different analytic sets. The rows differ in scope and analytics. The engine settings barely differ.

The regime 2 score is 3 of 5, and the debt is Medium.

Checked on 2026-10-21 against the ORE 1.8.17 source (OREAnalytics/orea/app/inputparameters.cpp, oreapp.cpp, OREData/ored/marketdata/csvloader.cpp) and the user guide (Docs/UserGuide/parameterisation/ore.tex). The version is the one the repository records in external/ore/catalogue/ore_version.txt.

Finding 12 needs a decision before the model task starts: keep the 13 live settings, drop the 7 that ORE ignores, and add the live ones the owner wants to manage. Every setting now has a long description and a table of its values in the prototype, written from the source.

as_of in run_document_generator.cpp resolves the date for each run. eod gives the weekday before the run date, live gives the run date, and date gives the stored date. The eod rule does not consult holiday calendars. The definition states end of day or intraday and no date, so the date kind and the stored date belong to the run.

The engine settings become a named configuration of type engine_settings. A report definition binds one in its own slot, as it binds the pricing engines. The configuration is an entity made of a central row and three parts, and it holds every engine setting that the official ORE documentation describes, 15 in all. The owner first confirmed five groups on 2026-10-21. The documented-only rule, described below, leaves three.

Why parts. The standard says a field set earns a part when it has its own multiplicity, change reason or reader. The two groups that change the numbers have a change reason that differs from the operational group. A person edits one group at a time, and the run reads all three. A group can be absent, and an absent part means the engine default for the whole group. The convention families already use this shape, for example tenor_basis_swap_pay_receive.

The composition rule. A write to any part bumps the central row's version in the same transaction. The History tab shows one entry for each part changed.

What leaves the run settings.

• The report currency moves to the report definition.
• The market data kind moves to the report definition, as end of day or intraday. The run carries its own time point.
• The five package paths and portfolio_recurse_into_sub_directories are package layout. The platform sets them and no configuration stores them.
• The run settings configuration keeps the scope, the analytics and the market roles. These are the Scope and Analytics tabs.

Migration. The 46 rows become 7 engine settings configurations, each with at most three part rows. Each name starts with its party's name. Only the five values that the rows set today migrate.

Decided by the owner on 2026-10-21: the screens describe only the parameters that the official ORE documentation mentions, and the model holds all of them. Where the guide and the source disagree, the source wins.

Checked against Docs/UserGuide of ORE 1.8.17.0. Eleven of the 19 stored settings are in the guide. Eight are not and leave the model: accrualDate, fixingCutoff, dateCalendar, dateConvention, defaultMappingToIdentity, useAnalytics, csvCommentReportHeader and additionalResults as a Setup parameter. Four documented settings were not stored and are added: useAtParCouponsCurves, useAtParCouponsTrades, ignoreFixingLead and gzipCompressionLevel.

ignoreFixingLag moved to the fixings part, because it limits the fallback that Enrich index fixings fills. The groups Dates and Report output of the first design hold no documented setting.

The documented Setup parameters that are not engine settings stay where they are: asofDate is the run's own time point, baseCurrency is the report currency, inputPath, outputPath and logFile are package layout, and the file parameters are documents. includePastCashflows is a parameter of the cashflow analytic in the guide, not of Setup.

The defaults on the screen follow the source. The source defaults continueOnError and buildFailedTrades to Yes where the guide says No. The guide says includeTodaysCashFlows and includeReferenceDateEvents default to false.

Consequence for the importer. A run document that sets a parameter the model does not hold is no longer refused. The importer drops the parameter and reports a warning that names it. This covers the eight settings that left the model and every other Setup parameter that the guide does not describe. fixingCutoff and csvCommentReportHeader are read by ORE, and fixingCutoff changes the numbers, so the warning says that the run will not read the parameter and that its numbers may differ from the original run. Decided by the owner on 2026-10-21.

Decided by the owner on 2026-10-21, after the review of the ORE source.

1. The documentation is data of its own, apart from the data model. The existing parameter_definition table is generalised into a documentation system for every ORE parameter and every ORE document element. It serves the UI with text, versions and formats. It does not validate values: validation stays with the data model.
2. A documentation entry relates to the ORE file it belongs to. The screens are hard coded to look an entry up by the name of the setting.
3. The system covers the conventions, the configurations, the pricing engines, today's market, the curve configuration and the analytics, not only the Setup block. The 365 analytic parameters and the 35 analytic types get the same columns.
4. An entry carries the ORE XML name, the release that introduced the parameter (since), the release that removed it (empty while ORE still reads it), the default, a long description, the format as text, and whether it changes the numbers, which the screen shows as a label. The description explains what each value means. The entry holds no table of values: a value that refers to an entity is bound to that entity, and the documentation does not copy it.
5. A setting that the engine build does not read produces a warning, not a refusal. The application supports two builds, ORE 1.8.17.0 and 1.8.16.0, and the documentation covers the parameters of those two only. The warning waits for a target build in the data model, see finding 13.
6. Only parameters that the official ORE documentation mentions are described. The undocumented legacy settings are removed from the screens.
7. The screens show a Simple and Advanced switch as on the feed screens. The documentation of a setting is collapsed under it. Advanced adds the entry: the ORE XML location, introduced in, removed in and the format.

The since and last version values are measured from the 20 ORE release tags (v1.8.0.7 to v1.8.17.0) by searching each tag for the Setup read. The two oldest settings are lower bounds. useAnalytics is read in 1.8.9.0 only. Six settings are never read in any tag. For those, the entry shows the first and the last release whose shipped examples carry the setting, and says so.

1. Who may change a group. The prototype lets an analyst edit all three. The two groups that change the numbers may need an approval like a pricing engine change.
2. The spelling of the flags. Every flag parses with parseBool, so the model stores booleans. The projection writes true and false. This is a default taken in the data model PR. The owner may change it, and the change is one function.
3. Whether the currency and the market kind move in this story as separate tasks, or in a later one.
4. Whether the scope and the analytics get names of their own later. The data says they are what differs between reports.
5. Where the target ORE build lives, and how the run records the build it used. See finding 13.

Settled on 2026-10-21: the model holds every documented engine setting, 15 in three groups. The source wins when it disagrees with the guide. The importer warns about parameters it drops.