Editing Generation Prompts
Every prompt the platform sends to a model is editable by an admin, from the screen where that prompt actually runs. There is no separate prompt page — a prompt you cannot see next to the thing it produces is a prompt nobody tunes.
Requires the Manage prompts & styles capability (prompts.manage).
Where the prompts are
Section titled “Where the prompts are”| Surface | Button | Prompts you get |
|---|---|---|
| Studio configuration sheet (Audio, Video, Infographic, Slide Deck, Document) | Prompts in the header | Every stage that asset runs, in pipeline order |
| Source Files panel on a project | The code icon in the panel header | The summary prompt that reads each uploaded file |
| Storyboard editor, before Finalize | Prompts in the toolbar | Storyboard, and the Veo shot prompt used at render |
| Audio script editor, before Generate Audio | Prompts in the toolbar | Topic detection → outline → script |
Multi-stage assets show their stages as a chain. Audio, for example, runs topic detection, then the outline, then the script — editing the script prompt without seeing that the outline shaped its input is how people tune the wrong stage.
Template and Rendered
Section titled “Template and Rendered”The panel has two tabs, and the difference matters.
Template is what you edit: the prompt with its {variables} still in place.
Rendered is what the model receives: the same prompt with the variables filled in from the configuration you are looking at and from your project’s real source chunks. Below the render, greyed out, is the block the pipeline appends itself — the invariants it needs to parse the result. That part is not editable.
Some values only exist part-way through a run. The outline that feeds the script
prompt, for instance, does not exist until the outline stage has run. Those appear
as ⟨resolved at runtime: outline⟩ rather than as a plausible-looking invention,
so you are never tuning against a fiction.
You edit the template, not the render. Saving rendered text would bake one project’s evidence into a prompt that publishing then ships to everyone.
The loop
Section titled “The loop”- Edit the template.
- Save draft. This creates a new version, unpublished. Nobody else is affected.
- Generate. The asset generates using your draft. The button on the configuration sheet does this directly; on the storyboard and script editors use Regenerate with draft, which re-runs that stage with the same settings as the original job so the prompt is the only thing that changed. For the ingestion prompt, reprocess a source file.
- Look at the result. Not good enough? Edit and save another draft.
- Submit for approval when it is. Someone else then approves it, and only then does that version become the baseline for everyone on the platform, for every future generation of that asset.
A draft only ever reaches a model when a generation explicitly asks for it by id. There is no state where an unpublished draft is quietly live for other users.
Who can do what
Section titled “Who can do what”Two capabilities, deliberately separate:
- Edit prompts & save drafts (
prompts.manage) — read the inspector, edit, save drafts, generate against them, submit one for approval. - Approve prompt publishes (
prompts.approve) — decide on a submitted version.
Administrators and Comms Lead / Reviewers hold both by default. Holding both does not let you wave through your own work: the person who submits a version can never be the person who approves it, super-admins included. If you are the only eligible approver, the request waits — there is no bypass.
Approving a publish
Section titled “Approving a publish”Admin Controls → Prompt Approvals is the queue. Each request shows the diff against the prompt that is live right now, who submitted it and when, their note, and every asset type that runs the stage — a published prompt has no per-project scope, so it lands on every project at once.
Approve makes it live immediately. Reject requires a reason and leaves the live prompt untouched; the rejected version stays in history with the reason attached, and the submitter can revise and resubmit. Withdrawing your own pending request is just deleting the draft.
Every step is audit-logged with the actor, timestamp, IP, both texts, and the
impacted asset types: PROMPT_PUBLISH_REQUEST, PROMPT_PUBLISH_APPROVE,
PROMPT_PUBLISH_REJECT, PROMPT_PUBLISH_WITHDRAW.
Version history
Section titled “Version history”The clock icon opens every version of that prompt, newest first.
- Baseline is v1, the text the platform shipped with. It cannot be deleted.
- Live is whichever version is currently published.
- Use loads a version into the editor and marks it as the draft for your next generation.
- Submit on an older version is the rollback — same request, same approval, same audit trail. There is no separate revert.
- Awaiting approval marks a version already in the queue; Rejected carries the reviewer’s reason.
Adding a new prompt
Section titled “Adding a new prompt”Prompt targets are defined in code, in backend/app/services/prompt_registry.py.
Adding an entry there is what makes a prompt appear in the inspector, under the
asset and at the pipeline position you give it. The row and its baseline version
are created the first time it is opened — no restart or migration needed.