Our GS1 resolver conformance run

The run

On 12 August 2026 we pointed GS1’s public resolver conformance test suite at a live packagepage resolver and it returned 30 pass, 1 warn, 0 fail, exiting zero.

The Digital Link URI under test was https://pkgedge.com/01/09520123456788. That address is public and it is still answering, so you do not have to take any of this on trust: open the suite, paste the URI, and run it yourself.

The complete machine output of that run is published here, unedited: the run’s raw JSON. It carries every criterion the suite checked, the message it returned for each, and the exit code. It is the same file the repository keeps as the run’s evidence, byte for byte.

What the suite is, and what passing it means

The suite is GS1’s own, it is public, and it needs no account. It tests a resolver against the GS1-Conformant Resolver Standard 1.2.0 — that a Digital Link URI is validated before it is answered, that a request for a specific link type gets that link or a 404 rather than something approximate, that the whole linkset can be requested and comes back as RFC 9264 JSON, that content negotiation is honoured, that a description file is published, and that cross-origin requests work.

Passing it means our resolver did those things on that day, at that address. That is the whole of the claim.

It is not a certification. There is no certification to have. GS1 does not endorse, certify or operate this service, and nobody at GS1 has reviewed our code. The suite is a tool anyone can point at anyone’s resolver, including ours, and the only thing that makes our result worth anything is that you can repeat it.

The one warning, named

A tally of 30 pass and 1 warn is not a clean sweep, and rounding it to one would be the kind of true-but-incomplete statement we would rather not make about ourselves.

The warning is linkOnRedirect: “No link to the linkset detected when redirecting.” The suite records that GS1’s own reference resolver returns the same warning on the same criterion, which is why our evidence file classifies it as shared with the reference. That is context, not an excuse — it is a real difference between what we return and what the suite would prefer to see, it is written down in the artifact above, and it is ours to close.

What this run does not cover

The suite does not test compression. A Digital Link URI can be carried in a compressed form, and a resolver is expected to decompress it before doing anything else. No criterion in this suite exercises that path, so a green run tells you nothing about it either way.

We know this because we read the suite rather than its summary, and it changes what a passing result is worth: conformance-green is necessary and it is not sufficient. Our own Digital Link library carries test vectors for compressed URIs derived from the specification directly, because the public suite would not have caught a defect there.

Why the run is dated rather than continuous

There is no live badge on this page and there is not going to be one until it means something. A badge that goes green on a schedule is a claim about today; what we publish is a claim about a day, with the output attached.

Each run we publish gets its date, its target, its tally and its raw file, and the old ones stay up. A conformance record that only ever shows the most recent result is a record you cannot check for the thing that matters, which is whether it has ever gone backwards.