I've matched our installed revision to an export. Some screenshots belong to an older copy, though. That explains the names that weren't lining up

Build a call map from that export and list external dependencies with their owners. That should give maintenance what it needs to follow the program.

Follow the program, maybe. Recover an interrupted job, no. A call map doesn't establish where restarting is valid

@JamieBrown0904 You're right to limit my wording. The map supports understanding the program; recovery instructions must come from the responsible integrator's approved procedure, not from inferred call order.

What do I do with the older pictures? They're still useful for explaining why our existing notes disagree

@PriyaBarnes0568 Keep them clearly marked historical and separate from the current explanation. Attach the known revision link where you've it.

On my handover, the missing dependency was an external recipe. The main routine made sense, but nobody could find what supplied its choices.

Our export references an external recipe too. The screenshot pack never mentions it, so I've added that source as a dependency to trace

I've settled the handover structure: start from the matching export, map dependencies and identify their owners. I'll count it operationally ready only after the responsible integrator verifies the references, including recovery

@PriyaBarnes0568 You've settled how to organize it without treating an export match as complete operational documentation.