One thesis: a resolver's answer is a linkset — RFC 9264's typed list of every door an identifier opens — and a bare list of URLs is not an answer an agent can act on; only a linkset whose every link carries its source, license class, and freshness is, and that combination is what this resolver returns.
The verifier class of agent is the hardest audience a resolver can serve, so this post is written to it. A verifier does not browse; it checks. It arrives, often with no human in the loop, holding an identifier and a question of the form is there an authoritative door for X, and may I use what is behind it? Both halves of that question must be answerable from the response itself — deterministically, without a follow-up, without prose.
The shape of the answer
Ask for the catalog — ?linkType=linkset, or Accept: application/linkset+json — and the standard's rule applies: the resolver does not redirect; it returns the full list. For one GTIN, the actual response shape:
{
"linkset": [{
"anchor": "https://barcoding.dev/01/00016000275270",
"itemDescription": "canonical identity: gtin-14 00016000275270 (scheme page: /schemes/gtin)",
"gs1:defaultLink": [{
"href": "https://brand.example/p/granola-bar",
"title": "brand product page (via the brand's own resolver)",
"provenance": { "source": "brand-published digital-link redirect",
"license": "pass-through", "fetched_at": "2026-07-31T18:20:11Z" }
}],
"gs1:nutritionalInfo": [{
"href": "https://barcoding.dev/enrich/00016000275270#nutrition",
"provenance": { "source": "usda-fdc", "dataset_version": "FDC 2026-04",
"digest": "sha256:…", "license": "public-domain",
"fetched_at": "2026-07-31T18:20:11Z" }
}],
"gs1:traceability": [{
"href": "https://epcis.dev",
"title": "event history door — 14 events · last posted 2026-07-30T22:41:09Z",
"provenance": { "source": "family: epcis.dev", "license": "caller-scoped" }
}],
"gs1:certificationInfo": [{
"href": "https://id.org.ai",
"title": "who attestation door — Agent. Human. Thing.",
"provenance": { "source": "family: id.org.ai", "license": "caller-scoped" }
}]
}]
}Every entry answers three typed questions: what kind of door (the linkType — from the GS1 Web Vocabulary for GS1 keys, labeled extensions beyond it), where it leads (the href), and — the part nothing else in the field carries — on what authority it is listed: source, dataset version and digest where one exists, license class from the same closed enum the enrichment envelope uses, and fetch time. The transaction-context door (transactions.dev's side of the family) rides the same shape when the identifier has paperwork.
Why bare URLs fail the verifier
Walk the agent's checklist against a conventional resolver response — a list of hrefs:
- May I persist what is behind this link? Unanswerable. No license class travels with the link; the agent would have to fetch the target, find its terms, and interpret prose — which a fail-closed agent cannot responsibly do inside granted authority.
- Is this door current? Unanswerable. No freshness signal; a link minted three years ago and a link verified this morning are indistinguishable.
- Who says so? Unanswerable. A URL asserts nothing about whether the resolver's operator had any right to list it, or whether the target is the brand's own surface or a scraper's.
The provenance-wrapped linkset converts all three into field reads. license: "public-domain" → persist freely. share-alike-odbl → carry the notice. caller-scoped → the door answers per-caller and grants nothing by listing. pass-through → this is the brand's own published redirect, resolved through, not replaced. A verifier filters mechanically and acts inside its mandate — no narrative, no judgment calls, which for this class of caller is the entire definition of usable.
Chips are live data or absent
Look again at the traceability entry's title: 14 events · last posted 2026-07-30…. That posted-context chip is governed by a rule as strict as the license enum: a chip is live data or it is absent. No door ever carries "explore the product journey!" or any other unfalsifiable garnish, because a linkset is a factual instrument and one decorative field would poison the trust model of every other field. A door with nothing true and current to say about this identifier says nothing — or is not listed.
The same discipline governs failure. Ask for a linkType this identifier does not have — ?linkType=gs1:recallStatus on a product with no recall door — and the answer is 404, per the resolver standard, never a redirect to something adjacent and never a page explaining what you could buy. For an absent-presence agent, an honest 404 is infrastructure: it terminates a check with a verdict instead of a detour.
The family map, read as a linkset
The response above is also the truest single picture of what this property is: identity resolution in the anchor, the license-clean answer layer in the enrichment doors, and typed doors into the sibling records — events, transactions, and the Who at problem-grain (an attested observer is a different fact from a warrantor account, and the door that resolves observers is id.org.ai's to serve). One identifier in, every door out, each with receipts. The conformance half of this design — description file, RFC 9264 behavior, default-link semantics, and why anyone may lawfully run one — is the previous post.
Hosted resolution — id.org.ai's capability, served through this property's door — is the gated half of the property. If your agents — or the humans provisioning them — need identifiers answered as typed, provenance-carrying linksets rather than as lists of unexplained URLs, tell us who you are. And hold every resolver you evaluate, the family's one resolver included, to the verifier's standard: an answer you cannot filter mechanically is not an answer; it is homework.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.