Task: Read the metric outputs

Every metric family is read by one declaration-driven reader into rows of subject, observation date, measure, qualifiers and value.

• One reader serves every family whose row shape is metric, and no family has a reader of its own.
• A row becomes one metric for each measure column, named by that column's heading, so a curve or a risk factor is a measure name.
• A qualifier travels with the metric, and Currency is the metric's currency rather than a measure.
• The reader refuses a file that omits a required key or states a figure it cannot read, and names the heading that failed.
• The tests read a checked-in expected output of every metric family.

One reader, driven by the roles the catalogue states. It checks that every required column is present and refuses the file if one is not; it takes each measure column and emits one metric named by that heading; it carries the qualifiers and promotes the subject and the observation date out of the keys.

Three rules are the corpus's, not the design's. A figure the engine states as its null string is not a metric and not a refusal. A heading the catalogue does not state is a measure in an open family and a refusal in a closed one. And a row's key can be empty: the corpus states a netting-set total with no trade id, so the subject is chosen for each row from the keys it does state, and the figure is kept.

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.

The reader is generic on purpose. ORE declares its columns imperatively and adds them in loops over the configuration, so a family's shape is not a fixed list; a reader per family would be sixty readers that disagree with each other and with the samples.

• The reader refuses only what it cannot read. A null figure, a row without its trade id and a stale subset of a family are all things the corpus states, so they are read rather than rejected.
• A family with no measure columns is not a metric family: the calibration report states text beside a key, and it is market state, which the marketdata task stores.
• The five payload families (the scenario dumps and the cubes) are left to the marketdata task; this reader is not the right one for a 789-column file.

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.

One reader serves every metric family, and a sample of each reads whole: 55 families, no refusal, 158 assertions over 11 cases.

What the corpus taught the reader, and therefore what the record now says:

• A null figure is not a metric and not an error. The engine writes #N/A, and a second test proves a row with one null measure keeps its other three.
• A row's key can be empty. xva.csv states a netting-set total with no trade id, so the subject is chosen for each row from the keys it states, and the figure survives as a netting-set metric.
• An open family accepts a heading the samples never showed: a new curve is just another measure. A closed family refuses one, and names it.
• A file that omits a required column is refused before a row is read.

The three child-row families and the five payload families are excluded on purpose, and the record says which task takes each.