Story: Model the ORE report configuration as entities

A report definition's configuration is a set of strongly typed entities rather than a flat row of switches: every one of the seventeen ORE configuration document kinds is identified, mapped to an owning component, seeded as a configuration type, and round tripped, import and export, through the entities over the vendored corpus. A report type is a foreign key from the definition, seeded with a stable code, and it names the workflow it selects and the configuration types a run of that type requires.

On 2026-10-05, at the sprint 26 close, this story was reworded to the scope it delivered and closed DONE. The remainder — the round trips still missing, the report-kind classification, the run-input packaging, and the entity models the hand-written tables still need — is Complete the ORE report configuration, and its twenty-two tasks moved there.

• Every entity in the seventeen ORE configuration documents is identified and mapped to an owning component.
• A report definition reaches its configuration through typed entities and foreign keys, never through a flat table of switches or an XML or JSON blob.
• Every report type is seeded with a stable code, and each one names the workflow it selects and the configuration types a run of that type requires. The report definition reaches its type by foreign key, not by a text code.
• Every configuration kind whose entities are modelled round trips end to end over the vendored corpus: the run document, the stress test, the credit simulation, the curve configuration, the shared reference configuration, the conventions, the pricing engines and today's market.

• The plan of record is one task per ORE configuration document, each running the whole path for that document: entities, an import mapper, an export mapper, and a round trip over every file of that type in the vendored corpus. Four earlier tasks were shaped by concern rather than by document and now roll up into these, closing when their last file type lands: Model the run document and the analytic list into Round trip the ORE run document, Model the analytics configuration libraries into the seven analytics round trips, Model the curve configuration entities into Round trip the curve configuration, and Model the shared reference configuration into Round trip the shared reference configuration. The concern-shaped tasks stay open as the roll-up, so the story keeps a record of the design intent behind each slice.
• A file type is round tripped when the exported document equals the imported one as a parsed document, and the test names the first difference when they differ. The corpus is the evidence, not a hand-written fixture, except for the two types the corpus does not contain.
• The mappers follow the convention already in the tree: a class named <thing>_mapper with static map for ORE XML to our type and reverse for the other direction, beside the generated bindings in projects/ores.ore. There is no base class and no registry today, so the harness is what will enforce the convention. The existing xml::roundtrip directory walker covers four document kinds; the harness extends it rather than replacing it.
• simmcalibration.xsd is included by external/ore/xsd/input.xsd but SIMMCalibrationData appears zero times in the generated projects/ores.ore/core/include/ores.ore.core/domain/domain.hpp, so that document cannot be read or written at all today. The SIMM slice generates the binding first; the round trip proves it afterwards.
• The classification task was written against columns that do not exist. The report definition carries fsm_state_id and scheduler_job_id, and keeps schedule_expression and concurrency_policy; pre_processing, prepared_input_key and post_processing appear nowhere but an untracked web build artifact. Classification replaces the type code with a foreign key and the run columns with a classification, and it does not hunt for those three.
• A reporting table declares a foreign key in a * Foreign keys section with :table:, :target_column:, :parent_entity:, :nullable:, :error_message: and :list_by:, which generates validation and indexes; it does not use the :references: property that one compute model uses. See evidence/reporting_model_recon.md.
• A round trip covers a document kind, so the corpus is the set of files whose root element is that kind, found by glob. Counting files named exactly <kind>.xml undercounts: the run document is 416 files, not 82, and credit simulation is 14, not 2, because the corpus holds variants such as ore_histvar.xml and simm_calibration.xml. See evidence/round_trip_corpus.md.
• Three documents cannot be round tripped as they stand. simmcalibration.xsd and baselTrafficLightconfig.xsd declare global elements that appear zero times in the generated domain.hpp, so no binding exists for them; historicalreturnconfig.xsd declares no global element at all and is a section of the documents that reference it, not a file type. The two with a root element generate their binding first.
• The existing binding round trips do not prove the content of every document. In `creditsimulation.xml` the transition matrix is carried as one `Data` element whose text is a whitespace or comma separated grid, with optional `t0` and `t1` attributes, and the existing `xml_creditsimulation_roundtrip_tests.cpp` deliberately does not compare `Data`. A test can therefore pass while the matrix is lost. Our round trip compares the grid cell by cell and names the first difference.
• A passing round trip can hide an axis it never measured. The credit simulation label comparison ran over an empty vector on both sides, because the binding does not hand the mapper the XML comment the labels live in: `parse_credit_simulation_grid` returned 64 values and no labels, and the loop that compared them executed zero times. Fourteen files passed a check that never ran, and it was reported as proof. The scale is fixed and is now in the type, so both directions take the ratings from one ordered constant and the comparison has a real expected value. An assertion over an empty vector is not an assertion, and a test that cannot fail is worse than no test.
• Where a configuration's entities live. ORE's own Analytics block decides it. If ORE names the document in that block it belongs to ores.analytics; if the run or an analytic merely references it, it belongs to the component that owns the concept, which is ores.refdata for curves, conventions, calendars, currencies and tenors, and ores.reporting for the run document and the registry. ores.ore holds the mappers and no state. A configuration is a header row in reporting.configurations and its content is in the owning component, joined by configuration_id.
• The harness takes a per-kind comparison, because parsed equality is not text equality. The binding holds some numeric attributes as text and the mapper writes them back in its own spelling: ORE's t0"0.0"= and our t0"0"= are the same bound, and the netting set list is indented differently although its codes are the same. A generic text comparison fails a faithful round trip; a rule that ignores text hides a lost value. So a kind supplies its comparison beside its mappers and the harness owns the walk, the count and the failure list. The credit simulation comparison moved out of its test into credit_simulation_diff.cpp for this reason, so the test and the harness share one implementation rather than drifting apart.
• A comparison may state a normalisation, but only one that carries the same information. Calendar adjustments are the case: ORE writes a date list it has no dates for as an empty element and the mapper omits it, so the kind declares that an empty list may be written either way. The rule is narrow by construction, because a list with dates in it is compared date by date and cannot slip past it. A comparison may not be widened to accept a lost value: where the difference is a field the entities cannot hold, as with ORE's currency type, the model is wrong and the model is what changes.
• The harness walks a corpus by file prefix, which is what the census globs. A kind's files are the ones whose stem starts with the kind's prefix, so creditsimulation* finds the 14 credit simulation documents including creditsimulation3_ts.xml. Counting files named exactly after the kind undercounts, which the census already recorded.
• A mapper that skips must count what it skips. conventions_mapper ignored seventeen of the document's twenty-six categories and said nothing, so seventy-two files passed a round-trip test that compared element counts while losing content. It now fills mapped_conventions::unmodelled and warns per category. A gap that is counted is one a caller can act on; a gap that is silent is indistinguishable from a document with nothing in it.
• A normalisation the mapper performs on purpose is stated, not fixed. Conventions come back with true written as True and A365 as A365F, because the mapper collapses booleans and enum aliases to the canonical codes the refdata columns hold. Two spellings of one boolean, and two aliases of one day counter, carry the same information, so the kind's comparison states them. The rule this story already holds to applies unchanged: what may be stated is a difference that carries the same information, and a dropped element carries less than the document did.
• A vendor's token gets its own column. ORE's CurrencyType was translated into the refdata monetary_nature, and the translation could not be undone: Major and Minor both became fiat, so the export could never recover which one the document held. The two are different axes, since a nature says what a currency is and ORE's type says how important it is, and market_tier was not a home for it either because its lookup holds g10 and emerging. The currency now carries ORE's token verbatim in ore_currency_type, which is nullable because ORE declares the element as a free string and most documents set none, and it derives the nature from it. The rule generalises: where a document's field is the vendor's vocabulary and not ours, it is stored as the vendor wrote it, and our classification of it is a separate derived column.
• A round trip is compared after a save and load cycle. A document that cannot survive its own export and re-import is not a round trip, and the cycle is what proves the binding decodes the text it escapes. PR #2500 dropped the cycle to hide a binding defect; it is back, with the defect fixed.
• The ORE parser is fixed in xsdcpp, not in the bindings. The generator embeds src/XmlParser.cpp verbatim into domain.cpp, so a parser fix made only in ORE Studio would be lost at the next regeneration. Until the unexplained trade and componentSubTrade drift in a full regeneration is resolved, the bindings take only the parser hunks, byte-identical to the generated ones.
• A file's origin is measured by rendering, not read from its comment. census_sql_origin.py renders every catalogue component and labels a SQL file codegen output exactly when the render contains it. Generated files also carry the "do not edit" comment, drop scripts included, but a comment survives the deletion of its generator's input, so it is a hint for a reader, not a count.
• Every SQL file is wired or named as an exception. WIRE_001 checks every file under create, drop and populate, reached from the tree roots and the bootstrap scripts, and CI fails on it. A file a person or another tool runs directly goes in validation_ignore.txt with what runs it.
• A report type selects the workflow and names the run's required configuration. The workflow is a column on the type, and the required configuration types are a junction, both read under the system tenant where the lookups are seeded. The trigger refuses a definition that binds fewer, so a run that cannot finish never creates an instance. Analytic-specific configuration belongs on the analytic types, not the report type.
• Soft foreign keys impose no creation order. An insert trigger resolves its parent table when it runs, so generated aggregates need only a table before its trigger and hand files that name tables after the tables.
• World data is not party configuration. World data (currencies, calendars, index and currency pair conventions, market quotes) is one view of the world that every party shares, so it has no party_id; it is per tenant until the synthetic data rewrite settles its scope. Party configuration (run documents, pricing engines, curve configurations, today's market, stress tests, instrument conventions) has party_id and a restrictive party RLS policy, set from the JWT by stamp. Synthetic data writes only world data. See World data versus party configuration.
• A key column can be wider in SQL than in the API. :sql_key: true puts a column in the primary key, unique indexes, exclusion constraint and versioning triggers but not in the repository or protocol key, so a party supplied by the session lets two parties hold the same convention id.
• A run's configuration moves through one store per document kind. ores.ore.core/store writes and reads each mapped document, and the run store imports an ORE input directory against a report definition and exports it back as the files the run document names. A binding to conventions means the conventions the session sees, since conventions have no header.
• Reporting lookups are read in the system tenant. Configuration types, analytic types and parameter definitions are seeded once, for the system tenant, so every foreign key to them carries :use_system_tenant:.
• No service reads or writes another component's tables. The run store that Import a run's configuration from an ORE input directory put in ores.ore.core wrote the reporting, analytics and refdata tables directly, and the operator ruled that an architectural error. Each owner stores its own configuration documents and exposes them as NATS operations; ores.ore maps ORE XML to and from those documents and orchestrates the owners, with a workflow saga for the import. See No service reads or writes another component's tables.