Story: Normalise every ORE parameter representation

A rendering is a string a document or a caller states for a value whose meaning is one of a closed set. ORE accepts more than one rendering for four kinds of value, and the store keeps whichever arrived:

A fifth kind looks the same but is not this class: Model, Engine and a sensitivity template code name a thing the document defines, so their valid set is open and nothing about them can be canonicalised.

The count of case-insensitive comparisons in the ORE source is twenty across irmodeldata.cpp, lgmdata.cpp and bondutils.cpp, against the three the value set audit marked, so the audit under-counted that class.

projects/ores.refdata/core/include/ores.refdata.core/repository/business_day_convention_code.hpp holds the 27-to-7 crosswalk as a compiled table. It solved the one case that broke a test and a picker, and it is exactly the shape the story forbids for the general case: ORE adds a spelling, and a release has to follow. Twenty-seven strings of engine knowledge in a binary is a copy that will drift.

Three placements were considered.

• A backfill: rows already stored under an alias must be rewritten to the canonical form, and the check in the acceptance is what finds them.
• A read per write batch, which the repositories already do for other lookups.
• The compiled table goes, so the one case the branch fixed moves to data.

extract_parameter_types.py already reads the ORE source for the parser of every parameter. It gains three facts per parser: the accepted strings, whether the comparison upper-cases its input, and the spelling the engine's own writer emits (the canonical form). The census task runs it over ORE 1.8.17.0 and writes the table above with a row per parameter, which is the list the rest of the story works through.

Five of the six case-insensitive words have a writer this scan found, and the spelling it emits is the canonical form the story adopts:

Two details matter here, and both are evidence a person reads rather than trusts. The engine writes FirstBestFitThenBootsrap for the enumerator it parses as FIRSTBESTFITTHENBOOTSTRAP — the writer is misspelt, and its own parser would refuse that spelling. And CalibrationStrategy writes CoterminalAtm where the value set states CoterminalATM.

The rule that follows: the canonical form must be a rendering the parser accepts, because a document the system exports has to be one ORE reads back. Where the writer and the parser disagree, the parser wins and the difference is recorded as an engine defect rather than copied. So FirstBestFitThenBootstrap is canonical and the writer's typo is noted; CoterminalAtm is canonical because the comparison ignores case and the writer states it.

• A writer the scan cannot see. Sixty-nine parameters have no writer in the engine's source: the enumeration belongs to QuantLib, and operator<< for it lives in the QuantLib tree, not this one. The canonical form for those must come from a person's reading of the engine's output, or from the value set the registry already states, and the census says so rather than guessing.
• Leaves are not in the census. This scan reads engineParameter, modelParameter and globalParameter call sites, so it names the parameters of a pricing engine. The curve and convention leaves are a different family: the business day convention leaf was the case that started this story, and the day counter leaf is the same class. A later task extends the census to the leaves, or the value set's own links are taken as the list.

Three tables answer "which ORE element is this column, and which value set states its values": the curve columns table, the convention kind terms table and the vocabularies table. Measured, they are not three statements of one leaf. The curve columns name only curveconfig.xsd leaves and the convention terms only conventions.xsd ones, so the two are disjoint; the vocabularies table names four curveconfig.xsd leaves, and the contract path resolves the same four sets to the same codes. What the tree holds is two column maps, one per schema, and a four-row duplicate of what the contract already states.

The defect is coverage rather than duplication. Of the 299 distinct leaves the two guards check, 245 resolve to a value set and 54 resolve to none, because the parameter contract holds no row for them. A leaf the map names and the contract does not is silently unguarded. The evidence is evidence/leaf_maps_overlap.py, with its output beside it.

The overlap is worse than duplication in one direction. Both guards resolve a value set through the parameter contract — curve column or convention term to (schema_name, xpath), then to the parameter, then to its setting link — so the vocabularies table is not on any path a write takes. A rule stated only there is stated and not enforced. That is measured, not inferred: grep -rn "ore_parameter_vocabularies" --include=*.cpp --include=*.hpp --include=*.ts --include=*.tsx projects/ apps/ returns nothing, and both guards' joins are projects/ores.sql/create/refdata/refdata_curve_configuration_columns_validate_create.sql:43 and refdata_convention_terms_validate_create.sql:51.

For the canonical form the story needs exactly one thing: given a column or a parameter, find its value set. Two links already do that, one for a parameter and one for a leaf. The canonical pointer goes on the values those links find, so no new map is added and none of the three leaf tables is a prerequisite.

The first task of the story, not a later clean-up: one leaf map keyed by the ORE element, with the projection columns attached to it, and the two links collapsed into one shape. It runs before the canonical form, because every later task reads a value set through a link, and a link with three homes is what makes a reader guess which one wins.