Semantics do not line up

A national procurement portal integrates two domestic registries that both expose a field called status with a code active. In the business registry, active means the company has filed its annual return in the last 12 months. In the professional licensing registry, active means the licence has never been formally revoked. A bidder-eligibility check that reads the two codes as equivalent will pass companies whose business filings have lapsed, so long as their licence has not been formally revoked.

The problem

The shapes line up. The meanings do not.

A field named status may refer to registration status, licensing status, programme enrollment, operational status, or data quality. A code named active can mean legally active, recently updated, eligible for service, or simply “not yet suspended.”

Those differences are not cosmetic. They decide whether a downstream service can rely on the value, whether a claim is true, and whether a reviewer can reconstruct the basis for an answer.

Why it matters

When meaning is implicit, the integration code becomes the semantic record. The mapping decision an engineer made on a Tuesday in 2024, in a function nobody else has read since, is now the de facto definition of what active means inside the procurement portal.

An audit asking “what was the basis for this eligibility decision?” has to read the integration code to find the answer. The semantic choice was load-bearing. It was also invisible.

Why common approaches stall

Field mapping spreadsheets are common and often necessary. They stall when the spreadsheet lives in a wiki and the runtime lives in a Helm chart, and nothing forces them to agree.

Shared standards reduce ambiguity by giving teams a common vocabulary. They do not remove the need to say which local field maps to which concept, which value set is used, what freshness applies, and what the deployment does not claim. Two registries can both align to the same standard and still mean different things by active.

Code review at integration time catches obvious mismatches. It misses the ones that look right: same field name, same code, different meaning underneath.

What Registry Stack changes

The registry says what it means, in a form an integrator can read and a reviewer can audit.

Registry Manifest publishes schemas, shapes, catalogue metadata, service metadata, policies, and evidence-offering descriptions. The procurement portal can read what active means in the business registry, and separately what active means in the licensing registry, before it writes the eligibility logic.

Registry Relay binds the declared entities and fields to the runtime sources, so the published meaning is the meaning the API serves.

Registry Notary evaluates configured claims against named source bindings. A signed answer carries the source meaning that supported it.

Registry Atlas lets a reviewer inspect the published graph before integration code is written.

Two registries can still mean different things by active. The procurement portal now sees both meanings and decides what to do, instead of discovering the difference in production. For the broader model, see the architecture overview.

What is built today

Registry Manifest documents renderers for JSON Schema, SHACL, DCAT, BRegDCAT-AP, CPSV-AP, ODRL policy JSON-LD, and CCCEV-shaped evidence metadata. Registry Relay documents entity fields, allowed filters, metadata routes, and scope behavior. Registry Notary documents claim definitions and response formats. Registry Atlas documents strict inspection of published assets.

See the standards register for which standards each project emits, maps to, or aligns with.

What is future-facing or out of scope

Registry Stack does not guarantee that two registries use the same meaning. It also does not automatically reconcile value sets, translate legal definitions, or infer policy from field names.

Semantic review remains a human and institutional responsibility. The technical surface exists to make that review possible and repeatable.