The Model Name Belongs in the Filename in PWZ AI

Imagine opening a folder with four files called final.mp4. One came from text, another from a still image, and two used different models. The file you need may be there, but its source is unclear.

In PWZ AI, a project can move between image creation, image-to-video, video transformation and editing. The model name belongs in the filename because the file should still explain itself after it leaves the workspace.

The workspace is only the context. The same naming method works with any multi-stage image or video tool.

Name the test before generating it

Choose the filename pattern before the first generation.

A quick test can use:

project_stage_model_render_status.ext

A project that needs fuller traceability can use:

project_stage_model_source_prompt_render_status.ext

For a fictional coffee-pouch clip, that might become:

coffee-launch_i2v_model-a_src02_p04_r03_review.mp4

The sections have separate jobs:

Use a short, consistent model name. Availability may change, so record the option selected for each output.

Keep the stage names boring

Use a small shared list of stage labels:

t2i for text to image;

i2v for image to video;

v2v for video to video;

edit for a later adjustment;

export for a delivery file.

Choose one spelling and keep it. Stage describes what happened to the asset; status records the decision about it. In the example, i2v is the stage and review is the status.

Use lowercase letters and numbers where possible. Put hyphens inside fields and underscores between them. Avoid slashes, colons and quotation marks, which operating systems may handle differently.

Keep status labels simple: draft, review, approved, rejected and delivered. If an approved asset changes, give it a new render number and return it to review instead of overwriting it.

Separate the source version from the render version

Suppose three video attempts come from src02: r01, r02 and r03. The source image is then corrected and saved as src03.

When the source or prompt version changes, restart the render number at r01. The complete combination remains unique:

coffee-launch_i2v_model-a_src02_p04_r03_review.mp4

becomes:

coffee-launch_i2v_model-a_src03_p04_r01_review.mp4

Without both numbers, a team may approve newer motion while restoring an older source image. A render number is only a counter, not a quality score.

Keep the prompt outside the filename

A filename is an index, not a place for the whole creative brief. Long prompt fragments are hard to read and may expose information when the file is shared.

The p04 field should point to a separate project note containing the full prompt, source names, selected model, relevant settings, reason for the change and approval record. Two files with different prompt IDs should not be described as a model-only comparison.

Do not put private information in the name

File names appear in downloads, shared links, cloud logs and attachments. Do not include full names, email addresses or confidential product details. Use neutral project codes and keep consent records, licences and commercial-use notes in a protected document.

A clear filename does not make an asset safe to publish. Images, footage, audio, voices and brand material still need permission. Check generated wording, labels and factual claims against an authorised source.

A filename should survive the workspace

The useful test is simple: copy one output into an empty folder. Can another person tell which project, stage, model, source, prompt and render it belongs to? Can they see whether it is a draft or an approved file?

If the answer is yes, the filename is doing its job. The model name is only one field, but leaving it out removes a key part of the asset’s history.