Skip to content
MirrorFirm

What record fields and schema can a mismatch case file use?

Sets out a possible JSONL shape for one mismatch per line, with linked records, evidence, policy references and separated ground truth, plus tool action naming.

A case-level file in JSONL can hold one mismatch per line. A possible shape:

- **case_id:** stable identifier such as CASE-0412. - **domain:** insurance, banking, utilities, logistics or retail. - **record_a** and **record_b:** objects with record_type, record_id, source_system, amount or quantity, date and reference. - **links:** array of related ids, such as customer, account, batch, document and prior case. - **evidence:** array of notes or documents with type, author_role and text. - **policy_refs:** ids pointing to rules in a separate policy file. - **ground_truth:** cause_label, expected_action, expected_end_state and an escalate flag. In evaluation releases this sits in a separate file so it is not shown to the model. - **difficulty_tags:** for example multi_cause, decoy_record or missing_evidence.

Large tables, such as full ledgers or event logs, suit Parquet, joined to cases by record_id. Policies suit a JSON file keyed by rule id. Each file ships with a schema description so your customers can validate on ingest.

For environments, the tool surface can be described as actions with names, argument schemas and return types, for example search_records, get_history, post_reversal, raise_adjustment and escalate_case. Treat this as a starting shape; the exact fields come from scoping.

A per-case JSONL file with stable identifiers, separate ground truth and a published schema lets your customers validate on ingest and join to larger tables.

Audience:
Licensed resellers
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch