How should policy propagation appear in an environment's state model?

Represent the policy change as an entity with its own lifecycle. A generated change record can contain `change_id`, `policy_id`, `from_version`, `to_version`, `publication_status` and `propagation_status`. Publishing the document changes publication state; it does not automatically mark operational adoption complete.

Use separate application records to connect the change to business objects. Fields such as `target_id`, `assessment_status`, `required_transition` and `completion_evidence_id` let the environment distinguish an unassessed case from a case assessed as unaffected. That distinction prevents an empty work queue from becoming accidental proof of completion.

Actions such as `list_change_targets`, `assess_target` and `record_application` can advance these records through defined transitions. Each action should return the resulting state and any unresolved condition, giving the agent feedback it can use on its next turn.

MirrorFirm could generate the entity graph and transition definitions for a selected domain. Builders can initialise them from JSONL and expose them through their own tool layer. This structure makes propagation inspectable as work performed, with incomplete adoption remaining visible even after the new policy is publicly readable.