Registration problems rarely announce themselves. A pattern that drifts two millimetres across a run will pass a quick look at the first metre and fail a side-by-side comparison at the end of the pallet, and by then the question is not what happened but when. A registration record answers the when, provided it was written while the run was still on the line.
This guide is for private-label flooring teams working with a manufacturing partner on printed surfaces. It sets out what a registration record should contain, how to date the checks, and why the accepted output matters more than the target. It is editorial recordkeeping guidance only: not a print specification, not a registration tolerance, not a colour standard and no substitute for the documents issued by a manufacturing partner.
Fix the repeat reference before the run starts
Registration is measured against something, and that something has to be named. The repeat reference is the file, plate or printed reference that the run is being aligned to, identified by version rather than by filename alone. A file called repeat-final can exist in three places with three different contents, which is why the record pairs the name with a checksum or a dated proof reference.
Name the surface technology the run is producing alongside the reference, since a printed panel that carries Blue Eleven or DSE is making a claim about the surface that the registration reference has to match. Two boards can register perfectly to the wrong reference and still be wrong.
Record each check as an event, not as a status
A record that says "registration checked" is a status, and a status cannot be interrogated. An event has a time, a place in the run, a method and a person. Write those four things for every check, even when the check passed, because the passing checks are what establish that the failing one was an exception.
Place in the run matters as much as time. First-off, mid-run and last-off are three different observations, and a single check somewhere in the middle describes only the middle. Note which one each entry refers to, using the count or the pallet position rather than a description like "early on".
Separate alignment from appearance
Registration and appearance fail differently. A run can be perfectly registered and still read slightly warm, or hold its colour and drift out of alignment at the edges of the web. Recording them in one field merges two kinds of evidence and makes both harder to use.
The table below is a workable shape for a single run record. It is deliberately narrow: one row per check, with the fields that later questions actually ask for.
| Field | What to record | Why it matters later |
|---|---|---|
| Repeat reference | Version identity plus checksum or proof reference | Identifies one artefact rather than a filename |
| Surface technology | Which surface the run is producing | It is the claim the registration has to support |
| Position in run | First-off, mid-run or last-off, with a count | An unpositioned check describes nothing but itself |
| Alignment observation | What was compared against what | It separates registration from colour |
| Appearance observation | Colour or texture notes kept apart from alignment | Two kinds of evidence stay usable |
| Accepted by | Name, role, time and channel of acceptance | It turns a judgement into a decision on record |
Say which output was accepted
The most useful line in a registration record is the one that names the accepted output. Not the target, not the reference, but the specific piece of output that the team agreed to run with: which pallet, which position, which time. Everything after that output is either an attempt to reproduce it or a deviation from it.
Where the accepted output is a physical piece, say where it is kept. A sample that cannot be produced is a memory of a sample, and memory is the weakest evidence in a run dispute. Where the acceptance was given from a photograph or a scan, say so plainly rather than letting the record imply a physical inspection that never happened.
Let every change make its own entry
Adjustments during a run are normal. Plates are re-set, tensions are changed, ink is topped up, and each of those can shift registration by an amount that matters. Record each change as its own entry with its own time, then continue the checks afterwards.
Never rewrite the earlier entries to match the later ones. The sequence is the evidence: it shows what was seen, what was changed and what the effect was. A record that has been tidied into a single consistent story has lost the only information that would explain a difference between two pallets.
Frequently asked questions
What makes a repeat reference usable?
+
A version identity that cannot drift, such as a checksum or a dated proof reference, paired with the filename rather than replaced by it. The record should point at one artefact, so that a later comparison is being made against the same thing rather than against a label that has since been reused.
Why record first-off and last-off separately?
+
Because a single mid-run check describes only the middle of the run. First-off establishes the setting, last-off shows whether it held, and the two together are what make a drift visible. A record with only one position cannot distinguish a stable run from a run that moved.
Should alignment and appearance go in the same field?
+
Better kept apart. A run can register correctly and still read warm, or hold its colour and drift at the edge, and a combined field hides which of the two was observed. Separate fields keep the evidence usable when a question is asked later.
What should be kept after the run closes?
+
The repeat reference identity, the dated check entries with their positions, any change entries, and the identification of the accepted output along with where it is held. Together they let a later reprint be compared to what was actually accepted rather than to what was intended.