How does a mismatch case appear as structured data in a training pipeline?

A mismatch case can be represented as one JSONL line per case, with the working context linked by identifiers rather than embedded, so the same record is reusable across cases.

A typical case object carries:

- `case_id` such as `CASE-0412` and a `domain` tag - `record_refs`: the disagreeing records, each with `system`, `record_id` and an `as_of` timestamp - `discrepancy`: the field name, the value on each side and the signed difference - `root_cause`: a controlled label such as `keying_error`, `timing_difference`, `duplicate_posting` or `policy_variance` - `evidence_ids`: the records that support the cause, with decoys flagged as such - `authority`: the role and limit needed to act - `expected_outcome`: one of `correct`, `wait`, `escalate`, `write_off` or `no_action` - `downstream_refs`: linked items that should change when the fix is made

The referenced records sit in separate files, for example one Parquet table per system keyed by `record_id`. A join on `record_refs` rebuilds the working context for a single case.

Trajectory data, where included, adds a `steps` array holding the tool call, arguments, observation and a short rationale. The `root_cause` and `expected_outcome` fields are withheld from the model-facing view and held in a separate grader file. Schemas are versioned so a lab can pin the version it ingests.