Pointing at the Problem: How Row-Level Findings Work

The most common question after a worrying risk score is the practical one: which rows? A dimension score of 61 on distribution fidelity does not tell an engineer what to fix. Findings exist to close that gap — concrete records, with the column involved, a severity, the issue, and a sample value.

Findings currently come from a sample of up to 5,000 rows drawn from CSV, TSV, and JSONL sources. The sample is weighted toward regions the dimension scores flagged, so it functions less like a random audit and more like a guided biopsy: the cascade says where it hurts, the sampler goes there.

We are explicit about the epistemics. A finding is an existence proof — this specific record exhibits this specific problem. The absence of findings in a sample is weaker evidence, which is why an empty findings list on a columnar corpus renders as an explanation, not a green checkmark: parquet and arrow sources are not sampled yet, and full-file inspection is coming with our GPU pipeline.

Severity levels are calibrated to action: critical means fix before training, high means fix or consciously accept, medium and low are drift to monitor. The table exists to be triaged, not admired.

Sampling is a deliberate waypoint. The dimension scores already reflect the entire corpus through the cascade; findings are the drill-down layer, and their coverage will expand from sampled text formats to full-file, all-format inspection as the GPU pipeline lands. The design principle stays fixed: never let the interface imply more coverage than the math delivers.