Create a claim ledger before production: exact wording, current source, scope, and the person responsible for confirmation. Review visual implications as well as spoken and written statements. If a claim has no adequate support, revise or remove it rather than making the presentation more confident.
Trace the statement to its source.
| Proposed statement | Evidence to request | Decision before production |
|---|---|---|
| “Works offline” | Current product documentation and a check of the relevant workflow. | State which actions work offline; do not imply the entire app does. |
| “Ready in seven minutes” | Defined start/end points and representative timing records. | Identify the measured scenario; do not generalize one run to every job. |
| “Every piece approved” | Asset-level final approval records for the stated delivery. | Name the delivery and distinguish final from first-pass approval. |
| “Customers love it” | Authentic feedback with permission and context. | Use a real attributable statement or replace it with a factual product description. |
These examples are review questions, not claims about the products shown on this site. Aitoma’s NAIARA story reports a specific final delivery approval count; it does not establish a general first-pass approval rate or an advertising outcome.
Record four fields for every material claim.
Keep the exact proposed wording, a link or file reference to the supporting source, the conditions under which it is true, and the reviewer responsible for confirming it. Add a checked date when the fact may change. Prices, offers, product screens, and availability need current references.
For an illustrative app, “Find an assistant for everyday questions” might be supported by the current app’s categories and screens. “The app solves every problem instantly” would require a different level of evidence and changes the promise completely. Editing should preserve the supported scope.
Review what the picture implies.
A visual can make a claim without saying a word. Showing a software button can imply the feature exists. Showing a product performing an action can imply it works that way. Showing an AI presenter speaking in first person can imply a personal customer experience.
Compare software screens with the current product. Use real demonstration footage where physical behavior is important. Keep illustrative presenters clearly distinguishable from actual customer testimony. The review should cover script, captions, product views, voice, and landing page together.
Resolve uncertainty before the final export.
| Finding | Practical response |
|---|---|
| Source is outdated | Request the current product reference and pause the affected scene. |
| Source supports a narrower statement | Use the narrower wording and retain its conditions. |
| Reviewer disagrees with the implication | Show the exact frame and proposed alternative, then record the decision. |
| No support exists | Remove the claim or use a demonstrable product fact instead. |
Do not hide a major qualification in tiny text while the headline makes the broader promise. The viewer should understand the same offer across the spoken line, on-screen text, and destination.
Keep the evidence with the approved version.
When the export is accepted, save the claim ledger with the asset version and reviewer decision. If the product changes later, this makes it possible to find which creative needs an update. Link the same record to localized versions, and review their meaning rather than assuming a literal translation preserves the claim.
This is a production accuracy workflow. Regulated product claims and market-specific requirements may need a qualified specialist. The checklist helps identify the statements that require that review; it does not replace it.
Work through a claim review.
Download the editable product-claim review workbook (XLSX). It includes a blank form and a worked example. Use one column per claim, including claims made by a picture, and keep wording decisions separate from checks on the exported video. No account is required.
Fictional teaching example. An invented task app lets people read previously saved task text offline, but editing requires a connection. That is the full relevant rule in the imaginary source, RULES-v4. The app, files, reviewers and review date in the workbook are invented; they do not describe Aitoma features or customer results.
| Claim in the first version | Decision from the source | Check on the replacement export |
|---|---|---|
| Voice and captions: “All your tasks work offline.” | Use “Read saved tasks offline. Editing needs a connection.” The original line implies more than the source supports. | In this exercise, v02 keeps the narrower wording and its condition in both voice and captions. This claim passes its check. |
| A task is edited successfully while an offline badge is visible. | Replace that action with a saved task being read. The picture implies an unsupported capability even if the voice is correct. | In this exercise, v02 still shows the edit succeeding. Record “Revise” and inspect the next export after the scene changes. |
| Closing overlay: “Save hours every week.” | No timing study or defined comparison was supplied. Remove the time-saving claim; the offline feature does not establish saved hours. | The removal has been requested but not checked in v02. Record “Pending,” then inspect the ending, captions and post copy. |
The video is still unresolved at this checkpoint. One verified claim does not cancel an inaccurate scene or an unchecked ending. Keep the exact export version and the open action beside each decision so the next reviewer knows what remains.
Use the record on your own content.
- Enter the asset version and timestamp, slide or text location. Record the exact words or describe the visual implication.
- Attach the current source and its version. Write the supported scope, including any condition the audience must understand.
- Record the wording decision, replacement, reviewer and actual review date. “Use replacement” means the wording was chosen; it does not mean the editor has made the change.
- Inspect the replacement export and record a separate result. Recheck the surrounding voice, captions and image together, then retain the unresolved actions.
- Duplicate a claim column or the sheet for more entries. Adjust row heights for longer notes. Add a recheck trigger when a product change, new offer or localization could change the meaning.
The workbook records human decisions; it does not verify claims automatically or calculate a publication score. Keep publication permission in the handoff record. Use the creative review worksheet for the other production checks on the complete piece.
Before approving a static product creative, use the AI product image review guide to check packaging, variants and the final placement. It includes a worked example and a review record.