Unique at scale, with no central coordination
Several processes must be able to generate identifiers in parallel without consulting each other and without risking a collision.
This page distinguishes the working website lookup code from the target production format. The twenty-byte scheme requires implementation and cryptographic audit; the example lookup does not validate real signatures.
Visible identity. Connected traceability.
The proposed stamp brings together each unit’s identity and medicine details. The QR opens its lookup; the barcode represents the example print sequence.
Opens this unit’s public URL. A copy of the graphic retains the same identifier.
The readable ID matches the QR and can be entered manually to look up the unit.
Defined for each implementation. This example declares no jurisdiction or actual territorial operation.
The visible domain shows where to look up the identity, including outside this page.
An example number for the printed piece. It is separate from the unit identifier.
A readable Code 128 symbol encoding the example print sequence. It represents neither GS1 identification nor fiscal validation.
Volume comes from the registered presentation: 120 ml for this unit.
The name lets people compare the package with the record of the unit being checked.
Dosage form and strength matching the example medicine.
Manufacturer or importer and declared health reference. RS-EJEMPLO does not represent official approval.
When the identity was issued. It is separate from production, activation or expiry.
A separate field matching the batch of the unit being looked up.
The working example uses the TRZ-XXXX-XXXX-XXXX format and a local record. The requirements below belong to the target design; they do not describe cryptographic checks performed by this website.
Several processes must be able to generate identifiers in parallel without consulting each other and without risking a collision.
Knowing one code must not let you derive others. A simple sequence would be enumerable: someone would print valid “future” codes.
The goal is to validate the signature before querying the registry. The scheme, keys, security and performance must be checked during implementation; this website does not perform that validation.
It has to fit in a small QR with enough error correction to tolerate scuffs, humidity and a curved label.
If the camera fails, the code is typed by hand on the lookup page. That forces grouped characters and a check digit.
TRZ-7F2K-4K7Q-92FA
https://traza.technology/en/verify/?c=TRZ-7F2K-4K7Q-92FA&t=medicamentos The target format reserves twenty bytes in four parts. It is a design proposal awaiting validation, not the twelve-character format of codes that can be queried on this website.
The target representation proposes Base32 Crockford with a typing-error check. The following block is illustrative: it is not a cryptographic test vector or a code recognised by this website’s registry.
In the target format, the check digit would be checked before a service lookup. This website’s reader checks the example identifier format; it does not implement that algorithm or validate a cryptographic signature.
The URL is uppercase on purpose. A QR’s alphanumeric mode encodes more information per module than byte mode, so the same content fits in a QR one or two versions smaller: it scans sooner and tolerates more damage. Scheme and domain are case-insensitive, and the server accepts the path in uppercase.
A short domain matters too: fewer characters mean fewer modules, and fewer modules let you print smaller at the same level of error correction.
TRZ-9FXK-2M4Q-J8TV-QH3N-7WPD-BL5R-XCK
URL inside the QR (uppercase, alphanumeric mode):
HTTPS://T.EXAMPLE/V/9FXK2M4QJ8TVQH3N7WPDBL5RXCK The target architecture proposes addressing the record from the identifier. The described benefits require implementation and measurement; they are not results established by this website.
The epoch addresses the key, so no keys have to be tried. The signature discards junk without touching storage. The embedded issuance points straight at the single record holding the passport. And the position within the issuance is the exact key of the row.
Nothing searches; everything addresses. That is the difference between a random identifier — which forces a database lookup even to discard junk — and a signed one, which decides valid or invented before asking anything.
A code’s validity is proved by derivation, not by a stored row. Issuing an order writes one record with its size and its state; the labels exist mathematically from that moment. The row for a specific label is born on its first lookup, so only the units somebody actually looks at take up space.
There is no proprietary hardware: each issuer prints with its own infrastructure. What is fixed is the minimum that makes the code readable in a shop with bad light.
The issuer picks a system template and does not edit the layout: the system injects the data. That way a label printed today and one printed next year are comparable.
The same code with the same template version produces a byte-for-byte identical file. Artwork need not be stored: it is regenerated.
A vector imposition PDF, with cut and registration marks and bleed, to run full sheets.
Native thermal-printer language, to label in line at the machine’s own speed.
A variable-layer-only output, when the security background is already pre-printed in offset.
The integration reference describes the target API. Public lookup lets you explore this website’s available example codes, with their results and limits explained.