What schema and action contracts could support generated customer changes?

A package could contain `customers`, `change_requests`, `dependent_records`, `propagation_jobs` and `audit_events`. A change request might carry `request_id`, `customer_id`, `change_kind`, `requested_value`, `status` and `policy_version`. A dependency edge can identify a source field, target record and propagation rule.

Use stable identifiers such as `REQ-2187` and `JOB-0412` across snapshots and events. Parquet can hold initial tables, while JSONL can carry ordered requests and action results. A schema should state nullability, enumerated values and referential constraints, including whether a missing relationship is valid or erroneous.

MirrorFirm could also generate contracts for actions such as `validate_request`, `apply_change` and `retry_propagation`. Contracts should define preconditions, returned errors and transaction boundaries. If updating the source creates a propagation job, specify whether both operations commit together.

An idempotency key can prevent a repeated tool call from creating duplicate work. A record version can reject a stale write. These details make the generated material usable as interactive state: the builder can implement what each action means, rather than merely loading documents that describe an intended process.