Fashion production begins with a document. The technical pack, or tech pack, is the specification blueprint that a brand sends to a factory describing exactly what it wants made: the garment’s measurements, its construction method, its materials, its trims, its labelling requirements, its stitch density, its seam allowances and every other detail the factory needs to produce the garment accurately. The factory reads the tech pack and builds from it. The tech pack that reaches the factory is the tech pack that gets made.
The gap between the tech pack that gets made and the tech pack the brand intended can open at any point in the revision process. A brand sends a tech pack. The factory produces a sample. The sample does not fit correctly at the shoulder. The brand’s technical designer makes a correction, updates the document and sends a revised version. Then another correction. Then another. Each revision is an update to the specification. Each update creates a new version. The question of which version the factory received and built from determines whether the production run matches the brand’s final approved specification or an earlier iteration that has since been superseded.
This article examines what tech pack version control is, why its absence is the most common documented cause of factory miscommunication in independent fashion, and what a brand needs to build before revision history becomes a production accountability instrument rather than an email archive search problem.
A factory builds from the tech pack it receives. If that version isn’t the approved version, the garment it produces isn’t the garment the brand intended. This article explains what tech pack version control is, why most brands lack it, and what it costs when they do not have it.
What a Technical Pack Is and What Its Version Represents
The document and its components
A tech pack is a complete specification document for a garment covering the full production picture, from materials sourcing to construction methods to revision history. Its typical contents include: a flat sketch of the garment from front, back and detail views; a Bill of Materials specifying every material, trim and label by type, colourway, supplier and approved substitutes; a measurement specification with graded measurements across all required sizes; construction details including seam types, stitch specifications and assembly sequence; labelling and packaging requirements; and a revision log recording every change made to the document since its first issue.
The revision log is the component most commonly omitted by independent brands producing tech packs in Adobe Illustrator and Excel, which remain the most widely used tools for tech pack production despite not being purpose-built for the task. Without a revision log, the tech pack’s version history exists only in email threads: a sequence of PDF attachments whose correct reading order is reconstructable only by someone with access to the full thread and the time to trace it. For a factory receiving the same brand’s sixth email with the subject line ‘Updated tech pack please use this one,’ the version history is a reconstruction problem rather than a structured record.
What the version number establishes
A version number on a tech pack establishes three things simultaneously: that this specific version of the document exists as a discrete instance; that it is different from previous versions in ways that the revision log describes; and that it is either a draft, under review or factory-approved, a status designation whose presence tells everyone handling the document whether it is the current working version or a previous one. Version 1.0 issues when the document first goes to a factory. Version 1.1 is issued when a correction is made that does not change the design direction; version 2.0 is issued when a substantial revision changes a significant design or construction element.
Without a version number, a document cannot be distinguished from its previous iterations except by content comparison. Content comparison requires time and attention that the factory’s technical team rarely has: they handle multiple brands’ packs across multiple revision rounds simultaneously. The absence of a version number does not create ambiguity for one brand’s single-document production run. It creates a compounding ambiguity problem for the factory that receives twelve brands’ unversioned documents in a single month and must identify which of several similar-looking PDFs is the current approved specification for a given style.
Why Version Mismatches Happen
The multi-tool workflow problem
The primary cause of version mismatches in tech pack management is not incomplete specifications. It is the multi-tool workflow that most independent brands use to produce their tech packs. A technical designer works in Adobe Illustrator for the flat sketch, maintains a separate Excel file for the BOM and measurement specifications, and manually assembles the final PDF before sending it to the factory. Each revision requires updating both the Illustrator file and the Excel file independently. When a revision is made to the Illustrator file, but the Excel file is not updated in the same session, or when a measurement change is made in the Excel file but the PDF assembled from it is not the version sent to the factory, a version mismatch is created within the brand’s own documents before the pack reaches the factory.
The version mismatch then enters the email thread. The factory receives a PDF. The brand corrects and sends a revised PDF. The factory receives the revision. The factory’s production team begins cutting based on the first PDF while the floor supervisor is reading the second. The garment emerges from production with the shoulder width of version 1.0 and the hemline of version 1.1, because different sections of the factory floor received different documents at different points in the production timeline. This is not a hypothetical scenario. It is the scenario that tech pack version control exists specifically to prevent.
Version control is not bureaucratic overhead. It is the production record that determines who is accountable when the garment that comes off the production line does not match the garment the brand approved. Without it, the factory can reasonably claim it built it from the document it received. Without a revision log, the brand cannot prove which document that was.
The email archive as the accidental version system
Without a structured version control system, the email thread becomes the de facto version history. The brand sends V1. The factory replies with questions. The brand sends V1.1. The factory confirms. The brand makes a late change and sends V2 with the subject line ‘Please use this updated version.’ The factory’s response to V2 contains a question about the V1.1 measurement. The brand’s reply references the V2 correction. Three weeks later, the sample arrives built to V1.1 measurements with the V2 collar. The brand investigates and finds, by scrolling back through the thread, that the factory’s floor team received V2 after cutting had begun on the collar but not on the body.
This reconstruction, done after the production failure, is the email archive functioning as an accidental version system. It can establish what happened. It cannot prevent it from happening again, because the cause of the failure was not a communication breakdown. It was the absence of a system that made the current approved version unambiguous at every stage of the production process.
What a Version Control System Provides
The structured record
Tech pack version control, as defined by product lifecycle management practitioners, is the practice of assigning sequential identifiers to each revision of a garment’s technical specification document. A well-controlled tech pack history includes the original design brief and tracks every subsequent change, who made it, when they made it and why. It tracks the approval status of each version: whether a revision is a draft, under review or factory-approved. The factory-approved designation signals to the factory that the document is the version it should build from, rather than an interim revision that may still change.
The revision log within the versioned tech pack provides the content of the version history: what changed between V1.0 and V1.1, what changed between V1.1 and V2.0. A factory whose technical team reads the revision log before beginning production knows exactly what is different in the current version from the previous one and can confirm that any prior cuts or preparations they have already made are compatible with the current specification. The revision log makes this confirmation possible without requiring the factory to re-read the entire spec from the beginning.
The factory-approved version as the accountability instrument
The factory-approved designation serves a second function beyond production clarity. It is an accountability instrument. When a brand applies factory-approved status to a specific version of its tech pack before sending it to the factory, it creates a production record: this is the specification the factory was asked to build. If the garment that returns from the factory deviates from that specification, the deviation is measurable against a document whose version, date and approval status are all on record. The brand’s quality control team can compare the returned sample against the factory-approved version, identify the specific measurements or construction elements that differ, and determine whether the deviation originates in the factory’s production process or in a specification error in the approved document.
Without a factory-approved version in the record, this comparison lacks a reference document. The brand’s quality team compares the returned sample against whatever version of the spec they most recently reviewed, which may or may not be the version the factory actually built from. This ambiguity creates an accountability gap that benefits neither party: the factory cannot verify it built correctly because the correct version isn’t a defined term; the brand cannot hold the factory accountable for a deviation it cannot prove came from the document the factory received.
Reducing revision rounds and their costs
The practical production benefit of version control extends beyond accountability. Wave PLM’s analysis of its customers’ revision patterns found that brands with a structured version control workflow averaged under two revision rounds per style, compared to four or more revision rounds for brands managing revisions through email and unversioned PDFs. Each revision round in a garment development cycle carries a cost: a new sample cut, fabric consumption, production time at the factory and international shipping. At four revision rounds, these costs add up to a significant proportion of the garment’s development budget. With fewer than two rounds, they remain a manageable, predictable expense.
The reduction in revision rounds comes not from the version control system reducing the number of corrections the brand needs to make. It comes from the version control system ensuring each correction reaches the factory in a form it can act on without creating further ambiguity. A correction that arrives in a versioned, change-logged document with clear factory-approved status eliminates the factory’s need to ask clarifying questions about what has changed, where the change applies and whether the current document supersedes the previous one. The question count goes down. The rounds go down. The cost goes down.
Version Control Across Different Production Contexts
Independent brands in direct factory relationships
For an independent fashion brand with a direct relationship with one or two factories, the version control requirement is the simplest to implement: a consistent version numbering convention applied to every tech pack from the first issue, a revision log updated with every change, a factory-approved designation applied before each send and a single source of truth for the current version held within the brand’s own file management system. The additional administrative load on the brand’s technical designer is measured in minutes per revision, not hours. The protection it provides against the scenario described above is structural rather than procedural: the system produces the evidence that the email thread does not.
Brands sourcing across multiple factories
For brands sourcing different styles or product categories across multiple factories, version control requirements scale with complexity. A brand managing fifteen styles across four factories may have sixty or more simultaneous tech pack version streams in production at any given time. Without a PLM system or equivalent structured document management infrastructure, the probability that the wrong version of at least one style reaches at least one factory at some point in the production cycle is essentially certain. The brand is managing a document problem that exceeds what an email-and-PDF workflow can reliably handle.
PLM systems address this by managing version control structurally: every tech pack lives in the system with its full version history, every change is timestamped and attributed, every factory-approved version is locked from further editing without a new version being created, and the system distributes the current factory-approved version to the correct factory contact through the platform rather than through email. The factory accesses the current version through a platform link rather than searching an inbox for the most recent attachment. The version ambiguity problem is architectural rather than procedural: the system does not allow the factory to download an outdated version because the system makes the current version the only one accessible.
Connecting Version History to Other Documentation
As Omiren Styles has established, in its analysis of what a 3D fashion sample can answer before physical fabric arrives, the decisions the 3D sample enables earlier in the development cycle include construction logic and pattern correction. Each of those decisions, when implemented, produces a new version of the tech pack. The version control system records those decisions as a structured history rather than as a sequence of files the brand’s team must reconstruct from memory when a question arises about what changed and when.
As Omiren Styles has established, in its analysis of the documentation gap in fashion supply chains, the record that exists is not always the record that attributes responsibility correctly. The tech pack version history is the documentation that allows responsibility for a production outcome to be attributed correctly: the factory built from the document it received, the document it received is on record, and the record shows whether that document was the factory-approved version or an earlier iteration. Without version history, responsibility for a production failure becomes a negotiation between parties whose documentation does not resolve the question either way.
The Omiren Argument
The question the title asks, which version reached the factory, is a production accountability question masquerading as an administrative one. The answer determines whether a quality failure originates in the factory’s production process or in the brand’s specification management. Without the answer, neither party has the documentation to establish what went wrong or to prevent the same thing happening on the next run.
For independent fashion brands, particularly those from the Global South managing production relationships across international supply chains, the version control gap is a structural disadvantage. A large brand with PLM infrastructure produces a factory-approved version before every send, maintains a full revision history and can investigate a production failure with precision. An independent brand managing tech packs through email and unversioned PDFs cannot. When a production failure occurs, the independent brand negotiates its claim against a factory without the documentation to support it. The factory is not necessarily wrong to dispute the claim: the brand cannot prove which version it received.
As Omiren Styles has argued throughout its coverage of production technology and the Global South, the Global South made fashion and never got credit. The version control system is one instrument that allows a brand to build the documentation infrastructure that makes commercial relationships with factories legible, accountable, and equitable. A brand that can point to a factory-approved version, a revision log, and a documented dispatch record can have a different conversation about a production failure than a brand that has only an email thread. Building that infrastructure is not a technology investment. It is a decision to manage production as a documented practice rather than a series of conversations.
MINIMUM VERSION CONTROL REQUIREMENTS FOR A TECH PACK
- Version number on every issue: V1.0 at first factory send; V1.1 for minor corrections; V2.0 for design or construction changes.
- Revision log in the document: date, author, what changed and why, in every version.
- Approval status on every version: Draft, Under Review or Factory-Approved.
- Factory-approved lock: the factory-approved version is not edited; corrections go into a new version.
- Single source of truth: one system (PLM, shared drive or document management tool) holds the current approved version; the factory accesses or is sent only this version.
- Dispatch record: the date and version number of every tech pack sent to the factory, logged and retained.
ALSO READ
- What Can a 3D Fashion Sample Answer Before Physical Fabric Arrives?
- The Documentation Gap: What Fashion Supply Chains Still Fail to Record
- Digital Product Passports for Fashion: The EU Framework Exists. Textile Rules Do Not Yet.=
- The Global South Made Fashion. It Just Never Got Credit.
EXPLORE MORE
Read the full Production Technology and Material Intelligence coverage at Omiren Styles for ongoing analysis of production documentation, supply chain accountability and the tools that convert fashion devturnt from a conversation into record. Discover travel and heritage intelligence across Africa, the Caribbean and Latin America at Rex Clarke Adventures.
