Ask most regulated companies what their packaging artwork actually is, and the answer is a file. A PDF. An InDesign document. Something that gets created, reviewed, approved, and eventually printed. That framing has been correct for as long as artwork has existed in digital form — and it's becoming less useful every year.
The more accurate way to think about artwork, especially in pharma, medical devices, medical marketing, and FMCG/CPG, is as data: a set of discrete, structured elements — text content, regulatory statements, symbols, barcodes, allergen declarations, UDI carriers — that happen to be arranged on a page. The file is a rendering of that data, not the data itself. And once you make that shift in how you think about artwork, several things that look like separate problems turn out to be the same problem.
Why "It's Just a File" Stops Working at Scale
A single artwork file is manageable. A portfolio of products, each with multiple language versions, multiple market variants, and a revision history stretching back years, is not manageable as a collection of files — not reliably, and not at the pace regulated industries now operate at.
The strain shows up in predictable places. A correction to a dosage statement needs to propagate across twenty language versions of a pharmaceutical leaflet — and if each version is a separate file, propagation is a manual, sequential task with no structural guarantee that it happened correctly everywhere. A medical device's UDI needs to be consistent across three packaging levels — and if each level's artwork is produced and reviewed independently, consistency is something you hope for, not something the system enforces. An allergen declaration needs to carry identical meaning across every market a product ships to — and if each market's file was built and approved on its own timeline, "identical meaning" is an assumption until someone checks.
In every one of these cases, the underlying problem is the same: the content that matters is treated as a property of the file rather than a property of the product. When ten files each contain their own copy of the same regulated fact, you have ten opportunities for that fact to drift out of alignment, and no structural mechanism that would catch it happening.
What Changes When Artwork Is Treated as Data
Electronic Product Information is the clearest example of this shift already underway. EMA's move toward structured, FHIR-based product information — rather than static PDF documents — is explicitly a move from "the file is the record" to "the data is the record, and the file is one way of displaying it." The same content that used to live only inside a formatted PDF becomes a set of discrete data elements that can be validated, compared, and republished independently of any single document's layout. The same text-level risk shows up in FDA's Structured Product Labeling requirements, where the underlying content, not just the visual document, has to match the approved source exactly.
The same logic applies below the regulatory-submission level, in the artwork verification process itself. A comparison built around "does this file match that file" is fragile — it depends on layout staying consistent even when only the underlying content should be compared, and it treats every file as its own island. A comparison built around "does this data element match the approved data element, wherever it appears" is structurally different. It doesn't care whether the allergen declaration sits in paragraph three or paragraph five, or whether the file is a PDF, a print-ready artwork export, or a structured XML submission — it checks the content against the source of truth, regardless of the container.
This is the practical meaning of a digital thread: a single, traceable line of data connecting the approved source content through every downstream representation of it — the pharma label, the device IFU, the promotional detail aid, the FMCG package — such that a change at the source can be verified against every representation, and a discrepancy in any representation can be traced back to where it diverged from the source.
What This Implies for Version Control
Version control built around files answers the question "which file is current?" Version control built around data answers a more useful question: "does every representation of this content currently match the approved source?"
The difference matters most exactly where regulated industries are most exposed: multilingual and multi-market products, multi-level packaging, and long revision histories with many contributors. A file-based version control system can tell you that Version 14 was approved and Version 15 was not — but it cannot tell you, on its own, whether the allergen declaration inside Version 15 still says what the approved source says, unless someone runs that specific comparison. A data-oriented approach makes that comparison the default check, not an optional one someone has to remember to run.
What This Implies for the Audit Trail
An audit trail built for files documents which files were reviewed, by whom, and when. An audit trail built for data can document something more specific: which data elements were verified against which approved source, what the outcome was, and where in the final artwork that element appears. The second kind of record is the one that actually answers the question a regulatory inspector or a notified body auditor asks — not "was this file reviewed," but "was this specific claim, this specific dosage, this specific UDI, verified against what was approved."
What This Implies for Real-Time Verification Across the Supply Chain
The most forward-looking implication is also the least developed today: if artwork is data rather than files, verification doesn't need to wait for a discrete review cycle. A change to an approved data element — a corrected allergen threshold, an updated symbol standard, a revised claim — could, in principle, trigger verification against every downstream representation that depends on it, across every market and every packaging level, as soon as the change is approved. That's meaningfully different from today's default, where a change is made, and then someone has to remember everywhere it needs to be checked.
This isn't a claim that the infrastructure for this exists everywhere today — it doesn't, and building it is a genuine undertaking for most organizations. It's a claim about the direction the underlying logic points. Every regulatory and operational pressure covered in this piece — multilingual consistency, multi-level packaging, structured electronic submissions — pushes toward treating the content as the thing that needs to be governed, with the file as a secondary, derived artifact.
The Shift Worth Making Now
None of this requires abandoning files — pharma labels, device packaging, and FMCG artwork will keep being printed, and PDFs will keep being the practical medium for a long time yet. What it requires is a change in what the verification process treats as the source of truth. When the approved data — not any single file — is the reference point, comparison stops being "does this file match that file" and becomes "does this specific piece of regulated content match what was approved, everywhere it appears." That's a more demanding standard. It's also the one that actually reflects what's at stake when the content is wrong.
↗ Content Compare verifies content against the approved master at the character and element level — across every file format, every language, and every market representation. Request a demo to see the difference.
