Investigation: the two engine-facing configurations

The master input file, ore.xml, has the root ORE and the blocks Setup, Logging, Markets, Analytics and Restore (ore.xsd lines 3 to 11). The Setup block is a flat list of Parameter name"…" value</Parameter= elements (ore.xsd lines 7 and 26 to 39).

ORE reads 51 parameters from Setup (inputparameters.cpp, the loadVariablesImpl function, lines 46 to 207). They fall into three kinds.

The distinction matters. A name of a document is not a choice of the configuration. The run document names the file, and the file is a configuration of its own. ORE Studio already models this: in run_document_projection.hpp, mapped_setup::files holds the names and states that "a configuration does not name its files".

Of the 31 choices, ORE Studio holds 15 in the engine settings model, in three groups. The source defaults are in inputparameters.hpp lines 81 to 105, and several disagree with the guide.

The list below is the whole extraction: every parameter ORE reads from Setup that is a choice rather than a file name, a path or a date. The count and the types come from the loadParameter calls in inputparameters.cpp lines 144 to 207, and the defaults from the member initialisers in inputparameters.hpp lines 76 to 122.

Affects the numbers is the engine run settings model's own classification where the model holds the setting. Where it does not, the mark is the reading of the source taken for this investigation, and the standard treats it as a claim to confirm.

The model marks a whole section at once. The building section therefore carries the mark even for lazyMarketBuilding and observationModel, which change how the engine reaches a value rather than the value itself. That coarseness is what a per-section lifecycle inherits, and the standard must say so.

logMask is the one engine setting that ORE reads from Logging, not from Setup, and the Logging value overrides a Setup value when both are present.

The setting is not a label on a screen. Each one reaches a named place in the ORE source.

The consumer is what a documentation entry should name. A person who reads "Lazy market building" and does not know where it acts cannot judge the change.

Three observations follow.

1. The 15 are a subset of the 31 Setup choices. Other live choices that can change the numbers are not held: allowModelBuilderFallbacks (default true), fixingCutOffDate, useMarketDataFixings (true), eomInflationFixings (true), entireMarket (false) and allFixings (false). The documented-only rule dropped them.
2. The guide is wrong on two defaults. continueOnError and buildFailedTrades default to true in the source and the guide says false. The screen must show the source default, as the engine settings design already decided.
3. logMask is a Logging parameter, not a Setup one, and the Logging block overrides Setup. It is in the execution group on the screen, and the design records it as an engine setting. The model is right about the effect and loose about the block.

The pricing engine configuration is its own ORE document, pricingengine.xml, with the root PricingEngines (pricingengines.xsd line 3). Its shape is:

PricingEngines
  Product type="<product type>"        (unbounded)
    Model                              (a model name)
    ModelParameters
      Parameter name="..."             (unbounded)
    Engine                             (an engine name)
    EngineParameters
      Parameter name="..."             (unbounded)
  GlobalParameters
    Parameter name="..."               (unbounded)

The guide's own section title is Pricing Engine Configuration (pricingengines.tex line 2), and its first sentence says the file "is provided to select pricing models and pricing engines by product type".

ORE reads the document into EngineData (enginedata.hpp line 41). That class holds, per product type, a model, its parameters, an engine, its parameters, and one list of global parameters (lines 58 to 94). oreapp.cpp lines 264 and 550 pass the global parameters to GlobalPseudoCurrencyMarketParameters. They configure the pseudo-currency market that a model calibration reads, and they are not run settings.

The ORE Studio extraction measured on 2026-10-24 from pricing_vocabulary.json:

The build task recorded 108 product types; the current extraction finds 104. The difference is a measurement question for the extraction task, not a disagreement about the design.

Five places look like one concept and are two.

1. Two global parameter bags. The pricing document has GlobalParameters, read into the pseudo-currency market for calibration. The run document has Setup, read into the setup variables. Both are called global, both hold Parameter name"…"=, and neither reads the other.
2. Fixings. implyTodaysFixings, enrichIndexFixings, ignoreFixingLead and ignoreFixingLag change which fixings enter a curve. Pricing parameters such as IncludePastCashflows and SensitivityTemplate change what a result reports. Both read as "fixing settings" on a screen.
3. Market construction. lazyMarketBuilding, observationModel and useAtParCouponsCurves change the market the engines price from. A pricing parameter assumes that market exists. A reader who changes the first expects the second to explain the difference, and it does not.
4. The same XML shape. Both documents hold Parameter name"…"=, so a reader who learns one shape expects the other to behave the same way. The namespaces of the names are disjoint and nothing enforces that.
5. One reach that is not visible. Both are bound to reports, and the report that binds one need not bind the other. A change to a shared engine run setting reaches reports that do not appear on the pricing page.

Five names describe two things.

1. A catalogue of engines that is not. The page titled Pricing engines lists configurations. The product holds 74 engine names, so a reader who wants the list of engines looks in the wrong place.
2. The settings of a pricing engine. Engine settings reads as the settings on a pricing engine, which is exactly what the pricing page's Settings tab holds. The two words are the two entities, reversed.
3. A tab that repeats a screen name. The pricing page has a Settings tab, and another screen is called Engine settings. A person reading a screenshot sees "Engine settings › Settings".
4. Two ORE terms missing. ORE calls the first a pricing engine configuration and the second the Setup block of the master input. ORE Studio invented engine settings and shortened the first to pricing engines.
5. One name, three spellings. The same object is a pricing engine, a pricing engine configuration and a pricing model config, depending on the page.

A name is good when it meets all five.

• C1 It names the object, not one kind of the thing inside it.
• C2 Its head noun differs from the other's, so the two never read as one.
• C3 It says what the configuration decides, without the lead.
• C4 It uses ORE's word where ORE's word is unambiguous.
• C5 It collides with no other screen word, including a tab name.
• C6 It translates to French and Portuguese without a false friend.
• C7 It fits an area card and a breadcrumb.

Option A is the decision. The owner chose it on 2026-10-24. The two heads are configuration and settings. The modifiers are pricing engine and engine run, and each says a different thing: the first is the object that prices, the second is the run the settings belong to. The shared word engine is honest, because both are about the ORE engine. The disambiguation is carried by the head noun, the one-line definition on every card and page, and the cross-link that the current pages lack.

Two supporting changes make A work.

• Drop the pricing page's Settings tab. The parameters of a product live in its workbench, and the document's global parameters have a tab of their own.
• Never print either name alone. A card, a page title and a breadcrumb carry the name and, on a card and a page, its one-line definition.

A rename is cheap on screen and expensive in the model. The recommendation changes the words only. The tables, the configuration type codes, the API routes and the component names keep their spelling, as the report currency kept base_currency.

The relationship still needs drawing, and a name cannot draw it. The standard must require three things on every configuration page: a sentence that says what the configuration decides, a card that lists the other configurations the same report binds, and a link in both directions.