How could complaint records be packaged for an evaluation pipeline?

A release could use JSONL for message and task records, with Parquet for case, issue and relationship tables. The format choice should follow the buyer's loader and inspection tools rather than change the meaning of the records.

A case schema can include `case_id`, `received_at`, `policy_version_id` and `owner_role_id`. Separate issue records can use `issue_id`, `case_id` and `issue_category`. An evidence-link table can connect `issue_id` to `record_id` with a relationship such as supports, contradicts or supersedes. This avoids forcing every concern into a single case-level finding.

A manifest can declare schema versions, required files, timestamp conventions and allowed enumeration values. Import checks should reject orphaned references and distinguish absent fields from explicitly unknown values. Stable identifiers allow a buyer to join records without relying on text similarity.

Expected decisions and scoring annotations can sit in a separate evaluator package, linked through `task_id`. MirrorFirm could generate both packages to an agreed contract. The runner should expose only the authorised input bundle to the agent, preventing answer annotations from entering retrieval results or tool responses.