Quality Is a Contract: Checkpoints, Promises, and Reviews

OpenMontage treats quality as a lifecycle rather than a final glance at an MP4. The useful question is what each control catches: a checkpoint preserves state, a delivery promise protects the kind of video approved, a risk scorer surfaces warning signs, and a post-render review inspects the file that actually exists. Understanding those boundaries lets a reader judge whether a run is resumable, honest, playable, and still in need of human judgment.

This matters because a technically valid video can still be the wrong video. It may contain a video stream but no audible narration, satisfy its duration while breaking the approved motion treatment, or pass through a renderer with a visual rhythm that feels like an animated slide deck. OpenMontage's quality system is an attempt to keep those failures visible at the point where they can still be corrected.

A checkpoint preserves both progress and decisions

A checkpoint is a saved state at a production boundary. It records the stage, its canonical artifact, relevant review information, and often a cost snapshot. When a stage requires human approval, the checkpoint must remain in an awaiting state until approval is recorded; the agent is not allowed to mark the gated stage completed merely because it produced an artifact. The checkpoint implementation also validates predecessor stages, so a later stage cannot be declared complete while the required earlier work is missing or unapproved.

The lifecycle distinguishes several situations that are easy to blur in an informal workflow. An in_progress state can report that a long operation is underway or partially complete. A review state tests the artifact against the manifest and other constraints. An awaiting_human state means the system has reached a deliberate pause. A completed state means the stage can be treated as a valid input to the next stage. Revision sends work through the stage again, while failure or a blocker means the intended path cannot safely continue without a changed condition or an explicit decision.

stateDiagram-v2 [*] --> in_progress: Stage entered in_progress --> review: Artifact or partial work ready review --> awaiting_human: Gate required awaiting_human --> completed: Approval recorded awaiting_human --> revision: Feedback requested review --> completed: Checks pass review --> revision: Issue found revision --> in_progress: Prior version archived in_progress --> failed: Blocker or interruption failed --> in_progress: Resume from latest checkpoint

The archive is as important as the current file. When a checkpoint is replaced after a revision or gate transition, the earlier non-progress checkpoint is retained in history. That means a revised artifact can become the current input without erasing what was previously approved, rejected, or awaiting a decision. A decision log adds another layer of continuity by preserving major choices such as provider, style, music, voice, or runtime selection in an append-only project record.

Resumability and auditability are related but different. Resumability asks, “Where can execution continue without repeating valid work?” Auditability asks, “What changed, when, and under which decision?” A partial asset run may need the first; a provider swap or a user-requested revision needs the second. Checkpoints and history support both, but neither guarantees that a human will interpret the record correctly. They preserve evidence; judgment still has to use it.

Backlot makes this persisted state easier to see.