A file can exist and still be wrong.

Three different questions

Staleness bugs happen when one signal is asked to prove too much. File presence, modification time, and content fingerprints answer different questions:

• Presence: does the declared path contain a non-empty file?
• Modification time: is an input newer than an output derived from it?
• Content fingerprint: are these exactly the bytes that were previously reviewed or recorded?

A dependable resolver combines them instead of declaring one universal winner.

Use timestamps for derived outputs

If script.md is newer than scenes.json, the scene plan may have been built from an older script. The conservative result is “stale.” Modification times are cheap and work well for this build-system-style relationship.

latest_input_time > earliest_output_time
= output may be stale

Timestamps are not proof of semantic change. Copying, restoring, or touching files can alter times without altering content. Some tools also preserve timestamps. That is acceptable when the desired behavior is conservative: unnecessary rebuilding is safer than silently advancing obsolete work.

Use hashes for reviewed content

An approval needs a stronger question: “Are these the same bytes the reviewer approved?” Store a cryptographic hash at approval time and compare it with the current hash. This catches an edit even if the filename is unchanged.

Hashing every large media asset on every status check can be expensive. Apply fingerprints where exact identity matters—source lists, claims, scripts, QC reports, manifests, and release inputs—then use timestamps for ordinary derived-output freshness.

Dependency state matters too

A perfectly current rough cut should still be blocked if its script gate reopened. A stage is not safe merely because its own files look fresh. Resolve upstream stages first, then derive downstream state from both file freshness and dependency completion.

Make the reason visible

State without explanation is difficult to trust. Return both a stable status and a human-readable reason:

script      waiting_for_approval  reviewed content changed
scene_plan  blocked               waiting for script
rough_cut   blocked               waiting for scene_plan

This lets a person act without reading implementation details. It also makes automated reporting safer because the system can describe why it stopped instead of inventing recovery steps.

Implementation checklist

• Reject absolute paths and parent-directory escapes.
• Treat missing and empty outputs as incomplete.
• Compare the newest required input with the oldest required output.
• Hash exact approval inputs and store the algorithm.
• Resolve dependencies before declaring a stage runnable.
• Return a reason with every non-complete state.
• Prefer conservative false positives over silent stale work.