Approval should belong to content, not a checkbox.

The failure

A source list is reviewed. A script is approved. Scene planning begins. Then somebody rewrites the last paragraph of the script. The project board still says “approved” because the checkbox is attached to the task or filename, not the bytes that were reviewed.

Nothing has crashed. Every tool is behaving as designed. The failure is semantic: downstream work is now being built from content that never received the recorded approval.

The smallest dependable approval record

An approval record needs four things: the gate name, the reviewer, the review time, and a deterministic fingerprint of every file covered by the decision. A SHA-256 hash is a common choice because the same bytes produce the same value and a meaningful edit produces a different one.

{
  "gate": "script",
  "approved_by": "editor",
  "approved_at": "2026-07-18T10:30:00Z",
  "files": {
    "script/script.md": "sha256:..."
  }
}

When the workflow is resolved later, hash the current file again. A match means the approval still refers to the current content. A mismatch means the gate is waiting for review. This does not decide whether the content is good; it only prevents an old decision from silently applying to new material.

Invalidation should travel downstream

A reopened script gate should block scene planning, narration, editing, and release when those stages depend on the script. That propagation requires an explicit dependency graph. Without it, each script must contain its own improvised logic for deciding what can run.

The resolver should answer two separate questions for every stage:

1. Are this stage's own required inputs and outputs present and current?
2. Are all upstream dependencies complete, including their approval gates?

Keeping those questions separate makes failures explainable. “Blocked because script is waiting for approval” is actionable. “Pipeline failed” is not.

What an approval gate cannot prove

A content fingerprint proves that the reviewed files have not changed since the recorded decision. It does not prove that sources are licensed, claims are accurate, narration is ethical, or a release is safe. Those remain human judgments. Good workflow software preserves the boundary instead of pretending to automate it.

Implementation checklist

• Normalize project-relative file paths before hashing.
• Refuse missing or empty files at approval time.
• Store the algorithm with each fingerprint.
• Record the reviewer as supplied metadata, not verified identity.
• Re-resolve dependencies every time status is requested.
• Make invalidation automatic and re-approval explicit.
• Never treat a hash as a substitute for editorial review.