Batch and serial labels that let one faulty run be found

A batch is a group of products made together, under similar conditions, at about the same time. For ceramic bowls, a batch might be one firing, using one clay batch and one glaze batch, in one kiln load. Defining batches that way lets the studio trace a fault to the conditions that produced it, rather than to a vague period of production.

A serial, by contrast, identifies a single item within a batch, or sometimes a single item on its own. Serial labelling is more detailed and more work, but it lets the studio find one bowl, rather than a whole firing, when a fault is specific to that bowl, such as a crack that only one bowl developed.

Batch codes should be simple, durable, and unique. A code painted, stamped, or etched on the base of a bowl, or on a durable tag, should survive washing, stacking, and use, and should not be confused with another batch's code. The studio should keep a code list, with each code, its firing date in general terms, its clay and glaze batches, and the number of bowls in that firing, in a log that can be searched quickly.

Serial codes add a further element, such as a number within the batch, so that a bowl can be identified as, for example, the third bowl from a particular firing, rather than merely as a bowl from that firing. That precision helps when a fault affects only some bowls in a batch, and it helps a customer who reports a fault to identify exactly which bowl they own.

Illustration: a studio fires 40 batches of bowls in a year and imagines that 20 of them, in round illustration terms, share the same code because the studio reused a code from an earlier year. Those figures, as presented in Batch and serial labels that let one faulty run be found, are invented, not measured. They show why codes must be unique over time: a reused code makes traceability impossible, because a fault reported against that code could belong to either of two firings, with different glazes and different conditions.

The studio should therefore design codes that cannot repeat accidentally, such as codes that include a year and a firing sequence, and should check new codes against the log before using them, rather than inventing a code on the spot at the kiln.

Marking methods matter for ceramics. A code on a paper label that washes off, or on packaging that is discarded, will not help a customer who reports a fault months later, when only the bowl remains. The code should be on the bowl itself, where practical, in a form that survives normal use, or on a durable record given to the buyer that links the bowl to its code.

• Define each batch by firing, clay batch, and glaze batch.
• Design codes that are simple, durable, and unique over time.
• Mark codes on the bowl itself where practical, not only on packaging.
• Keep a batch log linking codes to firing, materials, and bowl count.

Batch labelling often fails through vagueness. A studio that uses the same code for every firing all year, or that changes code meanings without a log, cannot trace a glaze fault to its firing, and must therefore treat every bowl as suspect when only one firing is faulty. That broad approach harms customers and the studio alike, because it turns a narrow problem into a general one.

Another failure is to mark batches but never use the marks. A batch log that is never consulted when a fault is reported is decoration, not traceability. The studio should test its system by picking a bowl at random, finding its batch in the log, and listing every other bowl from that batch, before a real fault forces that test under pressure.

Close by writing a batch and serial plan for the studio: how batches are defined, how codes are designed, where they are marked, and how the log is kept. That plan should be shared with everyone who fires, marks, packs, and answers customer messages, so traceability works in practice, not only on paper.

Review the plan whenever firing, clay, or glaze practices change, or when a fault is traced to a batch. Each review should ask whether batches are still defined usefully, whether codes are still unique, and whether the log still lets the studio find a faulty run quickly.