What Reaches the Machine: The Card Your Specification Becomes

Most buyers assume their specification reaches the plant in the form they sent it. It does, and then it stops. Between the order file and the machine is a step nobody photographs: a person reads the order and retypes the parts that matter into the plant's own production card, known as a work order, a job ticket or a route card.

Products in this guide: Reactive Glaze Ceramic Mug 390-400ml · Porcelain Ceramic Soup Bowl

The card is short, because it has to be: it goes to a setter, a decorator, a kiln loader and an inspector, none of whom can work from thirty pages. The plant compresses, and the compression is lossy in ways that repeat from order to order. So the question before the next purchase is not whether the specification is detailed enough, but which requirements can survive the transit at all.

See the full ceramic sourcing process map.

The requirement changes hands before it changes anything

The handover is a person with a screen. A merchandiser opens the purchase order and types into a production system, and what they type is shaped by the fields that screen offers. Those fields are shaped by what the plant needs in order to schedule, not by what you need to control.

Two factories can therefore receive the same file and produce different things without either ignoring you. One has a card with a free text note the planner actually uses; the other has a card that will not accept a sentence. Your requirement did not change. The container it travels in did, and a point raised three times by email can be absent from the run not because anyone forgot it but because it never entered the only object the operator reads.

What a production card actually holds

The form differs by plant, but the skeleton is stable.

• The internal item code and a short description
• The body, and the size in the plant's own measurements
• A colour reference, usually a code or a sample number
• The decoration reference, and where it sits
• The quantity for the run, and the pack configuration
• The delivery date the run must meet, and the destination

Six of those fields exist so the plant can schedule. There is no field for a condition, a reason or an allowance.

The three things that do not fit on a card

The first casualty is the qualifier. A card holds single values, so a requirement written as a condition loses its condition. A matt exterior with a gloss handle becomes matt, and a decoration on the front face only becomes a reference the decorator applies wherever it implies.

The second is the reason. Specifications often carry their justification, because it persuades a supplier to accept a tight number. On the floor a reason is not actionable: an operator told the piece must survive a dishwasher can do nothing with that sentence until it becomes a glaze, a firing curve and a test.

The third is the acceptance allowance. Tolerance language belongs to the inspector, who rarely reads the same sheet as the setter. A card saying white and 350 ml has nowhere to record that shade variation is acceptable within a limit and not beyond it. The setter aims at perfection, the kiln produces a spread, and the argument that should have ended at inspection begins there.

Why a two-value requirement becomes one value

The costliest version happens when an order contains two of something: two colourways, two sizes, two decoration positions. A card expresses one value per field, so the plant either splits the order into two runs with two cards, or someone picks the value that seems to represent the whole.

The first is manageable if the split is visible to you and the dates stay joined. The second is where reorders drift. Your approved sample stands for one value; if the card was typed from the other, the run is right against the card and wrong against the sample, and each side can prove its case.

The cheap mitigation belongs at quotation stage: ask that the order be carded as two runs wherever a field can hold two values. A plant that cannot is telling you something before it has produced a piece.

The code on the card is not your code

The card is keyed on the plant's item code, and yours is a different string. The mapping lives on someone's desk, which matters twice.

It slows every conversation: order the same mug for three years without learning the plant code and each reorder begins with a description and a photograph rather than a number. And a new code can be created for an object that has not changed, so a different pack or a small revision to the decoration file opens a new item instead of revising the old. The next run is scheduled from a card with no history.

One page you can hand over, and two questions that cost nothing

The practical response is not to demand access to the plant system but to supply a one-page line card whose fields follow the card the plant already uses: object and code, body and size, colour reference with its sample number, decoration reference with its file and version, pack configuration, and one line naming what must not change.

Then ask two cheap questions. May we see a photograph of the card at the machine on the first run: a plant that answers within a day has a working chain, and one that cannot has a chain ending at the office door. And which field would change for a different colourway in the same body. The answer tells you whether the system can express your variant, or whether it will become a new code with no history.

The spec freeze guide explains how artwork and packing files are locked between orders.

Where this belongs in the order file

Put it in the quality annex, next to the specification it depends on, as three short instructions rather than an essay.

State that the specification is transcribed into the card without abbreviating the colour reference, the decoration reference or the pack configuration. State that where a field admits two values the order is carded as separate runs, with both numbers in the confirmation. And state that a photograph of the first-run card is shared as a record, not as an audit.

None of the three asks the plant to change its system, which is why they tend to be accepted. What they do is close the gap between the document you wrote and the object that arrives, and that gap is where most arguments in a long ceramic programme are born. The master sample guide explains how sealed references keep batches identical.