The strongest upscaling brief describes what the image must do and what the process must not change. It separates objective delivery requirements from stylistic preferences, provides verified references and tells reviewers where invention would create risk.
Specify the destination and threshold
State the placement, final dimensions, crop, file format and colour requirements. Add the expected viewing size and what quality means in that context. A tool cannot make a good decision from enhance this image because the desired result could be archival fidelity, a clean ecommerce crop or expressive campaign art.
Provide a source assessment: original dimensions, known compression, blur, noise and any previous edits. If the source is already a small derivative, locate the highest-quality original before processing.
List protected and flexible attributes
Protected attributes may include a person’s identity, product geometry, colour, logos, written text and documentary details. Flexible attributes may include background texture, non-identifying foliage or deliberately illustrative elements. Make the distinction explicit.
If generative changes are allowed, define their purpose and review owner. NIST frames generative AI risk management as an ongoing activity, so the brief should include evaluation and accountability instead of treating the tool output as a finished deliverable.NIST generative AI risk profile ↗
Use references with labels
Attach only approved references and explain what each one controls: colour, material, identity, lighting or composition. A reference without a label invites the system and the reviewer to infer which features matter.
Do not use an unlicensed image merely because it is easy to download. Record source and rights information with the brief. Where supported, provenance records and content credentials can help connect outputs to their production history.C2PA technical specification ↗
Write acceptance criteria before generating
Define how the result will be compared with the source, which details receive close inspection and who can approve them. Include unacceptable changes such as altered text, invented product seams, transformed facial features or false reflections.
Request a neutral baseline before creative variants. Record the tool, model or mode, settings and output identifier. That gives the team a defensible starting point for iteration rather than a collection of anonymous files.
Turn the brief into a one-page control sheet
Put the source thumbnail, destination frame and three most important protected details on the first page. Follow with exact dimensions, acceptable crop, reference labels, allowed changes and rejection triggers. An operator should understand the job before opening the tool, while a reviewer should be able to test the output without reconstructing the request from messages.
Separate requirements from preferences visually. Required product geometry, approved copy and consent limits belong in a hard-constraint block. Mood, texture and degree of polish can sit in an art-direction block. If a preference conflicts with a protected fact, the fact wins or the brief returns to its owner.
Translate the brief into tool instructions carefully
Not every production requirement belongs in a prompt. Pixel dimensions and format may be tool controls; protected regions may need masks or reference strength; exact text may require later typesetting. Choose the control that matches the decision instead of describing everything in prose and hoping the model interprets it consistently.
Keep the plain-language brief as the authority. Tool-specific instructions are an implementation layer that may change when the service changes. This makes the project portable and prevents a long prompt from becoming the only record of why the image looks the way it does.
Review the brief before spending production time
Ask the operator to repeat back the destination, protected attributes and stop conditions. Ask the reviewer to identify the evidence needed for approval. If either person gives a different answer from the brief, correct the document before generating a batch.
After the first accepted asset, update the brief with a real approved example and a rejected example that exposes an important failure. Avoid filling it with every experiment. A short, curated learning record is more useful than a gallery that leaves future operators to infer the rule.
A practical decision table
| Brief field | Good instruction | Avoid |
|---|---|---|
| Output | 2400 px wide ecommerce crop | Make it HD |
| Protection | Do not alter label text or cap shape | Keep it realistic |
| Review | Compare label at 100 percent | Use best judgement |
Release checklist
- Name the placement
- Set pixel dimensions
- State crop tolerance
- Describe source defects
- List protected attributes
- List allowed invention
- Label every reference
- Record rights status
- Define rejection conditions
- Name the approver
Common questions
Should a brief include a long style prompt?
Only when style is part of the job. Output constraints and protected facts are usually more important.
What if the tool does not expose settings?
Record the service, date, mode, input and output identifiers, then preserve a baseline for comparison.