Define
Agree on intended use, media direction and the host workflow to evaluate.
From intention to evidence
A concept becomes credible through a traceable sample review. Keep the revision, conditions and result together; avoid treating a checklist as a certificate.
Prototype
Identify the sample revision and document the actual engineering platform.
Evaluate
Review output and recovery behavior under stated conditions.
Decide
Record changes, unresolved issues and the evidence needed for release.
| Review area | Practical question | Evidence to keep |
|---|---|---|
| Output | Is the text, line art or photograph suitable in its real context? | Physical samples, source artwork, media identity and revision |
| Media handling | Can the user load, feed, tear or remove it consistently? | Observed steps, failure conditions and recovery notes |
| Host workflow | What happens when a job is cancelled or the host disconnects? | App/OS version, sequence and observed outcome |
| Power behavior | What is supported when charging, starting and recovering? | Actual power specification and test procedure |
| Commercial readiness | Do packaging, instructions and refill names match the approved revision? | Approved artwork, BOM mapping and open-issue register |
Before a releaseKnow what has
Know what has
not been established.
Market obligations
Safety, radio, battery, environmental and labeling requirements depend on the actual product and destination. Engage appropriate specialists; this template does not determine compliance.
Performance claims
Do not add resolution, speed, battery life, capacity, durability or permanence claims from concept images. Use substantiated data for the actual product revision.
Change control
A media supplier, app update or component substitution can change the result. Define which changes require another review and how accepted revisions are identified.