Volume 05, Chapter 4
Naming, Cataloguing, and Storage
Definition
Imagine a regular customer calls to reorder a dress. Somewhere in the workshop is the exact pattern used last time, except it's saved as "Blue Dress," and there are eleven similarly vague folders that could be it. Two hours later, someone finally finds it. Nothing about the pattern itself was ever the problem, only what it was called.
A naming convention is a consistent, predictable code applied to every pattern so it can be found, referenced, and never confused with another. Cataloguing is the record that maps every code to its details. Storage is where the physical and digital copies actually live.
"Dress 1," "Dress 2," "New Jacket Final," "New Jacket Final v2 ACTUAL", this is how pattern libraries quietly become unusable. A proper code (like DR-2026-041) is boring on purpose: it sorts logically, never repeats, and tells you at a glance roughly what it is and when it was made. Combined with a catalogue record and a deliberate storage plan, any pattern becomes findable in seconds, by anyone, not just whoever made it.
Naming: Codes, Not Descriptions
| Bad Naming | Why It Fails |
|---|---|
| "Dress 1", "Dress 2" | Meaningless after the tenth dress; no information, no order |
| "New Jacket Final" | "Final" rarely is; invites duplicate "Final v2," "Final ACTUAL" |
| Customer's first name only | Breaks the moment two customers share a name; discloses personal data unnecessarily |
A good code is structured and boring: for example DR-2026-041, garment type (DR = dress), year created, sequence number. Anyone in the business can decode it at a glance, it sorts naturally in any file system, and it never collides with another pattern.
Use a code, not a description, for every pattern name. A description like "New Jacket Final" feels natural at first but stops working once there are dozens of patterns. A structured code keeps working no matter how many patterns you have.
Cataloguing: The Record Behind the Code
The code alone isn't enough, it needs a catalogue entry recording what it actually is:
| Field | Example |
|---|---|
| Code | DR-2026-041 |
| Garment type | Wedding dress |
| Base size | M |
| Date created | 2026-03-14 |
| Created by | Head Cutter |
| Current version | v2 (Chapter 5) |
| Status | Active |
| Physical location | Drawer 4, Folder C |
| Digital location | Shared drive, Patterns/2026/ |
| Related customer order(s) | Order #1187 |
This is exactly Volume 20, Chapter 1's Pattern Module in practice, whether kept on an index card or in software, every pattern needs this record to exist somewhere searchable.
Storage: Physical and Digital, Both Deliberate
| Storage Method | Best For |
|---|---|
| Flat drawers | Full-size paper patterns, protected from folding damage |
| Labelled envelopes | Smaller pattern pieces, kept together by garment |
| Waterproof folders | Protection against damp, spills, and general wear |
| Digital scans | Backup, remote access, and disaster recovery |
| Organization by garment type, then customer, then season | Multiple valid systems, the only rule is picking one and applying it consistently |
A digital-only pattern library with no physical backup (or vice versa) is one hard-drive failure or one flood away from losing years of accumulated value. Keep both, and treat the digital scan as the true backup of the physical original, never the only copy of anything.
Example Story: The Pattern That Took Two Hours to Find
Before adopting a naming convention, MANIAC MINDZ stored patterns by whatever description felt natural that day: "Blue Dress," "Wedding Order Sept," "Mrs Adamu's Dress 2." A repeat customer's reorder took over two hours to locate, because nobody remembered which of eleven similarly-described folders held it.
The fix, codes like DR-2026-041, a simple spreadsheet catalogue, and drawers organized by garment type, turned that two-hour search into a thirty-second lookup, permanently. Nothing about the patterns themselves changed; only how they were named and recorded.
Across Industries
| Business | Their Naming Convention |
|---|---|
| Precision Print & Press | [Client Code]-[Job Type]-[Year]-[Sequence], e.g., MMZ-BC-2026-003 for MANIAC MINDZ's third business card job of 2026 |
| Nimbus Labs | Version-numbered code modules in a shared repository (a central code store), named by what each one does, not by which developer wrote it |
| Golden Crust Bakery | Recipe codes by category and sequence, e.g., BR-014 for the fourteenth bread recipe |
Common Mistakes
Works for the first ten patterns, fails by the hundredth, see Section 2.
A pattern created today but catalogued "eventually" is exactly as unfindable as one never catalogued at all.
Physical-only risks fire, flood, and misplacement; digital-only risks hard-drive failure and file formats that stop opening on newer computers. Keep both.
Quiz Yourself
DR-2026-041 better than a description like "Wedding Dress Final"?Practice Exercise
- Design a naming code for your business's patterns (garment/product type + year + sequence, or your own logical structure).
- Rename your five most-used existing patterns under the new code, and log each in a simple catalogue using the fields in Section 3.
- Confirm each has both a physical and a digital copy, stored per Section 4.
Quick Summary
Quick Summary
- Use a structured code, not a description, for every pattern name, boring, unique, and sortable.
- Every code needs a catalogue entry: type, dates, version, status, and both storage locations.
- Store patterns both physically and digitally, treating the digital copy as the backup, never the only copy.
- A missing or outdated catalogue entry makes a pattern just as unfindable as if it never existed.