How should generated records be packaged for an environment loader?

Use a manifest as the entry point for the generated release. It can declare `release_id`, `schema_version`, `scenario_id`, `asset_paths` and `initial_state_ref`. Each asset declaration should identify its format and the schema that validates it.

Parquet can hold account, invoice, party and relationship tables. JSONL can carry messages, case events and task definitions. Policy text can be supplied as separate assets linked through stable `policy_id` values. Format choice should follow the loader's needs rather than force every record into one representation.

Define joins explicitly: `referral.account_id` resolves to an account, `message.case_id` resolves to a case and `task.initial_state_ref` resolves to a snapshot. Validation should reject missing required targets and duplicate primary identifiers before an episode starts.

MirrorFirm could also generate a compact dependency report identifying which assets each scenario needs. This allows a builder to load a single episode without importing unrelated scenarios.

The manifest should distinguish public task instructions from private simulation assets. An evaluation hook can check that the loader exposes only declared observations and that a reset reloads the same asset versions used at episode creation.