What goes wrong when writing a large batch?
Six failures cover almost every bad batch, and five of them leave no visible trace. A locking option left ticked, a phone moved too early, a mixed batch, a substituted chip, a tag written twice while another was missed, and operator drift as the run speeds up.
The six failures
| Failure | Cause | Visible during the run |
|---|---|---|
| Whole batch locked | A lock option left ticked in repeat mode | No |
| Partial writes | Phone moved before the write completed | Sometimes |
| Mixed families | Two tag types in one delivery | Only if the write fails outright |
| Content too large | Supplier substituted a smaller chip | Only on the first failure |
| Double write and miss | Written and unwritten piles mixed | No |
| Operator drift | Speed increases as the run progresses | No |
Why five of them are silent
Because a tag gives no outward sign of its state. Written, unwritten, locked and half written all look identical in a pile, and none of them can be told apart without a reader.
This is the structural difference between tag production and printing. A misprinted label is visibly wrong. A misprogrammed tag is not, so quality control has to be an explicit step rather than a consequence of looking at the output.
Operator drift, the one nobody plans for
At the start of a run the operator holds each tag carefully and waits for the confirmation. Two hundred tags later they have learned how long it takes and begin moving early.
Writing needs the tag powered for the whole operation, so moving early produces partial writes. The result is a batch that is good at the beginning and progressively worse towards the end, which is exactly the pattern a sample check taken from the top of the pile will miss.
If you sample rather than verify everything, sample from the end of the run.
What prevents them
Check the lock option before starting, every session.
Two physical piles that never touch, and a written tag that never returns to the unwritten side.
One tag read and verified before the run, to catch a substituted chip or a mixed delivery before it costs anything.
A verification pass afterwards, sampled from the end rather than the top.
And a rhythm rather than a race. A run done at a steady pace with confirmations respected is faster overall than one done quickly and reworked.
Frequently asked questions
How do I know if a batch got locked by accident?
Try to rewrite one tag. If it refuses and the tag is otherwise healthy, the batch is locked and nothing recovers it.
Can a partial write be fixed?
Yes, by reformatting and writing again, provided the tag was not locked. The difficulty is finding which tags are affected, since they look normal.
Why would a supplier substitute a chip?
Availability, cost, or an assumption that a comparable chip is equivalent. It is common enough that verifying one tag per delivery is worth making a habit.
Is a sample check enough?
For internal deployments usually. For anything distributed to customers, verify every tag, since the marginal cost is a second each and the failure cost is someone holding a dead card.