← All documentation

The kinds of job

A demo, a re-render, a refresh, an edit, an import and a scripted job each walk their own line through the same phases.

Every video in your library is a job, and every job has a kind. The kinds are demo, rerender, import, scripted, refresh and edit. They walk their own lines through the same set of phases, and the difference between them is exactly which passes they run.

This page is the vocabulary the rest of the docs uses.

demo

queued → discovering → capturing → compositing → uploading → done

The original. You give a URL and an intent line; discovery explores the app and writes a plan; capture films it. This is what the composer makes.

rerender

queued → capturing → compositing → uploading → done

The same video again, from the stored plan. No exploration, no model call, no new decisions — the plan is seeded from the source's stored artifact and replayed. It is what you press when the render itself went wrong, or when you want the identical demo at a different tier.

Because it re-films the app, it does reflect whatever the app looks like today; because it re-uses the plan, it clicks exactly what it clicked before. If the app has moved, that is a re-shoot's job rather than this one's.

refresh

queued → discovering → capturing → compositing → uploading → done

"The UI changed — shoot it again." The full demo line including discovery, from the source's own URL, intent, tier, format and finishing. It explores the live app from scratch, so it produces a new plan rather than replaying an old one.

Available on a finished demo, refresh or rerender that has a URL. It is deliberately not offered on a scripted job, whose plan a person wrote by hand — re-discovering would discard that work.

edit

queued → capturing → compositing → uploading → done

What the step editor ships. The source's plan with your changes merged in — retyped narration, trimmed beats, camera picks, masks, per-beat sound, the look, the finishing, the voiceover switch — stored under the new job's own key and replayed from there.

It re-films the app, which is why it is a capture and not just a re-composite: the trims and the camera moves apply to fresh frames.

import

queued → uploading → done

Somebody else's file. Your browser uploads an MP4 straight to the job's own storage key on a signed URL, and the worker checks it: size at most 500 MB, content type video/mp4, and a probe that reads its real duration and dimensions. A poster frame is grabbed from it.

Nothing is discovered, nothing is captured and nothing is composited — the uploaded file IS the artifact. An import therefore has no plan, no beats, no editor, no captions and no guide. What it does get is everything about distribution: a library card, a title, a project, a share link, an embed and audience analytics.

You can trim an import before it uploads, in the browser, so the bytes that leave your device are already the cut you want. Trimming only the end is a fast remux; moving the start point re-encodes. The shortest clip a trim may leave is 1 second.

scripted

queued → capturing → compositing → uploading → done

A complete plan supplied by the caller through the API, rather than discovered. It walks the re-render line with no model call at all. It is how the calibration rigs and hand-authored demos are made; it is not something the web app offers a button for.

What they share

  • Every kind writes the same status line to the same build log, and every kind can fail from any non-terminal status.
  • Every kind lands in a workspace, and a derived job lands in the SOURCE's workspace rather than wherever you happen to be looking. See Workspaces and members.
  • Every kind counts once against your daily allowance, at creation — except the automatic re-shoot after a failed capture, which is a delivery of something already paid for rather than a new creation.
  • Every derived job records which job it came from, which is what Version history reads.