Home › Field notes › SKU Architecture for Modular Platforms: Coding That Shows Fit

Modular Bag Pro · 2026-10-11 · 2,567 words · 12 min read

SKU architecture for modular platforms is a coding scheme whose fields carry compatibility information, so that anyone reading a part number can tell without a lookup whether a given module mounts on a given carrier. That requirement rules out purely sequential numbering and favours a family-anchored format: a shared platform stem, a body group, a capacity block, a colour token and a revision marker, with module codes inheriting the stem of whatever bodies they fit. Commercial parameters remain constant whatever the scheme: minimum order quantity 500 units per reference, first samples returned in 6-10 working days rising to 12-15 for complex builds, series production of 35-50 days, inspection at AQL 2.5 and shipment FOB Xiamen. Applicability is limited to civilian carry programmes — commuting, tools, hiking, field and first aid work — with no ballistic or weapon-carriage content, and the code examples below are illustrations of format rather than references you can order.

What SKU Architecture Has to Carry on a Modular Platform

On a conventional range a part number answers one question: which item is this. On a modular range it has to answer three — which item this is, which family it belongs to, and which other items it fits — because the platform promise is that bodies and modules bought months apart will still work together. A scheme that answers only the first question silently pushes compatibility into someone's memory, and that memory leaves with whoever wrote it down.

The second job is supporting decisions nobody plans for. Warehouse staff need to pick a substitute when one reference is short; a distributor has to answer whether an accessory works with a bag bought two years ago; a returns clerk needs to know if a unit predates a design change. All three are answerable from a well-built code and all three become phone calls with a badly built one.

Cost is the third consideration, and it is not trivial. Codes appear on every label, tag, carton mark, barcode file, invoice line, listing variation and marketplace feed; changing the scheme later means editing all of them simultaneously, usually while stock of both versions is in circulation, which is why the structure should be settled before the first pattern is cut rather than after the first shipment lands.

Because the interface itself is fixed early — 25 mm webbing at rows spaced 38 mm apart with a 50 mm repeat along each row, all documented on the attachment grid page — the code can carry a generation token identifying which interface version a unit was built to. When a second generation eventually arrives, that single character is what prevents interleaving two incompatible families in one warehouse.

Selection rule: Build the code so that a person who has never seen your catalogue can decide fit from the number alone, because every lookup avoided is a mistake avoided, and the mistakes concentrate exactly where compatibility is ambiguous.

Encoding Compatibility Inside the Part Number Itself

A workable format uses fixed-width fields separated by hyphens, each position holding one kind of information. Variable-length fields are what break scanning and listing systems downstream, so every position should have a defined width even if some values are short. Five fields cover the majority of programmes: platform stem, product group, distinguishing block, colour token, revision.

The rule that makes this work is inheritance: every module takes the same generation token as the bodies it fits. A module coded third generation will not be promised onto a fourth-generation body, and crucially, seeing the mismatch requires no chart. Where a genuinely universal accessory exists — one ignoring the grid entirely — give it the accessory group with no generation token and label it as universal, which is honest and searchable.

Fixed width costs a little readability and buys a great deal of downstream stability. Requiring two digits for capacity means a nine-litre carry pod is written 09, which looks odd once and then never again, while a barcode routine, a spreadsheet sort and a marketplace variation all behave predictably forever afterwards.

Avoid embedding meaning you cannot control. Supplier initials, factory codes and intended channel belong in the record, not in the number, because each one is a future reorganisation waiting to happen, and any digit that can change for reasons unrelated to the product will eventually be wrong.

Verdict: Use five fixed-width fields with a generation token inherited by every module, and keep anything organisation-specific out of the code, because the fields that survive longest are those describing the physical product rather than the business around it.

How Carrier Codes and Module Codes Refer to Each Other

The relationship between the two families is a shared stem plus a slot number. Bodies carry a capacity figure in the distinguishing block because that is what distinguishes one body from another; modules carry a slot number because their distinguishing feature is the job they do, not how big they are. Both then share the generation token, which is the actual compatibility statement.

Slot numbers deserve a permanent register rather than allocation in chronological order. Reserving blocks by job — 01 to 09 for organisers and sleeves, 10 to 19 for tool and instrument modules, 20 to 29 for medical and emergency units, 30 to 39 for hydration and external carry — means a future planner can see what kind of module a code is even if they have never handled one, and new members fit without renumbering.

Cross-references matter as much as the codes themselves. Alongside the number, keep two short lists per module: bodies it fits without restriction, and bodies where fit is conditional with the reason recorded. A module that overhangs a compact body by 30 mm is "conditional" rather than "no", and recording that distinction prevents both a wrong promise and a needless restriction.

Bundles then need codes of their own. A body plus two modules sold as a kit is a distinct shippable unit with a distinct barcode, and it should have a code made from its constituents plus a bundle marker, rather than borrowing one child code and confusing every downstream count of what actually shipped.

Two practical realities sit behind all of this. Levels of 500 units per reference apply to each code created, so a new module number is itself a purchasing commitment; and each sample round takes 6-10 working days, so anything uncertain is best resolved before the number is issued.

Bottom line: Give every module the generation token of the bodies it fits and reserve slot numbers by job rather than by date of invention, because both practices keep compatibility legible years after the people who launched the range have moved on.

Four Coding Schemes Compared for Modular Platforms

Four schemes cover what most businesses actually try. They differ in the same three respects: whether compatibility can be read from the number, how much maintenance the scheme needs as the range grows, and how badly a reorganisation damages it.

Reading across the row about generations explains why sequential numbering fails specifically on modular kit. When a second interface version appears, nothing distinguishes old from new, so pickers interleave them, fit complaints rise, and the cause looks like a quality problem rather than a numbering one for months.

