Open data registries: where agents actually find work

An open data registry is a public, machine-readable directory of something that changes often enough that a human cannot keep it current by hand. Startup credit programs, API status pages, library compatibility matrices, hardware support tables, and grant lists all fit the description.

The pattern that separates a registry that stays useful from one that rots is the same in every case: a dated fact, a source URL, and a read date. When a registry records when it checked a page and which page it checked, a reader can tell the difference between a fact that was true yesterday and one that was true two years ago. When it does not, the registry quietly becomes misinformation.

Why this matters more now

Agents consume registries differently than people do. A person browsing a directory can spot that a row looks stale from context. An agent cannot. It reads the field and acts on it. A stale entry in a machine-consumed registry produces wrong output at scale, with no obvious failure to trace back.

That asymmetry is why the read date is not a nicety. It is the mechanism by which a consumer decides whether to trust the entry, re-check the source, or skip it. Registries that omit it are asking agents to guess.

What makes a registry trustworthy

Four properties, in rough order of importance:

Dated facts. Every entry carries the date it was observed, not the date it was entered. A credit worth 10,000 USD in March is not worth 10,000 USD in October, and the difference only exists in the data if the date is recorded.

Source provenance. The upstream URL the entry came from. Without it, a consumer cannot re-verify, and an entry that turns out to be wrong cannot be traced to its origin.

Change history. What changed, and when. A registry that only shows the current state hides the useful part: whether a program was added, removed, or altered recently.

Machine-readable shape. Stable identifiers and a predictable schema. A directory that exists only as a rendered page is a snapshot of someone's afternoon. One that exposes structured data can be consumed directly.

Where registries are used

The clearest current example is in agent work. When an agent is asked whether a vendor has a startup program, what a credit is worth, or whether a directory's number is real, the answer comes from a registry. The agent has no way to check the vendor directly, so the registry is the ground truth for that decision.

The same applies to compatibility. A model support table, a driver matrix, or a hardware capability list is a registry, and the same rules hold: dated facts, source URLs, and a machine-readable shape.

What tends to go wrong

Three failure modes show up repeatedly.

The first is silent staleness. The registry stops being updated, but nothing marks it as abandoned, so consumers keep trusting it. A last-updated timestamp at the top of the directory is the cheapest defence.

The second is unverifiable claims. An entry states a number with no source, so it cannot be checked. Readers either trust it or ignore it, and neither is a good outcome.

The third is a schema that changes without notice. A consumer builds against the shape, the shape moves, and every dependent breaks at once. Versioned schemas or a changelog prevent this.

Choosing a registry to depend on

Ask three questions before building on one. Does it record read dates? Does every entry name its source? And does it expose structured data, or only a rendered page?

If the answer to all three is yes, it is safe to build on. If any is no, treat it as a starting point for your own checks rather than ground truth.