A polished AI demo begins when the answer looks good: a prompt, a quick cut, and a finished result. That sequence can hide the details that decide whether it is a repeatable product behavior: which feature was active, what input was supplied, which version ran, and whether the output was altered before the camera returned. The brief should make those details part of the story. We are not asking for a lab report on screen; we are asking for enough continuity that a reasonable viewer can tell what actually happened.

A product demonstration shows a defined action through a defined interface; a concept visual explains a possibility. Both can be useful, but they cannot carry the same wording. The four-part brief is a production handoff, not a promise of repeatable behavior.

Part 1 — Make the action observable

Write one action the viewer should be able to see: “upload a synthetic invoice, ask for three fields, inspect the extracted table,” not “show how intelligent the assistant is.” Name the starting state, user action, system response, and visible result. Keep input and result in the same trace. If the tool needs a hidden permission, connector, or preloaded file, show the setup or disclose it in the brief.

On screen, reserve room for the control, input, state change, and output that supports the narration. Do not let a voiceover claim that the product searched, calculated, exported, or completed an action while the frame only shows a static end card. If loading time is removed, mark the omission in the edit notes. If the screen is recreated, call it illustrative; synthetic input is acceptable when identified, not presented as a customer file.

The proposal is simple: the first shot should answer “what went in?”, the middle should answer “what did the user ask the product to do?”, and the last should answer “what came back?” A demo can be short; it cannot be vague.

Part 2 — Freeze the version record

A viewer may not need every setting, but the production team does. Attach a source/version card to each take:

  • product and surface: app, API, plug-in, or workflow;
  • account, plan, region, and feature access where they affect the path;
  • exact model ID, snapshot, alias, app build, and API version;
  • prompt or instruction version, input identifier, tool mode, and relevant settings;
  • capture timestamp, take ID, output/run ID, and any source files.

Provider documentation explains why this is not bureaucracy. OpenAI says prompting behavior can change between model snapshots and recommends pinned versions; its API reference identifies the API version and request IDs for troubleshooting. OpenAI’s API overview and backwards-compatibility guidance A catalog entry is not automatically access. At this check, OpenAI describes GPT-6 Astra as rolling out to enterprises through a Trusted Access Program, with broader plan access coming later; listing, rollout notice, and account access are distinct states. OpenAI’s model catalog

Google’s Gemini documentation makes the same distinction: stable versions are specific, latest aliases can be hot-swapped, and experimental endpoints may change availability. Google’s Gemini model-version guidance Record the exact string and access state used for the capture. “The latest model” is not a version record.

Part 3 — Keep the cut honest

Continuity means a viewer can follow cause to effect. It does not require showing every second of a wait. Keep the raw screen recording and a timeline with timecodes for input, action, response, and result. Every cut should have a reason: waiting, privacy masking, a legibility zoom, or a clearly labeled illustrative shot.

Do not splice the prompt from Take 01 to the ideal output from Take 07 and leave the sequence looking like one run. If you combine runs, label each. If an editor corrects a captured typo, retain the original or label the correction. If narration describes an off-screen tool call, show a status indicator, result panel, or transcript that locates the step.

A proposed review pass asks: Can the reviewer identify the take that produced each result? Does the spoken sentence stay true after every cut? Could a viewer mistake a mockup, replay, or post-edited result for a live interaction? The first two answers must be “yes”; the third must be “no” before delivery.

Part 4 — Define the boundary

End the brief with the smallest statement the footage supports. “This run extracts three fields from this synthetic invoice in this configured workspace” is bounded. “This AI understands invoices” is a much larger claim. State whether the clip is a single capture, a selected successful run, a replay, or a montage. Never turn one smooth take into a reliability, speed, or universal-access claim.

OpenAI’s current help guidance says ChatGPT can produce incorrect or misleading outputs, may sound confident when wrong, and should be checked against reliable sources; it also notes that tool access and limits vary. OpenAI’s guidance on truth and limitations Treat those statements as a reason to show the review step, not as a disclaimer that excuses an unclear demo.

Put the limits in the handoff: what was not tested, whether the input was synthetic, whether a person selected or edited the result, and what availability or account condition the viewer would need. Stop when the starting state is hidden, the version cannot be recovered, the output is stitched from unknown runs, or the narration outruns the evidence. The clip is ready when another person can reconstruct the path from source to screen and see where it ends.

Sources and limitations

  1. OpenAI API overview and backwards-compatibility guidance — checked September 4, 2026; supports API-version and request-ID metadata, client request IDs, and the guidance that prompting behavior may change between model snapshots and pinned versions are recommended. Limitation: API metadata helps trace a request; it does not recreate an interactive app session or guarantee identical output.
  2. OpenAI model catalog — checked September 4, 2026; supports model IDs and aliases, listed tools, and the current rollout distinction for GPT-6 Astra between Trusted Access enterprise rollout and broader plan access described as coming later. Limitation: catalog status is provider documentation at check time; account, plan, region, and rollout can change.
  3. Google AI for Developers, “Models” — checked September 4, 2026; supports stable, preview, latest, and experimental naming, hot-swapping of latest aliases, and experimental availability changes. Limitation: endpoint availability and behavior can change; a model listing does not establish access in a specific account.
  4. OpenAI Help Center, “Does ChatGPT tell the truth?” — checked September 4, 2026; supports the possibility of incorrect or misleading outputs, confidence not equaling reliability, knowledge and tool-access limits, and the recommendation to verify important information. Limitation: this guidance concerns OpenAI products; it is not a benchmark or universal statement about every AI tool.