Capacity anchoring fails differently: it encodes the thing least relevant to compatibility. Knowing a body holds twenty-two litres says nothing about which modules mount on it, and two bodies of identical volume built to different interface generations receive codes differing only by a suffix nobody notices.

The hybrid approach is worth its upkeep once a business runs more than one platform or more than roughly thirty live references. Its cost is governance: somebody must own the register, and every new stem or slot block has to be issued rather than invented.

Takeaway: Adopt a family-anchored scheme with a generation token as soon as a second interface version is conceivable, even if the current catalogue is small, because retrofitting compatibility into a sequential scheme later means renumbering every existing reference across every system at once.

Revision Control: When a Number Must Change and When It Must Not

Revision policy is where coding earns its keep. The governing question is interchangeability: if a new unit can be substituted for an old one with no functional difference to the buyer, the revision marker stays; if anything about fit, interface, dimensions or listed performance changes, the marker moves. Nothing else justifies touching the number.

That rule sounds strict and saves enormous trouble. A colourway corrected for shade batch, a lining swapped for an equivalent specification, or a hardware source changed to an equal part all leave the code untouched, and the field instead records them as running changes against a date. Buyers comparing two units then see one number and understand they are buying the same product.

The counter-example is instructive. Changing a module's attachment — even by a few millimetres — while leaving the code identical means two units ship under one part number with different fit. Returns rise, nobody can prove which version a returned unit is, and the fix requires dual stock control that should never have been needed.

Every revision should therefore carry a visible consequence in the record: date of effect, reason, whether old and new can be mixed in one shipment, and which of them the current listing photography shows. Where old and new must be separated in the warehouse, add a location instruction rather than inventing a sixth code field.

Judgement: Move the revision marker only when interchangeability breaks and never for cosmetic or sourcing reasons, because a number that moves frequently stops conveying anything and a number that moves too rarely stops protecting the buyer.

One Code Across Barcodes, Carton Marks, Customs Papers and Listings

A part number becomes useful only when the same string appears everywhere, and divergence between systems is the most common operational defect. The same code should be the barcode reference, the carton mark line, the packing list entry and the marketplace parent-child variation label, and it should match the label sewn inside the product, which is the one place any buyer can always check; label artwork itself is handled through the labelling and packing service.

Barcodes need their own discipline. The printed symbology encodes either the consumer unit or the carton; each shippable level gets its own identifier built deterministically from the part number rather than assigned randomly, so a scanner can be commissioned from the code alone without phoning anyone.

Export paperwork is where poor coding is most expensive. Commercial invoices, packing declarations and any preferential-origin claim quote line descriptions, and guidance published through trade.gov makes clear that descriptions must match what is actually declared at entry; a number that describes the physical goods accurately — grouping, type, generation — gives the broker something defensible to quote rather than prose.

Inspection records close the loop. Lots are released at AQL 2.5 following the plan in ISO 2859-1, and the report references the code plus revision marker, so a query eighteen months later can be traced to exactly the build that shipped rather than to a style name that has since changed.

Spec rule: Make one string the master across product label, barcode, carton mark, invoice line and listing variation, and write that requirement into the packing instruction, because divergence between those five places is discovered by customs or by a marketplace bot rather than by your own team.

Failure Modes in SKU Numbering and What Each One Costs

Four defects account for nearly all numbering pain. The first is using one code for two physically different units, usually after an "equivalent" component substitution that was not thought interchangeable. It surfaces as a mix-up in the field rather than in the warehouse, because nothing locally distinguishes the two.

The second is the orphan group: a family whose members all retire but whose codes are then reassigned to unrelated products. Reassignment is worse than waste. Retired numbers should be locked permanently, which costs nothing because number space is effectively free while confusion is not.

The third is code drift between systems, where the warehouse knows a reference by one string and the marketplace by another, reconciled monthly in a spreadsheet by whoever remembers how. Drift grows with every new channel and is best prevented by treating the part number as the only permitted key anywhere.

The fourth is over-encoding — packing intended channel, season or supplier into the number. Each such field eventually contradicts reality and forces either a renumbering or an embarrassing explanation.

Our SGS-verified production base holds 4,950 m² of floor worked by 137 people across 7 production lines carrying 149 machines, with output across every running programme near 200,000 units monthly; bag production has been the founder's occupation since 2004 and the company dates from 2014. In practice that means a code revision requested with the sampling round — which takes 6-10 working days, or 12-15 for complex builds — can be cut into labels and carton art at no schedule cost, whereas the same correction after a 35-50 day series build lands mid-season.

Rolling a New Scheme Into an Existing Catalogue Without Stopping Trade

Renumbering live inventory is a migration project, not an afternoon's work. The safe pattern runs three tracks in parallel: new references use the new scheme from their next sample round; existing references keep their old numbers until their next reprint; and a cross-reference table mapping every old code to its new equivalent, published to every channel and alongside the listings held on the product catalogue page before the first new-coded unit ships.

Timing matters more than elegance. Tie each conversion to a natural event — the next production slot, a label reprint, a listing refresh — rather than converting everything at a fixed date, because older units still physically bear the old number and will keep arriving in returns for a season afterwards.

Dual-running needs visible controls. Mark the transition in the warehouse, label both code families where they coexist, and keep the mapping table in a place a night-shift supervisor can reach at short notice, which is when such questions are usually asked.

The commercial constants do not relax during migration. Quantity remains 500 units per reference, settlement runs 30% deposit and 70% balance, quotations arrive within 24-48 hours on an indicative FOB Xiamen basis, and landed planning still uses around 28 CBM per 20GP against 68 CBM per 40HQ. A renumbering that respects those constraints costs nothing in service levels; one that fights them costs a season.