Integrations become one-off negotiations

A national farmer registry has been integrated with an extension service, a subsidy programme, and a crop insurance provider. Each integration started with the same questions (“what fields exist? what do they mean? what does crop_type cover?”) and was answered separately, in a separate email thread, with a separate spreadsheet attached. A fourth partner has just asked to integrate. The same conversation begins again next week.

The problem

The questions repeat. The answers do not get reused.

Every caller asks the same things: what data exists, what fields mean, how codes are defined, which endpoint to call, which policy applies, what test data and expected responses look like. The registry owner answers them in an email thread. The answers drift into deployment notes, integration code, and tribal knowledge nobody else can read.

Why it matters

The third integration takes as long as the first. The fourth caller asks the same questions, and the registry team writes the same explanations into a fresh email thread. The negotiation never compounds; the cost of every new partner is roughly the cost of the previous one.

When the source changes, the owner has no one place to publish it. Each partner carries its own version of the integration, its own assumptions about what changed, and its own copy of fields the owner can no longer see into. The change goes out by phone and email, partner by partner.

Why common approaches stall

Integration templates accelerate one known partner pattern. They stall when the next caller has a different legal basis, different field needs, or a different evidence shape, and you discover the template was actually the previous partner’s integration with the names changed.

Point-to-point middleware moves data between two named systems. It stalls when a third system needs the same data with a different scope and the middleware has no contract anyone outside engineering can inspect.

A wiki page documenting the API captures the answers once. It stalls the first time the answers fall out of date, because nothing forces the wiki to track the source.

What Registry Stack changes

The questions get answers once, in artifacts every partner can read.

Registry Manifest publishes the metadata, schemas, code lists, and policies the registry actually exposes. The third partner reads the same description as the first.

Registry Relay exposes protected, read-only API contracts for configured entities. The contract is the same artifact every caller integrates against.

Registry Notary publishes configured evidence responses where a caller needs a status, predicate, selected value, or credential-shaped artifact instead of a broad record.

Registry Atlas lets a new partner inspect the published artifacts before any code is written, so the first integration meeting is about purpose, not about discovery.

The fourth partner still starts a conversation. The conversation starts from artifacts that have already been built, reviewed, and tested. For the broader model, see the architecture overview.

What is built today

The current site documents Registry Manifest render outputs, Registry Relay route shapes, Registry Notary claim definitions and response formats, and Registry Atlas inspection. OpenAPI references are published for Relay and Notary under the reference section.

See contracts, Registry Relay API reference, and Registry Notary API reference.

What is future-facing or out of scope

Registry Stack does not automate institutional approval, legal review, or partner onboarding. It also does not replace workflow engines, exchange layers, or sector platforms.

The ecosystem page explains how registry-facing contracts fit with workflow tools, exchange layers, wallets, and sector platforms. That positioning is guidance, not new runtime behavior.