Separate presenter footage from software proof
An AI presenter or reaction can introduce a task. It cannot establish that a software feature exists. Use genuine approved app recordings for product evidence and keep generated interface pixels out of the proof sequence.
The failure cases below are original illustrative review scenarios. They are not results from generated clips, provider evaluations or proof that a particular model passes or fails. Actual footage still needs a real review.
Inspect identity, motion and contact points
Watch at normal speed, then inspect suspicious intervals frame by frame. Compare the presenter against the approved identity reference where one is used. Look for changes in facial structure, clothing, hands, object contact, background geometry and motion continuity.
Pause at the beginning, end and transitions. A convincing still does not establish that the complete clip is usable. Record timestamps and the specific observed problem rather than writing “looks off.” Keep source scene instructions and identity references distinct in the review record.
Presenter
GENERATED REACTION Review identity and motion
Evidence
GENUINE APP RECORDING Show the real task
Decision
ACTUAL EXPORT Accept / revise / reject
| Decision or state | Example | Review |
|---|---|---|
| Identity drift | Face changes after the turn | Reject the affected interval; inspect a replacement. |
| Hand contact | Fingers merge with an object | Reject or replace the shot; do not imply clean output. |
| Invented interface | Generated dashboard shows a result | Replace proof with a genuine app recording. |
| Wrong lettering | Caption changes a feature name | Correct exact text and inspect the export. |
| Unsupported claim | Narration promises unverified savings | Revise claim; seek evidence or remove it. |
| Broken handoff | Presenter points at an unrelated screen | Revise timing/composition; preserve the real task. |
Treat text and claims as separate gates
Check every visible and spoken claim against the real product and eligibility. Exact captions should be reviewed as editable text and again in the export; do not assume generated lettering is accurate. Avoid simulated testimonials, invented customers and unsupported outcome claims.
When a face or gesture is acceptable but a claim is wrong, changing the music does not fix it. Correct the script or edit the problematic interval. When the footage itself fails, reject that segment rather than hiding a defect behind fast cuts.
Record the decision on the actual revision
Use accept, revise or reject with a reason and timestamp. Accept only the use case actually reviewed: an approved reaction shot does not approve a longer narration or a new product claim. Keep source, edit and export revisions linked.
Finally watch the joined presenter-and-demo export on desktop and phone, with and without sound. Check the transition into genuine software footage and the next-step destination. This rubric helps organize review; it does not certify production quality or replace permissions and applicable disclosure review.
Copy the planning worksheet
Use this worksheet in your own notes. Fill it with verified product details and actual review observations before sharing an asset.
Use case / approved identity reference:
Source and export revisions:
Timestamp / observed issue:
Identity, motion or contact check:
Real app evidence for each claim:
Exact text and eligibility review:
Accept / revise / reject with reason:
Joined export desktop / phone / sound-off review:
Reviewer and approved scope:Browse the founder guide library for the next task in your workflow.