Hold the behavior. Then lighten the structure.

Sequence

1. Read

   We lay out the tree, the build, the writes, the scheduled jobs, and the outside calls. The model is used to cover branches a person cannot read in one pass. People who know the system decide which path actually carries the business. What we cannot see in the code or the runtime is not written up as understood.

2. Pin the behavior

   Before the structure moves, we record inputs, outputs, and side effects on the critical paths. Characterization tests, log samples, and a parallel run all qualify. Without a comparison, replacement does not start.

3. Replace in small steps

   One boundary at a time. The old and new implementations run together until the comparison is stable, and until the day we can still go back has passed. Only then does the old path come out.

4. Review, then commit

   The model may draft a change in the style the repository already uses. A draft is not a merge. The engineer who reads the diff, runs the comparison, and commits owns that change.