How can generated change records be packaged for evaluation pipelines?

A release can package change requests as JSONL and larger entity snapshots as Parquet. The two formats can share stable identifiers so a runner can assemble each task without relying on row order or display text.

A change event could include `change_id`, `customer_id`, `target_entity_id`, `field_path`, `requested_value`, `effective_at` and `source_message_id`. A separate dependency table can link `upstream_entity_id` to `downstream_entity_id` with a `dependency_type`. Schema definitions should specify nullable fields, timestamp conventions and allowed enumerations.

Expected outcomes belong in an evaluator partition keyed by `task_id`. Keep that partition outside the agent's input bundle. A manifest can identify schema versions, file checksums and the snapshot associated with each event. Validation can reject missing references, unsupported enum values and events whose target does not exist.

MirrorFirm could scope exports and environment imports around the same contract. Evaluation teams should request a round-trip check: export a task, load it into the intended runner and compare its reconstructed starting state with the supplied snapshot. This tests portability independently of the agent's performance.