
Download the tested Ten-Minute Reset MP4 to inspect the encoded result rather than relying on screenshots alone.
The production contract
| Input or gate | What must be true | What it prevents |
|---|---|---|
| Complete script | Facts, numbers, qualifiers, cautions, order, and call to action are present | Quietly dropping meaning to hit a duration |
| Final voiceover | The exact recording used for review is the recording placed in the render | Timing a draft voice and replacing it later |
| Voice alignment | Every semantic unit has measured start, keyword, and end times | Average-speed timing and cumulative drift |
| Studio approval | The user hears the final voice while reviewing the actual composition | Rendering before story, layout, and synchronization are accepted |
| Encoded-file QA | The MP4 itself is probed, watched, sampled, and hashed | Calling a successful render command a finished video |
Worked 30-second example: The Ten-Minute Reset
This original 79-word script is deliberately low-risk: it makes no medical, financial, legal, or research claim. In the retained test, its five natural-speed narration segments totaled 28.500 seconds. The final video is 31.700 seconds after the deliberate end-card hold; no global speed change was used.
Big plans can feel productive, but they often delay the first move. Try a ten-minute reset. Choose one task you can actually finish. Close every tab that does not help. Put your phone out of reach. Start the timer and work only on that task. When it ends, stop or choose the next ten minutes on purpose. You do not need perfect motivation. You need one finished step that proves you can move. Start small. Finish once. Then build.
Use one blue timer ring as the recurring visual object. First it replaces an oversized plan, then isolates one task, pushes irrelevant tabs and the phone away, becomes the progress path, and finally locks into the end card. Keep the main visual vertically centered with balanced top and bottom negative space. Keep THE TEN-MINUTE RESET fixed above a thin blue line throughout the video.
| Semantic beat | Main visible action | Supporting text | Retained audio treatment |
|---|---|---|---|
| Big plans delay the first move | An overbuilt plan expands, jams, and collapses into one clean blue ring | BIG PLAN / FIRST MOVE | Voice only |
| Try a ten-minute reset | The ring becomes a ten-minute dial and moves to the visual center | 10:00 RESET | Voice only |
| Choose one finishable task | One task tile locks inside the ring; other tiles move out of focus | ONE TASK | Voice only |
| Remove distractions | Browser tabs close in sequence and the phone slides beyond the boundary | CLOSE / MOVE / START | Voice only |
| Work, then choose again | The timer traces a path to one completed step, then reveals a deliberate fork | STOP or CHOOSE | Voice only |
| Finish once, then build | The completed step repeats into a rising path while the timer becomes the end-card frame | START SMALL / FINISH ONCE / THEN BUILD | Voice, then a silent 3.2-second hold |
Those rows define meaning and order, not timing by word count. The retained build uses measured delivery intervals of 0.000–4.373, 4.373–8.682, 8.682–12.671, 12.671–19.647, and 19.647–28.500 seconds, followed by the end card through 31.700 seconds. If another approved narration lasts 32.4 seconds, build around that audio rather than compressing the entire timeline to 30.0 seconds.
Step 1: lock the script and the final voiceover
Save the approved text and the exact audio file in the project. Record its original filename and SHA-256 before converting anything. If the script and audio disagree on a word, number, negation, order, or missing sentence, stop and resolve that difference. A punctuation-only difference can be documented without blocking.
ffprobe -v error -show_streams -show_format -of json final-voiceover.wav
shasum -a 256 final-voiceover.wav
Inspect duration, codec, sample rate, channels, leading silence, first-word start, last-word end, trailing silence, peaks, clipping, and incomplete syllables. If a 48 kHz working WAV is useful, keep the original and verify that conversion does not move the first or last word.
Step 2: transcribe, correct, and build a real timing map
HyperFrames can accept audio during project initialization and produce transcript timing. Choose the actual language; an English-only model is wrong for another language. Automatic recognition is only a timing aid: correct its text against the approved script without relabeling ASR or provider timestamps as forced alignment. Use a true forced aligner when the risk or required precision justifies that stronger method.
npx hyperframes init ten-minute-reset --example blank --resolution portrait --audio ./final-voiceover.wav --language en --non-interactive
npx hyperframes transcribe ./final-voiceover.wav --model medium.en --language en
Create VOICE_ALIGNMENT.md with one row per semantic unit: timing provenance, voice start, keyword time, voice end, pause length, caption interval, main visual response, and allowed error. The retained sample records provider/ASR-derived word times, clamps four small ASR end overshoots to probed WAV duration, and states plainly that this is not forced alignment. Check near one quarter, one half, three quarters, and the last sentence; matching total durations cannot detect cumulative drift.
Step 3: create the project records before animation
SCRIPT.md: final narration, changes, measured audio facts, and caption units.VOICE_ALIGNMENT.md: audio hash, corrected transcript, word or sentence timing, pauses, visual responses, and drift checks.STORYBOARD.md: narration and keyword times joined to action, micro-motion, transition, color, focal center, and sound.DESIGN_DECISIONS.md: palette, typography, motif, layout, motion verbs, revisions, and review decisions.MEDIA_LEDGER.md: every local font, image, audio file, library, version, source, license status, path, and hash.PUBLISH_COPY.md: clean narration and destination-ready caption copy.CHARACTER_BIBLE.md: identity, poses, outfit, line hierarchy, and prohibited changes when a recurring character appears.
Each storyboard row needs a main visual action. “Show subtitle” is not enough. A path should have an origin, direction, destination, and response. An object comparison should keep the object anchored while the arrows, environment, or states explain the choice.
Step 4: set a readable vertical visual system
A practical default is 1080 by 1920 at 30 fps on warm gray #F8F9FA, with graphite #202124 text and Google blue #4285F4 for structure. Green can mark completion, yellow can mark attention, and red should be a small risk signal. Give each scene one dominant accent and at most one supporting accent.
Protect at least 72 pixels on the sides, approximately 220–280 pixels at the top, and 440–520 pixels at the bottom for platform UI. Keep the main visual group centered in the usable region rather than merely centering its DOM box. For this sample, the fixed title and blue line live above the active picture; the timer, task, phone, and completion path share a stable center below it.
At 1080 pixels wide, use roughly 72–96 pixels for the title, 58–76 pixels for a central conclusion, and 48–58 pixels for captions. Treat 26 pixels as a hard floor for necessary labels. Check contrast during entry and exit animation, not only on static endpoints.
Step 5: animate meaning on one deterministic clock
Choose one recurring geometry and two to four motion verbs. The Ten-Minute Reset uses ring transformation, object locking, path drawing, and environment clearing. Keep the identity consistent but change the physical use: the ring can establish the problem, become the timer, measure progress, and frame the conclusion without repeating the same full-screen zoom.
Every rendered state must be determined by seek time. Avoid live clocks, uncontrolled timers, runtime network requests, hover state, infinite loops, and unseeded randomness. Freeze fonts, animation libraries, images, icons, narration, music, and sound effects locally. HyperFrames' engine seeks to exact times and captures frames, but the official documentation still advises pinning Chrome, fonts, codecs, GPU behavior, and the host when exact pixels matter.
Step 6: run the strict browser gate
Run fast lint first, then use the current unified browser check in strict mode. HyperFrames documents checks for runtime errors, failed requests, layout, motion assertions, contrast, and snapshots in one browser session.
npx hyperframes lint .
npx hyperframes check . --strict --samples 15 --snapshots --at 0.1,1.2,2.5 --at-transitions --frame-check
Add every sentence start, keyword, sentence end, transition seam, densest frame, completed end card, and final frame to the explicit sample set. Inspect the original-size images. Fix warnings as well as errors. Automated checks do not judge whether a face is attractive, a metaphor is understandable, or a pause feels natural.
Step 7: open Studio and stop for approval
npx hyperframes preview
The preview must play the same final voiceover that will be rendered. Ask the reviewer to watch the first three seconds, sentence starts, keyword responses, sentence endings, visual centering, persistent title, captions, transitions, character consistency, and end card. Do not render until the reviewer approves, unless the original request explicitly said to render directly.
The retained sample followed the authorized direct-render branch, so it has automated and encoded-file evidence but no independent human Studio approval. A client or editorial release should still pause here unless direct rendering was explicitly requested.
Step 8: render, then audit the encoded MP4
npx hyperframes render --quality high --strict-all --output ten-minute-reset-final.mp4
ffprobe -v error -show_streams -show_format -of json ten-minute-reset-final.mp4
shasum -a 256 ten-minute-reset-final.mp4
Read back actual duration, dimensions, frame rate, video codec, pixel format, audio codec, sample rate, channels, and bitrate. Check the encoded voice start, last word, and representative sentence boundaries. Scan for unexpected black frames, blank tails, long freezes during speech, and unintended silence. Extract at least eight or nine frames from the MP4 and compare them with the preview, including 0.1 seconds, the opening event, the conflict, transition seams, the densest frame, the conclusion, the assembled end card, and the final frame.
Failure patterns worth stopping
| Failure | Why it happens | Recovery |
|---|---|---|
| The video ends at 30 seconds but drifts sentence by sentence | Timing was distributed by average speed | Rebuild from measured semantic boundaries and check cumulative offset |
| The image completes an idea before the keyword is spoken | The visual result was timed to the scene, not the word | Keep the preparation, move the visible peak to the keyword |
| The fixed title crowds the active scene | CSS centering ignored the usable safe region | Center the complete title-line-action group and inspect original-size frames |
| Text becomes unreadable during its exit | Opacity mixes it with a complex background | Prefer mask, scale, or translation exits and hide at a deterministic boundary |
| The final frame is blank or half-built | The internal animation ends before the composition | Hold the complete end card through the exact final frame |
| A successful render is reported as publish-ready | The command result replaced encoded-file review | Probe, watch, sample, compare, and hash the actual MP4 |
What the completed handoff should contain
At preview stage, report measured voice timing, expected composition duration, scene count, visual direction, Studio address, strict-check result, synchronization result, and an explicit not rendered state. After approval or an authorized direct render, add the absolute MP4 path, real media parameters, original-speed confirmation, sentence-level synchronization result, black-frame and freeze review, extracted-frame result, SHA-256, and every project-document path. For the retained MP4, the SHA-256 is 0d29144513ccd0160e9abe1433d21d3b24bd1fc8ae4c794e5c4421c8471ba12e.
The method is intentionally strict about what counts as done. A prompt is reusable instructions. A skill is reusable workflow guidance. A project is editable production state. A preview is a review opportunity. Only the inspected encoded file can support a final-video claim.
