Skip to content
MirrorFirm

What fields and file formats can a generated mismatch pack use?

Cases can ship as JSONL with record tables in Parquet or JSONL, and with a deliberate split between agent-visible files and grader-only files.

A mismatch case can be delivered as JSONL, one case per line, with record tables alongside as Parquet or JSONL. A typical case object carries these fields:

- case_id, such as CASE-0412 - domain and cause_class, with cause_class held in grading files, not agent-visible files - left_record_id and right_record_id, each with a system name and a primary key - observed_difference: amount, unit and direction - snapshot_ref: the identifier of the starting state the case runs against - policy_refs: IDs of the tolerance and approval rules in force - allowed_tools: the tool names exposed for the task - acceptable_end_states and unacceptable_end_states: lists of predicate IDs - rationale: a short text explaining why

Record tables carry a stable primary key, a valid_from and valid_to pair where history matters, a source_system field, and foreign keys such as external_ref or parent_id. Links between the two sides are intentionally imperfect where the scenario calls for it, so a join may need normalisation of reference formats.

Policies ship as a table with rule_id, subject, threshold, role_required and effect.

Splitting agent-visible and grader-only files is the main design choice. Keep cause labels, expected trajectories and predicate definitions in a separate grading file that never loads into the agent's state. Parquet suits wide record tables loaded in bulk; JSONL suits cases and traces. Ask for a schema file with types and nullability so loaders can validate before a run.

Separating agent-visible state from grading files, with typed schemas, lets you validate and load a pack before any agent run.

Audience:
Environment builders
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch