How to Version Tattoo Stencil Files So the Approved Version Gets Printed

The newest file is not automatically the approved file.

A tattoo project can contain a source image, several cleaned or redrawn revisions, a client-review export, a mirrored copy, a resized print file, and an old PDF still sitting in Downloads. All of them may have been created for valid reasons. The risk appears when one of those files reaches the printer without a clear relationship to the design that was actually reviewed.

The useful discipline is not keeping every duplicate. It is preserving the few decisions that answer four questions:

1. Which design revision is approved?
2. What changed after that revision?
3. Which production state is this file in, especially size and mirror orientation?
4. Which exact digital artifact produced the physical stencil?

A filename can help answer those questions. It cannot prove them by itself.

Separate the design revision from the production state

This is the distinction that prevents most version labels from becoming meaningless.

A design revision changes what could be tattooed. Create a new revision when you alter geometry or content: add or remove a line, change a contour, replace the source, move a facial landmark, change lettering, open a counter, alter handwriting, adjust a logo shape, change a composition, or otherwise make a deliberate visual change.

A production state describes how an already chosen design is being prepared for output. Examples include a specific physical size, a mirror state, page placement, or a print-ready PDF derived from the approved geometry.

Those are not the same axis.

A practical record might therefore say:

DESIGN: v03 approved
PRODUCTION: 90 mm wide / print-mirrored / A4 PDF

rather than burying everything inside final-final-2.pdf.

This distinction also makes later diagnosis possible. If the printed stencil is wrong, you can ask whether the design revision was wrong or whether the production transformation was wrong.

Freeze the approved design before making print variants

When one revision is accepted for the current job, make that transition explicit.

Do not keep editing the only approved file in place. Preserve a stable approved artifact that can be reopened and compared later. It can be a PNG, PDF, exported image, or another dependable representation of the chosen geometry. The important property is that casual production work does not overwrite it.

Then derive print-specific files from that approved state.

The diagram does not prescribe one folder structure or filename format. It shows the relationship that matters: approved geometry sits upstream of the production artifacts.

If geometry changes after approval, the approved state has been superseded for that decision. Create another design revision, describe the change, and review that revision. Do not silently modify the frozen artifact and keep the old approval label.

What deserves a new design revision?

Create a new meaningful revision when a change could alter what reaches skin.

| Change | New design revision? | Why | |---|---|---| | Add, remove, redraw, or move a line | Yes | Geometry changed | | Replace the source/reference | Yes | The evidence base changed | | Change portrait feature spacing or silhouette | Yes | Identity-bearing relationships changed | | Alter a logo counter, spacing, or wordmark shape | Yes | Brand geometry changed | | Smooth, reconnect, or reshape handwriting | Yes | Writer-specific geometry changed | | Change crop in a way that changes composition | Yes | Included content or relationships changed | | Change proportion or stretch one axis | Yes | Geometry changed | | Rotate or reposition elements within the design | Usually | Composition changed | | Mirror the approved design for a verified print path | Record production state | Same design can require a different output orientation | | Export the same geometry to PDF | Usually not | Representation changed, not design | | Place the same design on A4 without resizing it | Usually not | Page layout changed, not design geometry | | Re-export unchanged bytes because the first download was lost | No | No meaningful decision changed |

The boundary is semantic, not software-driven. An application can create a new file every time you export. That does not mean every export deserves a new design revision number.

Conversely, saving over the same filename does not mean the design stayed the same.

Keep a revision ledger small enough to use

A revision number only tells you sequence. v7 does not tell you what happened between v6 and v7, why the change exists, or whether either version was approved.

A useful ledger can be a text note, a project note, a small table, or another lightweight record:

| Revision | What changed | Why | State | |---|---|---|---| | v01 | First cleaned stencil | Initial preparation | Working | | v02 | Restored two source-supported leaf gaps | Source comparison | Review | | v03 | Reduced lower flourish and kept all other geometry | Requested revision | Approved | | v03 / 90 mm / mirrored | No design change; print transform only | Transfer preparation | Print artifact |

Describe meaningful deltas, not every click.

For source-sensitive work, be specific. “Cleanup” is too vague if the operation changed a terminal stroke in handwriting, a logo counter, a portrait landmark, or another identity-bearing feature. The handwriting preparation guide and portrait likeness diagnostic show why those small geometry changes can matter.

Approval is a state transition, not a filename

