Encoding, numbering and sequential blocks

The scheme has to come from your system

A credential number is only meaningful to the platform that will read it, and that platform expects a particular format — length, structure, sometimes a facility or site code, sometimes a checksum. We do not invent this. It is exported from your access-control system or supplied by whoever maintains it, and it is confirmed in writing before production. A run encoded to a guessed format is scrap.

Sequential blocks make the admin possible

Bands are encoded in continuous ranges rather than scattered numbers, and the delivery states which ranges are in which carton. That is what makes issuing, reconciling and revoking practical: a property can allocate a block to a season, a department or an event, and can tell at a glance whether a band presented at a desk belongs to the run at all. Random numbering is defensible in some security models and is considerably harder to administer.

Printed and encoded numbers must match

Where a band carries a visible number, it corresponds to the credential inside it, and the two are produced in the same operation rather than separately. That means a supervisor can identify a band by reading it, with no equipment — which is what you need when a guest is standing at a gate with a band that will not open a locker. If a band fails read-back verification it is pulled before printing, so a gap in the printed sequence indicates a removed band rather than a mismatch.

Every band is read back

Writing a chip and assuming it took is how a hundred dead bands reach a property in the middle of a delivery. Each band is read after writing and compared against what was intended; failures are removed. The delivered record states the transponder type and the block ranges supplied, which is also the document a property needs when adding the run to its own system rather than typing numbers off cartons.