Task: Investigate the two engine-facing configurations
Table of Contents
This page documents a task in the Make every configuration screen follow one standard story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
A point-in-time investigation that reads the ORE source and the ORE Studio tree, states the responsibilities and the boundary of each configuration, maps their linkages, inventories the naming collisions and recommends the screen words.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Make every configuration screen follow one standard |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-24 |
3. Acceptance
- The investigation cites the ORE 1.8.17.0 sources it read, with file and line.
- It states what each configuration decides, with the parameters each holds.
- It states where one ends and the other starts, including the overlap zones.
- It maps every linkage: the run document, the report binding, the run order and the documentation.
- It inventories the naming collisions and compares at least three naming options against stated criteria.
- It names the open questions the owner must decide.
4. Plan
(Implementation strategy. Written when work starts; key decisions
are distilled into the parent story's * Decisions at close, but the
plan itself stays — it is the historical record of what we did.)
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
| Setup parameters ORE reads | 51: 16 document names, 4 paths and dates, 31 choices | grep -o '"setup", "[^"]*"' OREAnalytics/orea/app/inputparameters.cpp |
ORE v1.8.17.0 3d75a6908 |
| Engine run settings held | 15, in 3 groups | projects/ores.reporting/modeling/ores.reporting.engine_settings*.org |
9838f83ef5 |
| Pricing engine product types | 104 | python3 over pricing_vocabulary.json |
9838f83ef5 |
| Pricing engine pairs | 194 | same | 9838f83ef5 |
| Distinct models and engines | 25 and 74 | same | 9838f83ef5 |
| Pricing parameter rows | 834, over 124 distinct names | same | 9838f83ef5 |
6. Notes
The record is Investigation: the two engine-facing configurations.
The two-line answer: the pricing engine configuration chooses and configures
the valuation method for each product type, and the engine run settings decide
how the engine prepares the inputs and runs the job for every product at once.
The run document joins them: its Setup block is the engine run settings, and
it names the pricing engine document through pricingEnginesFile.
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
The investigation is written: responsibilities, boundary, five overlap zones, five linkages, the data model and the UX of each, the naming collisions, five naming options against seven criteria, and ten rules the standard must carry.
Recommendation: name the first Pricing engine configuration and the second Engine run settings, and rename the pricing page's Settings tab to Parameters. The owner decides.