A file called approved.png may have been overwritten. A file called v4-final.pdf may have been exported from v3. An OS-added (1) says only that a duplicate filename existed.

Treat approval as a decision tied to a specific visual state.

A lightweight approval record should make it possible to identify the exact artwork that was reviewed. That can be as simple as retaining the review image and the approval message together with a revision label. The Tattoo Design Approval Sheet Maker can package one artwork state with a workflow status, recorded dimensions, orientation, notes, project ID, and date. Its Approved status is a creative-workflow label, not legal consent.

The approval artifact is evidence of which state was selected. It does not create revision history, compare two designs, resize a stencil, or guarantee that a later export still matches.

That is why the next rule matters.

After approval, classify every change before making it

Ask whether the proposed operation changes design geometry or only production state.

Geometry or content changes

Examples:

• simplify a crowded region;
• remove a line;
• open or close a gap;
• reshape a contour;
• move lettering;
• alter a date or character;
• change portrait proportions;
• repair or smooth handwriting;
• modify logo geometry;
• replace an element or source.

Create a new design revision and review it.

Production-only transformations

Examples can include:

• horizontal mirroring required by the verified transfer path;
• setting the already decided physical width;
• placing the same approved geometry on a print page;
• exporting the exact prepared state to PDF.

These can remain derived from the same approved design revision only if the design geometry remains unchanged.

Do not use this category to hide an adaptation. If reducing to 70 mm forces you to remove lines or open spaces, that is no longer “just sizing.” The geometry changed, so the design revision changed too.

Record mirror state explicitly

Mirroring deserves its own production field because a correct design can produce the wrong physical result when left and right are ambiguous.

Keep the approval view human-readable in the intended skin-facing direction whenever that is the review convention for the job. Then record any downstream print reversal separately, for example:

v03 / APPROVED / SKIN_VIEW
v03 / PRINT / 90mm / MIRRORED

Those labels are examples, not required vocabulary.

Do not infer the correct mirror state from the filename alone. Verify the actual print path. Some workflows reverse at a software stage, some at a printer workflow, and the paper-to-skin step itself matters. The mirror guide covers that diagnosis.

If you do not know whether a file has already been mirrored, stop. Re-establish the intended skin-facing reference and the transformations in the actual print path before printing.

Record physical size as production identity

The same approved geometry can legitimately produce several physical stencil sizes.

That makes size part of the print artifact's identity even when it does not create a new design revision.

For each print artifact, retain the intended physical width and, when useful, height. Keep aspect ratio or non-proportional transforms explicit. For example:

v03 approved
-> v03 / 90 mm wide / mirrored
-> v03 / 105 mm wide / mirrored

These are two production artifacts from one design revision.

If the intended dimensions are unknown, do not guess from a screen preview or reuse an old file because it “looks about right.” Set a known physical size first. The Size & Print Calculator creates known-size output; the wrong-size diagnostic starts after a physical print no longer matches the intended measurement.

Stale exports are a separate failure class

The editable document can be current while the exported PNG or PDF is stale.

A common dangerous chain looks like this:

v03 working document updated
-> old v02-print.pdf still exists
-> Downloads search finds the PDF first
-> old export gets printed

The file modification time does not solve this reliably. A copied old file can have a recent timestamp. A duplicate download can be newer than the approved design. An export can be created today from an older source revision.

Before printing, either regenerate the production artifact from the identified approved revision or directly verify that the existing export matches it.

The Version Compare tool is useful when two image revisions are uncertain. It can show them side by side, overlay them, blink A and B, align one version manually, and localize rendered differences. It does not know which file was approved and does not store version history.

A filename is a locator, not content proof

A useful filename can reduce selection errors. It cannot prove that the file contents are correct.

An example pattern is:

project-revision-status-production-state.ext

For one project:

rose-v03-approved.png
rose-v03-print-90mm-mirrored.pdf

Use another convention if it is clearer in your workflow. The fields matter more than the punctuation.

Avoid relying on labels such as final, latest, or use-this-one as the entire state model. They do not establish which review decision they correspond to, whether geometry changed afterward, which size was intended, or whether the file is mirrored.

For higher-stakes or multi-person workflows, a file hash can answer one narrow technical question: whether two files contain identical bytes. It still cannot tell you that the design is correct, that the client reviewed it, that print settings were correct, or that the physical paper output matches. Use it only when byte identity is genuinely useful.

