Task: Curate the shared segment leaves
Table of Contents
This page documents a task in the Standardise the curve configuration's parameters on the one contract story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
Give the four leaves every segment kind shares — PillarChoice, DuplicatePillarPolicy, Priority and MinDistance — a contract row, so the screen documents them and the page stops reading 238 of 289.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Standardise the curve configuration's parameters on the one contract |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-30 |
3. Acceptance
- Each of the four leaves carries a curation entry with a label, a description, a reason and a source reference.
- The seed carries a row for each leaf under every segment kind.
- PillarChoice and DuplicatePillarPolicy take their ORE parser's list, not text.
4. Plan
1. Curate PillarChoice, DuplicatePillarPolicy, Priority and MinDistance in curve_term_curation.json, from the prose the ORE guide spends on them. 2. Link PillarChoice and DuplicatePillarPolicy to the parsers that read them, so the screen draws the closed list rather than a text field. 3. Regenerate the artefact and the value sets, and run the four contract checks.
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 |
|---|---|---|---|
| Parameters the seed holds | 2295, then 2343 | python3 projects/ores.sql/utility/generate_ore_parameters_dataset.py |
this branch |
| Rows the curation adds | 48 (4 leaves x 12 kinds) | git diff --stat projects/ores.sql/populate/reporting/reporting_ore_parameters_artefact_populate.sql |
this branch |
| Value sets | 224, then 226 | python3 projects/ores.sql/utility/generate_value_sets.py |
this branch |
| Leaves still without text | 167 | the generator's own report | this branch |
6. Notes
The extractor was never the problem. curve_terms.json holds PillarChoice,
DuplicatePillarPolicy, Priority and MinDistance for every kind, with the type and
default the ORE source states; the walk on 2026-10-30 suggests otherwise only
because a term without a text is not written as a row. The guide explains the four
once, in the simple segment's prose, and never lists them as items, so the
extraction has no item to attach the words to. That is what curation exists for,
and the same route landed ProjectionCurve.
The default the extractor read is what the screen shows: LastRelevantDate for the pillar choice, KeepLast for the duplicate policy, 0 and 1 for the priority and the minimum distance.
7. Result
The four leaves reach the contract for every segment kind: the seed grows from 2295 to 2343 parameters, 48 rows, and the two closed lists take their parser's values instead of text.
The walk on a database recreated from this branch and an Acme tenant provisioned for it reads 289 of 289 parameters carry documentation, where it read 238 of 289, and the segment card reads Pillar choice Default: LastRelevantDate., Priority Default: 0. and Minimum distance Default: 1. where it read three dashes. The entry carries no without documentation line.
8. 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 |
|---|---|---|
9. PRs
10. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|