Run a five-part identity check immediately before print

Before the final print command, inspect the exact artifact that will be sent.

1. Design lineage

Can you point to the approved design revision this file came from?

If not, stop and reconstruct that relationship.

2. Geometry

Did any mark, spacing relationship, crop, proportion, or content change after approval?

If uncertain, compare the approved artifact with the print artifact. A difference may be expected from scaling, crop, antialiasing, or mirroring, so interpret the comparison rather than treating every highlighted pixel as an error.

3. Orientation

Is the current artifact in the mirror state required by this exact print and transfer path?

Do not assume “mirrored” means correct without knowing where other flips occur.

4. Physical size

What width and height should appear on paper?

If the answer is undefined, the artifact is not ready for controlled printing.

5. Page and file identity

Is this the exact PDF, PNG, or other file you intend to send now, rather than a similarly named stale export?

The Print Checker can inspect one chosen final file at intended size for file-side print risks. It does not establish approval history, so do the lineage check first.

Link the physical stencil back to the print artifact

Once paper exists, digital certainty can be lost again.

If you print one stencil and use it immediately, visual recognition may be enough. If you print several sizes, mirrored/unmirrored variants, alternates, or multiple jobs, the physical sheets can become ambiguous.

A minimal mark can preserve identity:

PRINTED
v03
90 mm
mirrored
2026-08-24

Or retain the exact print PDF and note which one was used.

For batches where physical identification is genuinely useful, the Stencil Label Sheet Maker can create compact labels with a safe ID, version, recorded size, mirror state, copies, and an optional thumbnail. It does not decide which revision is approved.

For the session itself, the Session Reference Sheet Maker begins later: it packages the final stencil, optional visual reference, version, recorded size, mirror state, placement summary, and artist-written cues. It is an operational handoff, not revision history.

Diagnose the first place authority was lost

When a physical stencil looks wrong, do not immediately open the newest file and edit it.

Trace the chain backward:

SOURCE
-> WORKING REVISION
-> REVIEW ARTIFACT
-> APPROVED DESIGN
-> PRODUCTION VARIANT
-> EXACT PRINT FILE
-> PHYSICAL STENCIL

Find the first mismatch.

| Failure | First question | |---|---| | Stale revision printed | Which design revision produced the export? | | Working experiment printed | Was this revision ever moved into approved state? | | Post-approval geometry drift | Does the print artifact still match approved geometry? | | Mirror-state mismatch | At which stage did left-right state change? | | Scale-state mismatch | Which intended dimensions belong to this artifact? | | Wrong variant | Which composition/source alternative was approved? | | Stale PDF or PNG | Was the export regenerated after the approved revision changed? | | Physical-sheet ambiguity | Which digital artifact produced this sheet? |

This is why “pick the newest file” is a bad recovery rule. The newest file may be an experiment, an alternate, a copied old export, or a production variant created after the design decision.

Stop when provenance is uncertain

Do not print from ambiguity.

Stop and reconstruct the chain when:

• nobody can identify which revision was approved;
• two files marked final differ;
• geometry changed after approval without another review;
• the print artifact cannot be linked to an approved design;
• mirror state is unknown;
• intended physical size is unknown;
• several stale exports coexist and you cannot distinguish them;
• several physical stencils exist and you cannot identify which digital artifact produced each one.

Re-establish three things in order:

1. the authoritative source or chosen design basis;
2. the approved design revision;
3. the required production state.

Then regenerate the output.

Do not “fix” an uncertain older revision by copying later edits into it blindly. First compare what changed and determine which changes were intentional.

The minimum viable protocol

A solo artist does not need Git, a DAM, a CRM, or a project-management platform to get the benefit.

Use this seven-step routine:

1. Keep the source. Do not overwrite the only authoritative input.
2. Create a new design revision for meaningful geometry or content changes.
3. Record the delta. One sentence is often enough.
4. Freeze the reviewed design when it becomes approved.
5. Derive print artifacts from that approved revision, recording mirror state and physical size.
6. Verify the exact export before printing whenever lineage is uncertain or another change occurred.
7. Retain or label the exact artifact that produced the physical stencil when multiple outputs could be confused.

Cloud version history can help recover old bytes. Automatic backups can help recover deleted files. Neither tells you which visual state was approved unless you record that decision.

The goal is not more files. It is a short, reconstructable chain from approved design to physical stencil.