Embedded Semantics as Governed Semantic Identity Infrastructure: Strategic and Technical Research Report

Full report

On this page

Executive thesis and current-system assessment

Scope and method. This is a black-box assessment based only on public websites, public documentation, specifications, standards material, and published research. No source code was available or inspected. Consequently, statements about Embedded Semantics below describe its publicly observable design and claims, not hidden implementation quality, security, scalability, or correctness.

Proposal horizon labels used throughout this report: NEAR TERM means approximately the next twelve months; MEDIUM TERM means roughly one to three years; LONG TERM means roughly three to five years; SPECULATIVE means research that should proceed only if earlier evidence is unusually strong.

Executive thesis. The strongest defensible interpretation of Embedded Semantics is not “a new way to give concepts identifiers.” That primitive is old and well established. RDF uses IRIs to identify resources; SKOS explicitly models concepts identified by URIs; OWL adds formally defined semantics; healthcare code systems such as SNOMED CT issue unique machine-readable identifiers for clinical concepts; ISO 20022 maintains governed business concepts; NIEM uses governed common and domain vocabularies; industrial standards already attach semantic identifiers to modeled elements.

The defensible opportunity is narrower and more interesting:

A lightweight, developer-native semantic identity layer that gives APIs, events, agents, memories, data products, and schemas durable nominal identifiers for intended meaning, while deliberately separating authoritative identity from probabilistic language interpretation.

That positioning turns Embedded Semantics from a putative alternative to RDF/ontologies/LLMs into a thin interoperability profile over them.

The sharpest technical problem is:

Two systems can agree on data shape yet still be unable to prove that two fields, messages, actions, metrics, or remembered facts mean the same thing. Names are mutable and language-dependent; schemas primarily constrain structure; embeddings estimate similarity rather than establish identity; LLM prompts interpret rather than govern; and rich ontology technology is often more machinery than application developers will adopt. A missing middle exists when deterministic, auditable semantic continuity is valuable but a full ontology stack is not.

OpenAPI itself defines a schema as a formal description of syntax and structure; schema registries such as Confluent focus heavily on compatibility between evolving schema versions. Neither by itself establishes that independently authored fields called, for example, customer, client, and account_holder denote the same business concept.

That missing middle is the possible category.

Current-system interpretation

The public Embedded Semantics site already contains several good architectural instincts. It describes “registry-backed multilingual concept identity,” states that reviewed multilingual expressions attach to stable ConceptCodes, keeps provenance and version information, treats vectors as retrieval evidence rather than the source of truth, uses exact reviewed expression resolution in the production path, and abstains when authoritative resolution is unavailable. Its research methodology explicitly distinguishes concept resolution from generic similarity and evaluates hard negatives, cross-language behavior, retrieval metrics, false neighbors, margins, and abstention.

That separation is important. The architecture is implicitly saying:

\[ \text{text} \;\xrightarrow{\text{probabilistic evidence}}\; \text{candidate concept} \]

is different from:

\[ \text{governed assertion} \;\xrightarrow{\text{deterministic lookup}}\; \text{Concept ID}. \]

That is a sound distinction.

The major caveat is maturity. As of August 23, 2026, the public Embedded Semantics status surface reports zero published concepts, zero reviewed exact expressions, zero of eleven bootstrap concepts deployed, and the semantic runtime inactive; the public registry API likewise returns an empty collection. The site describes a pre-release/repository-side bundle, but the publicly deployed authority surface does not yet constitute evidence of registry adoption, operational scale, federation, or external use.

Therefore this research treats Embedded Semantics exactly as requested: an early technical thesis with a promising separation of concerns, not a demonstrated standard or mature infrastructure product.

The related projects reinforce a recognizable design philosophy, but they should not be treated as independent validation. JustAnIota describes IOTA-1 as a compact structured AI-message profile using Unicode constraints, registries, canonicalization, schemas, validation, and evidence, and explicitly says Unicode is a substrate rather than semantics by itself. Protocol5's public material emphasizes compact semantic cues, registries, ranked candidates, vector evidence, and an evidence workbench. Mike Kappel's public site describes work on persistent AI memory, agent identity, scoped context, reviewed memory, and multi-agent coordination.

Inference: across these public projects, the recurring thesis appears to be identity + registry + evidence + validation + governed machine handoffs.

Strongest form of the core idea

NEAR TERM — Treat semantic identity as a nominal type annotation, not as a new ontology.

A Concept ID would say, “this field/action/event/memory is intended to denote concept X,” in the way a nominal programming-language type says an object belongs to a named type independent of its structural resemblance to another object.

That yields a potentially useful division:

The idea becomes valuable when those layers remain separate.

MEDIUM TERM — Make mappings first-class signed assertions. A concept registry should not merely contain concepts. The economically valuable artifact is often a maintained assertion such as:

private-enterprise:invoice-total → exact/equivalent/compatible-with → industry:monetary-total

with issuer, provenance, evidence, scope, date, and revision.

MEDIUM TERM — Federate authorities instead of attempting global semantic truth. Healthcare authorities should govern healthcare concepts; financial authorities should govern financial concepts; enterprises should govern their own private terms. The infrastructure should govern how identities and mappings are published and resolved, not centrally decide what the world means.

LONG TERM — Add semantic contracts only where explicit formal relations make static checking defensible. Concepts could eventually behave like semantic types across organizational boundaries, but only if the compatibility relations are much more precise than “these two things seem related.”

Strongest argument against the core idea

The strongest objection is severe:

Most of what Embedded Semantics proposes at the conceptual level already exists somewhere, and the unsolved problem may be adoption and governance rather than technology.

SKOS already provides URI-identified concepts and concept schemes. OWL provides formally defined meanings and relationships. SHACL validates graph constraints. JSON-LD embeds linked-data identifiers into JSON. FHIR terminology already distinguishes code systems, value sets, and concept mappings. SNOMED CT demonstrates governed concept identifiers and even has a compositional grammar. NIEM demonstrates common vocabulary plus independently governed domains. ISO 20022 maintains financial business concepts under release governance. OPC UA and related industrial information models already expose machine-readable domain semantics.

If developers rejected those approaches because semantic curation is expensive, introducing a new identifier format will not fix the problem.

The real test is therefore not whether ConceptCodes can work. They can. The test is:

Can a dramatically thinner developer experience make governed semantics cheap enough that teams who would never deploy an ontology begin annotating APIs, events, agents, and memories?

If the answer is no, Embedded Semantics should probably collapse into a small profile or library around existing semantic-web standards rather than become a new ecosystem.

What should remain unchanged

NEAR TERM — Preserve the deterministic/probabilistic firewall. The current public design's strongest feature is treating vectors as candidate evidence and authoritative registry resolution as a separate operation.

NEAR TERM — Preserve explicit abstention. “Unknown” and “ambiguous” must remain legitimate results. Forcing every expression into a Concept ID would merely encode model hallucination in a seemingly authoritative identifier. Embedded Semantics already recognizes abstention as part of its methodology.

NEAR TERM — Preserve multilingual expressions as labels on a concept, not separate identities for translations. This is one place where a stable identity genuinely improves on string keys.

NEAR TERM — Preserve provenance and immutable history. A Concept ID without a record of who asserted its meaning and how that record changed is not governed semantics.

NEAR TERM — Preserve model independence. A concept's identity should not be regenerated because an embedding model changes.

What should be reconsidered

NEAR TERM — Reconsider ConceptCode as the canonical identifier format. “ConceptCode” can remain a convenient compact token, but the ecosystem-facing canonical identity should preferably be a globally unique URI/IRI controlled by its authority. RDF and SKOS already establish this convention, and JSON-LD already provides a developer-compatible way to carry those identifiers in JSON.

NEAR TERM — Reconsider a single global registry. A mandatory central resolver creates an unnecessary availability, governance, economic, censorship, and lock-in choke point.

NEAR TERM — Reconsider “stable” as meaning “unchangeable regardless of semantic drift.” Editorial improvements can retain an identity. A material change in denotation must create a new identity or a clearly different semantic revision relationship. Keeping the same Concept ID while silently changing what it means would be worse than string drift because downstream software would falsely believe semantic continuity had been guaranteed.

MEDIUM TERM — Reconsider atomic-only concepts, but do not jump to universal composition. Atomic identifiers should remain the base layer. Composition should be an explicit, typed expression language above them.

SPECULATIVE — Do not make executable Concepts part of the identity layer. Attaching arbitrary execution semantics directly to concepts would mix description, authority, code execution, and security. Behavior should remain separately versioned, signed, sandboxed software referenced by a semantic contract when necessary.

Category, problem, alternatives, and competitive landscape

Category definition

The category I would use is:

Governed Semantic Identity Infrastructure

A more developer-oriented description is:

Stable semantic IDs for interoperable software systems.

It should be defined by six properties:

1. An identifier denotes a governed concept rather than merely a spelling.
2. The identifier survives label, language, schema, and model changes so long as the intended concept itself remains materially the same.
3. Definitions, labels, mappings, authority, and provenance are separately versioned.
4. Systems can resolve identifiers without an AI model.
5. AI models may propose mappings or resolve language to candidate identifiers but cannot silently become the authority.
6. Registries can be independently operated and federated.

The novelty, if there is one, lies in operational packaging and developer adoption, not the philosophical notion of concept identity.

The actual pain

The strongest problem is semantic drift across independently evolving boundaries.

Consider three systems:

System A                    System B                  System C

customer_id                 accountHolder             partyIdentifier
string                      string                    string

schema: UUID                schema: string            schema: string
meaning: ?                  meaning: ?                meaning: ?

A schema can tell a consumer whether customer_id is a UUID. It cannot, without additional semantics, prove that customer_id, accountHolder, and partyIdentifier mean the same business role.

Likewise, Protocol Buffers can provide stable field numbers and strong wire compatibility, but Google explicitly warns that reusing field numbers creates ambiguity and can cause parsing problems, data corruption, or sensitive-data leakage. That is durable wire identity, not durable business meaning.

The pain is most acute where all four conditions hold:

multiple independent producers + long-lived integrations + semantic evolution + consequences for getting meaning wrong.

This points toward APIs, event systems, agent capabilities, durable memory, enterprise data integration, and selected regulated workflows.

Who feels the pain today

The immediate sufferers are not ontology researchers. They are:

Integration and platform engineers maintaining N×M mapping logic among independently versioned systems.

API and event-platform teams that can enforce structural compatibility but still need human documentation to understand what fields and messages denote.

Data-governance and master-data teams maintaining business glossaries whose identifiers are not consistently carried into application runtime.

Agent-platform developers trying to decide whether two tools or agents perform equivalent actions even when skill descriptions differ.

AI-memory teams that want model-independent anchors while embeddings and extraction models evolve.

Regulated integration teams that need to explain why a machine treated two differently worded concepts as equivalent.

Alternative-technology matrix

RDF/SKOS already establish identifier-based semantic modeling; OWL and SHACL add richer formal semantics and constraints. OpenAPI and schema registries address structural interface descriptions and evolution. Embeddings and vector databases address approximate retrieval, and current research continues to document that embedding-model upgrades can require substantial re-encoding or adaptation of vector indexes.

This table implies an important strategic rule:

Embedded Semantics should win by composition with existing infrastructure, not by replacement.

Competitive landscape

Semantic-web standards are the strongest intellectual competitor. SKOS is especially important because it already models identified concepts with multilingual labels and mapping relations. Any Embedded Semantics specification that cannot cleanly map its core records into SKOS/RDF should explain why; otherwise it risks merely reinventing a smaller, incompatible semantic-web stack.

Knowledge-graph and ontology-governance platforms are strong enterprise competitors. TopQuadrant publicly positions TopBraid around governed ontologies, taxonomies, reference data and reusable standards; Stardog positions a knowledge-graph-powered semantic layer for enterprise data and AI. These vendors demonstrate that enterprises already buy semantic governance—but generally as part of broader data platforms.

Schema registries are the nearest developer-infrastructure competitor. Apicurio Registry supports Avro, JSON Schema, Protobuf, OpenAPI, AsyncAPI, GraphQL and, notably in its current documentation, MCP tool artifacts. Confluent Schema Registry provides central schema management and compatibility checks. These products already occupy a natural place in CI/CD and event architectures.

That suggests a particularly attractive positioning:

A semantic registry should initially look more like a semantic companion to a schema registry than an ontology-management suite.

Agent protocols are opportunity surfaces rather than competitors. Current MCP tools are identified primarily by tool names plus descriptions/input schemas, while A2A Agent Cards expose skills with IDs, names, descriptions, tags, examples and modes. A2A also supports URI-identified extensions. That provides obvious extension points for semantic capability identifiers without inventing another agent protocol.

Domain standards are incumbents that should usually be treated as authorities. SNOMED CT identifies clinical concepts; LOINC provides standardized observation identifiers; FHIR ConceptMap explicitly maps between terminology systems; ISO 20022 maintains financial business concepts; GS1 maintains product vocabularies; NIEM organizes government semantics across common and domain models; OPC UA Companion Specifications provide domain-specific information models.

Where the idea is genuinely differentiated

The potential differentiation is the combination of:

low ceremony + runtime-friendly IDs + deterministic authority + multilingual resolution + explicit abstention + private/public federation + model-independent identity + mappings into existing standards.

None of those ingredients individually is novel.

The ecosystem thesis succeeds only if the combination is significantly easier for application developers than deploying SKOS/OWL/knowledge-graph infrastructure directly.

Use cases, adoption, and market prioritization

The rankings below are strategic estimates, not measured market statistics. “Technical rank” asks how uniquely semantic identity addresses the problem. “Adoption rank” considers integration friction, existing incumbents, and whether the feature can be added incrementally. “Market rank” asks whether organizations plausibly have budget and consequential pain around the problem rather than estimating an unsupported total-addressable-market number.

Ranked use-case portfolio

Highest-value use cases

NEAR TERM — Cross-application enterprise integration.

This is the strongest problem because structural integration already exists while semantic mapping remains manual.

Suppose three independent systems describe:

System A: invoice.total
System B: document.amount_due
System C: billing.final_charge

A governed semantic layer could annotate all three with the same organization-approved concept identifier while letting each system retain its schema.

That creates value in:

• impact analysis when one schema changes;
• mapping generation;
• documentation;
• lineage;
• migration;
• AI tool grounding;
• cross-language interfaces.

The key requirement is that the Concept ID must not become another canonical data model that every system is forced to adopt. It should be metadata over existing models.

NEAR TERM — API semantic typing.

This is probably the easiest first adoption path. OpenAPI permits x- specification extensions, and the OpenAPI Initiative's extension registry already includes JSON-LD-related extensions intended to enable semantic interpretation and interoperability.

An early Embedded Semantics profile could therefore require no new transport:

amount:
  type: number
  x-semantic-id: "urn:example:concept:monetary-amount"

The schema says number. The semantic annotation says what the number denotes. A later constraint profile might identify unit/currency requirements.

The killer demo would be generating safe adapter mappings between two independently authored APIs using identifiers rather than field names.

NEAR TERM — Semantic events.

CloudEvents exists precisely because event producers otherwise describe event metadata differently, while AsyncAPI describes message-driven APIs and supports references to schema registries. CloudEvents also explicitly allows extension attributes.

A semantic extension could attach governed identifiers to:

• event kind;
• subject role;
• important payload fields;
• business outcome.

The value is not a new broker. It is allowing middleware to reason about semantically compatible events from independent producers.

For example:

vendor-A.customer.deleted
vendor-B.account.closed
enterprise.party.deactivated

may be structurally different and not necessarily equivalent. The semantic registry can make the relationship explicit rather than forcing a consumer to infer from names.

This use case is especially strong because event architectures already experience schema evolution and registry usage, making an adjacent semantic registry concept easier to understand. AsyncAPI documentation itself describes schema registries as repositories for managing and validating message schemas.

NEAR TERM — Agent capability identity.

A2A skills currently include textual metadata such as name, description, tags and examples; MCP tools expose names, descriptions and schemas. Those are ideal for human and model interpretation but do not by themselves establish that two independently named capabilities perform the same semantic action.

Semantic IDs could annotate an agent capability with concepts such as:

retrieve-order-status
cancel-order
request-refund
verify-customer-identity

Then negotiation becomes:

1. Discover candidate agents through A2A/MCP mechanisms.
2. Match required semantic capability identifiers.
3. Check schema compatibility.
4. Use LLMs only to handle unmatched/fuzzy candidates.
5. Execute through the native agent protocol.

This is much more defensible than inventing a proprietary “semantic agent protocol.”

MEDIUM TERM — Durable AI memory.

An agent-memory record should not consist only of text plus a vector. A hybrid record could contain:

original evidence
structured entities
governed Concept IDs
temporal context
source/provenance
confidence/assertion state
embedding(s)
embedding-model version

Concept IDs can remain stable while embeddings are regenerated.

Recent research on embedding-model upgrades explicitly addresses the operational problem that moving to a new embedding model can require re-encoding a corpus and rebuilding or adapting an approximate-nearest-neighbor index. That makes model-independent identity a meaningful architectural property, although it does not eliminate the need for embeddings.

The crucial limitation is that a Concept ID must never replace the original memory evidence. The agent should retain the sentence, document, observation, tool result, or event from which the semantic assertion was derived.

A durable memory entry should therefore distinguish:

Observed evidence
        ↓
Probabilistic interpretation
        ↓
Concept assertion
        ↓
Human/automated review status
        ↓
Stable concept reference

That prevents an early extraction mistake from becoming a permanent fabricated memory.

Conditional use cases

MEDIUM TERM — Analytics and metric identity. Organizations routinely disagree about what a metric such as “active customer,” “gross revenue,” or “churn” means. Stable IDs could persist across BI tools and warehouses. But enterprise semantic-layer products already target this problem, so ES must prove that portable, vendor-neutral identity provides additional value rather than merely reproducing another metrics catalog. Stardog, for example, explicitly markets a semantic layer for analytics, AI and applications.

MEDIUM TERM — Data lineage and provenance. Concept IDs could identify what a lineage edge, classification, or transformation means. The natural product opportunity is integration with catalogs rather than replacing them.

MEDIUM TERM — Industrial and IoT bridging. This is technically attractive because independently maintained equipment and domain models need interoperability. But W3C Web of Things already uses JSON-LD for semantic annotation, and OPC UA Companion Specifications provide domain information models; OPC UA can also reference external dictionaries.

The appropriate role is therefore:

bridge OPC/WoT/vendor/private semantics, not issue competing industrial meanings.

MEDIUM TERM — E-commerce mapping. Merchant catalogs contain huge attribute variation, but GS1 already publishes product vocabularies and is working toward semantic harmonization across standards.

A useful ES application would map merchant-local attributes into GS1 or other standard identities with explicit confidence/provenance.

Use cases that are mainly evidence for the idea, not attractive replacement markets

Healthcare provides perhaps the strongest proof that stable semantic identities are valuable. SNOMED CT deliberately gives clinical concepts unique machine-readable identifiers without human meaning encoded into the identifier; LOINC similarly provides standardized identifiers for observations and tests; FHIR terminology infrastructure includes CodeSystem, ValueSet and ConceptMap.

That simultaneously validates and weakens the Embedded Semantics thesis:

• validates: durable semantic identity is valuable;
• weakens: mature domains already know how to do this.

MEDIUM TERM — Healthcare should therefore be a local/private-overlay and mapping use case, not a new global clinical terminology.

The same conclusion applies to finance. ISO 20022 maintains an industry-agreed business model, dictionary and message concepts, while the Global LEI System already demonstrates globally governed unique entity identifiers and federated issuance.

Government has NIEM, whose architecture is particularly instructive: a common core coexists with domain models governed by domain stewards, extensions are expected, and the project explicitly avoids requiring an “uber-model.”

Legal systems present an even weaker replacement opportunity because context, jurisdiction, temporal validity, legal interpretation and exceptions are intrinsic. OASIS LegalRuleML models legal norms and Akoma Ntoso provides a common structured model for legal documents; European Legislation Identifier infrastructure already addresses persistent identification of legislation.

Observability, localization and robotics

Observability: OpenTelemetry already publishes Semantic Conventions defining common names, types, meanings and values, and it has explicit stability/migration mechanisms. That makes a new identity layer difficult to justify inside OpenTelemetry itself. A semantic bridge across observability standards might be useful, but this should not be an initial wedge.

Localization: Unicode CLDR/LDML already provides standardized locale data, canonical locale identifiers and an open process for reconciling locale information. Semantic IDs can usefully separate an application's conceptual identity from its translated labels, but localization by itself does not require a new semantic infrastructure layer.

Robotics: ROS 2 already defines typed topics, services and actions, with custom interfaces for exchanging structured data. Semantic capability IDs might become useful for heterogeneous robots selecting equivalent capabilities from different vendors, but this is closer to the agent-capability problem than a reason to redesign ROS interfaces.

Ideal early adopters

The best early adopter is not “healthcare” or “government.” It is a team with:

1. three or more independently designed interfaces;
2. repeated semantic mapping work;
3. enough autonomy to add metadata;
4. an AI or event-driven system that increases the cost of ambiguity;
5. no desire to deploy a full ontology platform.

The highest-probability cohorts are:

Developer adoption path

NEAR TERM — Make semantic identity optional metadata, not a framework.

The minimum viable developer journey should be:

Install SDK/CLI
   ↓
Annotate existing OpenAPI / AsyncAPI / JSON Schema / event / agent metadata
   ↓
Resolve IDs locally from a version-pinned bundle
   ↓
Validate semantic compatibility in CI
   ↓
Optionally use a hosted/private registry

A developer should not need RDF expertise, a graph database, a network dependency, or an account with a vendor.

NEAR TERM — Ship at least TypeScript, Python and .NET reference clients, followed by Java and Go. The exact language sequence matters less than demonstrating that Concept IDs are plain interoperability data, not tied to one ecosystem.

NEAR TERM — Ship a validator and linter before sophisticated AI resolution. Developers trust deterministic tooling more readily than another semantic-search demo.

NEAR TERM — Provide OpenAPI, AsyncAPI, CloudEvents, MCP and A2A examples. OpenAPI's extension mechanism, CloudEvents' extension attributes, and A2A's URI-based extensions all permit experimentation without asking those communities to change their base standards first.

Enterprise adoption path

NEAR TERM — Private registry first-class support is mandatory.

Enterprise semantics frequently contain:

• internal products;
• confidential business processes;
• unreleased capabilities;
• proprietary metrics;
• security classifications;
• legal interpretations;
• customer-specific vocabulary.

An enterprise must therefore be able to operate a registry offline or inside its trust boundary.

The enterprise path should be:

Private namespace
    +
Public-standard references
    +
Local terminology
    +
Reviewed mappings
    +
RBAC / audit / signing
    +
Pinned deployable bundles

MEDIUM TERM — Integrate with schema registries, catalogs, MDM, API gateways, event platforms and IAM rather than trying to replace them.

Apicurio's support for multiple schema/API artifact types and data-contract metadata illustrates how registries are already becoming broader governance surfaces.

Embedded Semantics technical architecture

Semantic identity as a type system

The best conceptual advance for “Embedded Semantics 2.0” is to treat Concept IDs as nominal semantic types.

A traditional structural validator can establish:

price: number
currency: string

A semantic contract could additionally establish:

price  → Concept: monetary-amount
currency → Concept: currency-code

This allows a static checker to distinguish:

distance: number
temperature: number
price: number

even though all three share the same structural representation.

NEAR TERM — Semantic IDs should annotate structural types rather than replace them.

MEDIUM TERM — Define explicit compatibility relations. A semantic validator might accept value concept A where concept B is required only if there is an authoritative relation explicitly suitable for type compatibility.

This requires caution. A generic taxonomy relation such as “broader” or “related” must not automatically become programming-language subtyping. SKOS is intentionally a lightweight concept-scheme model; OWL provides the stronger formal machinery when logical semantics are required.

Therefore a semantic type layer should distinguish:

human-taxonomy relation:
    broader / narrower / related

mapping relation:
    exact / close / source-specific mapping

formal contract relation:
    subtype-compatible / coercible / incompatible

Only the last category should drive static software decisions.

MEDIUM TERM — Semantic contract validation can become a compiler problem.

For example:

Producer
  structural type: decimal
  semantic type: net-monetary-amount
  unit constraint: ISO currency
        ↓
Consumer requires
  structural type: number
  semantic type: monetary-amount
        ↓
Validator
  structure compatible? yes
  semantic subtype assertion trusted? yes
  unit constraint compatible? yes
        ↓
Contract accepted

That is materially more useful than “embedding similarity = 0.91.”

Semantic identity as a protocol layer

NEAR TERM — Do not invent a new transport protocol.

Concept identifiers should travel as metadata inside existing protocols.

Potential integration points include:

• OpenAPI specification extensions;
• AsyncAPI message/channel metadata;
• CloudEvents extension attributes;
• JSON Schema annotations;
• Protobuf custom options where appropriate;
• A2A extensions;
• MCP metadata;
• ordinary HTTP/JSON fields.

OpenAPI explicitly permits custom x- extensions, CloudEvents permits extension attributes, and A2A defines extension URIs for protocol features.

MEDIUM TERM — Semantic capability negotiation.

A consumer could declare:

requires semantic capability: X
accepts:
  exact X
  or formally compatible subtype of X
revision policy: pinned/current-compatible
authority policy: trusted namespaces only

An agent or API endpoint advertises its own semantic contract, and a deterministic negotiator checks compatibility before execution.

The important point is that this happens after discovery but before probabilistic invocation.

LONG TERM — Semantic version negotiation should use explicit compatibility assertions, not ordinary semantic version numbers.

Meaning evolution does not map cleanly onto major.minor.patch. An editorial definition correction might preserve identity, while a subtle scope change might require a completely new Concept ID.

Recommended model:

Concept Identity
    ├── immutable revision A
    ├── immutable revision B
    └── immutable revision C

semantic change?
    no  → same identity, new record revision
    yes → new Concept Identity + explicit successor/mapping relation

Semantic identity as an agent layer

Agent systems are one of the most promising new markets precisely because current agent protocols intentionally leave considerable semantic detail in text.

A2A Agent Cards expose agent skills and capabilities, while MCP defines discoverable tools, resources and prompts.

NEAR TERM — Attach Concept IDs to agent skills and tool effects.

Example:

Tool name:
    terminate_subscription

Description:
    "Cancels a customer's current paid service..."

Semantic capability:
    subscription-cancellation

Input semantic types:
    customer-identifier
    subscription-identifier

Effect:
    subscription-status-transition → cancelled

A different agent might expose close_plan. Text matching may suggest equivalence; an authority-approved semantic mapping can establish it.

MEDIUM TERM — Capability negotiation should remain multi-dimensional.

Concept identity alone is insufficient. An agent must also negotiate:

• structural input/output schemas;
• authentication;
• permissions;
• side effects;
• latency/cost;
• jurisdiction;
• data handling;
• model/tool version;
• transactional properties.

A semantic capability ID is one axis of compatibility.

LONG TERM — Semantic contracts between agents. This becomes interesting when agents can statically verify expected semantic inputs, outputs, effects and constraints before delegating a task.

SPECULATIVE — Machine-native ConceptCode conversations. Compressing whole agent conversations into concept tokens is unlikely to be desirable for general reasoning. Natural language contains modality, uncertainty, pragmatics, presupposition and context that an atomic code stream would discard. Compact semantic tokens could work for negotiated, repetitive protocol operations, but not as a universal replacement for language.

Semantic identity as durable memory

The most useful memory architecture is hybrid:

Memory object
  ├── original evidence
  ├── extracted entities
  ├── temporal context
  ├── Concept ID assertions
  ├── assertion provenance
  ├── embedding model/version
  ├── embedding vector
  └── review/confidence state

NEAR TERM — Concept IDs should be anchors, not memories.

A vector helps retrieve a memory.

A Concept ID says what some aspect of that memory has been classified as.

The evidence explains why.

These should never be collapsed into a single representation.

MEDIUM TERM — Model migration becomes cleaner. A new embedding model can recompute vector representations while Concept IDs and provenance remain unchanged. Research on embedding drift/model upgrade already motivates special techniques to avoid full index rebuilds, underscoring the operational value of separating durable identifiers from representations.

MEDIUM TERM — Memory corrections should create new assertions, not rewrite history. If an agent initially maps text to concept A and review later establishes B, both assertions should remain auditable with different statuses.

LONG TERM — Trust-weighted memory retrieval could prefer facts whose semantic assertions were approved by trusted authorities rather than treating all embedding-nearest memories equally.

Semantic identity as a distributed registry

The core data model should be deliberately boring.

NEAR TERM — Stable identity plus immutable revisions.

A record should approximately contain:

{
  "concept_id": "urn:example:concept:opaque-id",
  "authority": "example-authority",
  "status": "active",
  "definition": {
    "en": "..."
  },
  "labels": {
    "en": ["..."],
    "fr": ["..."]
  },
  "revision": "immutable-revision-id",
  "content_hash": "digest",
  "provenance": [],
  "relations": [],
  "mappings": []
}

The exact syntax is less important than the invariants.

NEAR TERM — Canonical IDs should be opaque. Do not encode human semantics into the identifier. SNOMED's choice to make the identifier itself non-human-interpretable is a useful precedent: names can change while identity remains stable.

NEAR TERM — Prefer authority-controlled URI/IRI identifiers and treat short ConceptCodes as compact aliases. This permits compatibility with RDF/JSON-LD without forcing RDF on application developers.

NEAR TERM — The registry must support downloadable signed bundles and offline resolution. A production API or robot should not fail because a global semantics service is unavailable.

MEDIUM TERM — Introduce namespace federation.

RFC 8126's guidance for protocol parameter registries is useful here: it emphasizes clearly defined namespaces, assignment policies and change control, and specifically notes that hierarchical allocation can coordinate a top level while delegating lower levels to domain experts.

That is a much better architecture than one universal concept authority.

Conceptually:

Global discovery layer, if needed
        |
        +-- healthcare authority
        |
        +-- finance authority
        |
        +-- vendor A
        |
        +-- vendor B
        |
        +-- enterprise X (private)
        |
        +-- research community Y

The federation layer answers:

“Who controls this namespace, where can I resolve it, and what keys/policies identify the authority?”

It does not answer:

“Whose definition of this concept is metaphysically correct?”

Public and private registries

NEAR TERM — Yes, there should be a public registry, but not a compulsory global oracle.

Its initial purposes should be:

• demonstration;
• reference implementation;
• openly licensed example concepts;
• namespace discovery;
• test vectors;
• shared mappings;
• developer onboarding.

Its current zero-concept state means this is the most basic missing public proof point.

NEAR TERM — Enterprises must be able to run private registries.

Private concepts can map to public concepts without surrendering ownership.

An overlay should be able to say:

our internal concept A
    exact/close/narrow mapping
public concept B

but it should not silently redefine public concept B.

MEDIUM TERM — Private overlay resolution should be local-first and policy-driven.

Recommended order:

Pinned application bundle
        ↓
Authorized private registry
        ↓
Authoritative public namespace
        ↓
Trusted cross-registry mappings
        ↓
Probabilistic candidate resolver
        ↓
abstain

That ordering preserves enterprise control and deterministic behavior.

Content-addressed semantic identity

NEAR TERM — Do not make the Concept ID itself content-addressed.

IPFS Content Identifiers are derived from content, so changed content implies a different content identity. That is excellent for immutable snapshots but conflicts with a concept identifier whose labels or non-semantic metadata can evolve while the underlying concept remains the same.

Use:

persistent Concept ID
        ↓
revision 1 → content hash A
revision 2 → content hash B
revision 3 → content hash C

This combines durable identity with tamper-evident versions.

Signed semantic assertions

MEDIUM TERM — Sign authority assertions and registry releases.

A signed mapping record should include at minimum:

issuer
subject Concept ID
relation
object Concept ID
scope/context
evidence
validity period
revision
signature

The signature proves which authority issued the statement. It does not prove that the semantic claim is correct.

This distinction is fundamental.

Semantic transparency logs

MEDIUM TERM — Add transparency only when multiple authorities and meaningful trust exist.

Sigstore's Rekor demonstrates the useful pattern: an append-only transparency log can make signed artifacts and their inclusion auditable.

A semantic transparency log could establish:

• when an authority published a revision;
• whether history was rewritten;
• whether a mapping existed at a particular time;
• which signing key was used.

It cannot establish whether “concept A really means concept B.”

LONG TERM — Multiple independent monitors could detect equivocation by an authority.

SPECULATIVE — Blockchain consensus is unnecessary unless a concrete threat model eventually requires it. Nothing in the present problem requires global proof-of-work/stake consensus about meaning.

Semantic CRDT-like replication

MEDIUM TERM — Use CRDT-like ideas only for replication of immutable assertions, not semantic reconciliation.

Two registries may legitimately publish:

Authority A: X exactMatch Y
Authority B: X notEquivalent Y

A distributed data structure can merge both assertions without data loss.

It cannot algorithmically determine which authority is correct.

Therefore the convergent state should be:

{ assertion A, assertion B }

plus a local trust policy—not a fabricated semantic consensus.

Concept composition

SNOMED CT's compositional grammar demonstrates that concept composition can work in a constrained domain; OWL demonstrates much richer formal composition in a logic-based ontology environment.

The lesson is not “composition is easy.” The lesson is that composition requires explicitly defined semantics.

NEAR TERM — Keep Concept IDs atomic.

MEDIUM TERM — Introduce anonymous semantic expressions above them.

Conceptually:

AND(
    concept:temperature,
    qualifier:ambient,
    relation:measured-at,
    concept:warehouse
)

or a typed expression tree.

A composed expression should normally not receive a new governed Concept ID. Instead it can have a deterministic canonical encoding and content hash.

MEDIUM TERM — Frequently reused compositions may later be promoted to governed concepts.

This prevents registry explosion.

Semantic algebra

A general algebra is attractive but dangerous.

MEDIUM TERM — Investigate small, domain-specific algebras.

Potential operators include:

• conjunction;
• disjunction;
• negation;
• role/value restriction;
• quantity/unit;
• temporal qualifier;
• jurisdiction;
• provenance qualifier.

But each operator must have defined type rules.

For example:

monetary-amount + monetary-amount

may be meaningful with currency compatibility.

customer + invoice

has no natural algebraic interpretation merely because both are Concepts.

LONG TERM — A semantic compatibility calculus might be valuable. Its purpose would be static interoperability checking, not universal reasoning.

SPECULATIVE — A universal semantic algebra should be presumed unnecessary until demonstrated otherwise. OWL, description logics, rule languages and domain-specific formalisms already occupy the territory where expressive logical composition is required. Reinventing that territory would be a major strategic mistake.

Formal verification opportunities

NEAR TERM — Formally validate syntax and invariants.

Candidates include:

• registry record schemas;
• canonical serialization;
• hash generation;
• identifier uniqueness;
• immutable revision rules;
• signature verification;
• lifecycle transitions.

SHACL illustrates an established model for validating constraints over semantic graphs; JSON Schema can handle simpler JSON-level structure.

MEDIUM TERM — Formally validate semantic-contract compatibility.

A checker could prove:

• structural compatibility;
• accepted semantic type relationship;
• unit compatibility;
• required provenance;
• allowed authority;
• revision constraints.

LONG TERM — Verify composition rules.

A restricted semantic expression language could potentially receive a formal semantics and proof obligations.

What formal methods cannot prove: that a human-authored definition correctly captures a real-world concept. They can verify consistency with declared rules, not truth itself.

What should remain probabilistic

The following should explicitly remain probabilistic:

• unseen natural-language resolution;
• paraphrase matching;
• cross-lingual candidate generation;
• ontology/mapping suggestions;
• similarity search;
• entity extraction;
• ambiguous intent interpretation;
• ranking candidate Concepts.

Embedded Semantics' current methodology already recognizes this by separating exact reviewed resolution from future/experimental semantic retrieval.

The safest pipeline is:

LLM / embedding:
    "I think this may be Concept X."

Registry:
    "Concept X is defined as ... by Authority Y at Revision Z."

Policy:
    "Authority Y is trusted for this operation."

Application:
    "Proceed / reject / request review."

Knowledge-graph implications

NEAR TERM — Treat knowledge graphs as a natural downstream representation.

Concept IDs become graph-node identifiers.

Mappings and provenance become edges.

Do not build a proprietary graph abstraction simply because the registry eventually contains relationships.

NEAR TERM — Support SKOS/RDF/JSON-LD export and import. JSON-LD is specifically intended to bring linked-data semantics to JSON-based systems.

A critical design test is:

If the core Concept, label, mapping and provenance model cannot round-trip reasonably into established semantic-web representations, what capability justifies the incompatibility?

That question should be answered before inventing new vocabulary.

Database implications

NEAR TERM — Concept IDs should work as ordinary values.

In relational databases:

semantic_concept_id VARCHAR / URI-valued column

In document databases:

"semanticId": "..."

In graph databases:

Concept ID → node IRI

In vector databases:

embedding + semantic-id metadata

The registry should therefore not require a special database.

MEDIUM TERM — Semantic indexes can accelerate reverse lookup. Applications may need to ask, “Which fields/events/memories in this estate claim to use Concept X?”

That is more likely to create enterprise product value than the raw concept resolver.

API implications

NEAR TERM — Use extensions first.

A semantic annotation can attach to:

• operations;
• parameters;
• request/response fields;
• errors;
• effects;
• resources.

OpenAPI's extensibility means this can be proven without changing the standard.

MEDIUM TERM — Generate mapping diagnostics.

Given two API descriptions, tooling could emit:

Structural compatibility: yes
Semantic identity: exact
Conversion: unnecessary

or:

Structural compatibility: yes
Semantic identity: incompatible
Risk: same primitive type, different meaning

That second case is precisely where semantic identity would justify itself.

Security implications

The security model is substantially harder than a demo resolver suggests.

Major threats include:

NEAR TERM — Treat semantic resolution used in security decisions as a supply-chain problem. Pin authorities, revisions and signed bundles.

MEDIUM TERM — Mapping trust must not automatically transit.

If:

trusted A says X = Y
untrusted B says Y = Z

an authorization engine must not infer trusted X = Z.

LONG TERM — Semantic provenance can become an authorization input, not authorization itself.

A policy might say:

allow operation only if:
    requested capability is Concept X
    AND mapping path was issued by authority A
    AND registry revision >= R
    AND principal has permission P

The concept is only one component. Identity, principal, resource, context and policy still matter.

SPECULATIVE — A Concept-based policy engine may be useful, but only after semantic typing and trust propagation are independently proven.

Three candidate architectures for Embedded Semantics 2.0

Recommended architecture

The recommended architecture is not one giant 2.0 rewrite.

It is a staged stack:

Application layer
APIs | Events | Agents | Memory | Analytics
                 │
                 ▼
Semantic annotation profile
Concept IDs | Semantic contracts
                 │
                 ▼
Authority layer
Concept records | mappings | provenance
                 │
                 ▼
Federation layer
Namespaces | trust | signing | discovery
                 │
                 ▼
Distribution layer
Bundles | caches | mirrors | transparency
                 │
                 ▼
Probabilistic layer
Embeddings | LLMs | multilingual retrieval

The probabilistic layer is deliberately below the authority boundary, not the source of it.

NEAR TERM: implement the Thin Semantic Identity Profile.

MEDIUM TERM: selectively add federation, signing and private overlays.

LONG TERM: add formally constrained semantic contracts where pilots prove value.

SPECULATIVE: pursue general semantic algebra, executable Concepts or decentralized semantic consensus only if compelling failures cannot be solved by existing ontology/type systems.

Open ecosystem, governance, standards, federation, and economics

What should be open

The ecosystem can survive only if the interoperability layer is credibly non-capturable.

NEAR TERM — Open specification. The identifier semantics, record model, mapping types, resolution behavior, versioning rules and federation protocol must be public.

NEAR TERM — Open reference implementation. At least one registry, resolver, CLI and validator should be freely usable.

NEAR TERM — Open conformance suite and test vectors. These are arguably more important than the implementation.

NEAR TERM — Open export/import and offline format. A customer must be able to leave a hosted provider.

NEAR TERM — Open namespace rules.

NEAR TERM — Open cryptographic formats.

NEAR TERM — Open SDK protocol.

NEAR TERM — Public registry data should be mirrorable where licensing permits.

A sensible licensing pattern would be a permissive software license for reference code plus an openly implementable specification with an explicit patent/IP policy.

What can be commercial

Commercial value should sit around governance and operations:

There is probably not yet evidence for a standalone “ConceptCode market.” The likely initial budget comes from integration, data governance, agent infrastructure, API management or AI-platform spending.

What should never be monetized

The following should be constitutionally protected if ecosystem trust is a goal:

Never charge a mandatory fee for organizations to mint identities under their own namespaces.

Never require a proprietary hosted resolver for correctness.

Never make the canonical protocol dependent on a vendor API key.

Never prohibit export or independent mirroring.

Never put the conformance test suite behind a commercial license.

Never make a proprietary signing root mandatory.

Never make public identifier lookup a tollbooth.

Never let a company trademark become the only way to describe conforming implementations.

A paid certification program could eventually exist, but conformance must remain independently testable.

Public registry versus private registries

The answer to both registry questions is yes, but their roles differ.

Public registry: open namespaces, common concepts, discovery, test data, mappings, ecosystem distribution.

Private registry: proprietary business concepts, internal aliases, governance workflows, confidential mappings, policy classifications.

The federation principle should be:

public concepts may be referenced privately; private concepts may map publicly; neither side must surrender control.

NIEM's model of a common core plus semi-independent domain stewardship offers a useful institutional precedent for scaling vocabulary without demanding one centralized ontology.

Federation strategy

NEAR TERM — Avoid a central root entirely if DNS/URI ownership is sufficient.

An organization can publish globally unique Concept URIs under a domain it controls.

MEDIUM TERM — Add a registry-discovery convention only if real interoperability requires it.

MEDIUM TERM — If a directory/root emerges, make it a directory of authorities rather than the owner of every Concept.

RFC 8126's hierarchical registry guidance strongly supports delegation rather than central allocation of every value.

The global LEI ecosystem is another useful analogy: the global system establishes rules and a common index while accredited issuing organizations operate as local issuers.

The federation architecture should separate:

Protocol governance
    "How does a registry behave?"

Authority governance
    "Who controls namespace X?"

Concept governance
    "What does X:123 mean?"

Mapping governance
    "Who says X:123 maps to Y:456?"

Trust policy
    "Whose assertions does my application accept?"

Conflating these is a recipe for capture.

Governance credibility

External developers will trust the system only after governance ceases to look inseparable from one inventor or company.

NEAR TERM — Publish a governance charter before calling the work a standard.

It should specify:

• contribution process;
• decision-making;
• release policy;
• identifier permanence;
• definition-change rules;
• security disclosure;
• conflict-of-interest policy;
• IP/patent policy;
• appeals;
• namespace disputes;
• trademark rules;
• deprecation;
• archival/mirroring.

NEAR TERM — Semantic change policy is the most important governance document.

There must be an objective decision tree for:

label correction → same ID
translation addition → same ID
definition clarification → usually same ID
scope narrowed materially → new ID
scope broadened materially → new ID
concept merged → old IDs retained + replacement mapping
concept split → old ID retained/deprecated + new IDs

An immutable historical audit trail is mandatory.

MEDIUM TERM — Separate the technical steering body from domain semantic authorities. Protocol developers should not determine medical, legal or financial meaning.

MEDIUM TERM — Move ecosystem assets to neutral governance if multiple vendors adopt. Linux Foundation-style open governance is one possible institutional destination; its public governance model emphasizes open technical governance and steering structures for multi-party infrastructure.

Network effects

There are five plausible positive network effects.

Mapping network effect. Each new authoritative mapping can reduce the integration cost between previously disconnected vocabularies.

Tooling network effect. As more API/event/agent tooling understands semantic annotations, the cost of adding them declines.

Authority network effect. More credible domain authorities make more identifiers useful.

Multilingual evidence network effect. More reviewed expressions improve candidate resolution across languages without changing Concept identity.

Trust network effect. More independently signed and mirrored authorities make federation useful.

But a crucial distinction is:

More Concepts alone are not a network effect.

A million unused IDs create no ecosystem.

The relevant metric is the number of reused identities, maintained mappings, conforming tools and independent authorities.

Negative network effects

Growth also makes several problems worse:

• namespace squatting;
• duplicate concepts;
• contradictory mappings;
• mapping cycles;
• stale definitions;
• governance disputes;
• malicious authorities;
• high curation burden;
• licensing conflicts;
• semantic fragmentation.

This is why a flat universal namespace is undesirable.

Avoiding ecosystem capture

NEAR TERM — Make namespace operation permissionless at the protocol level.

NEAR TERM — Use open identifiers that survive provider migration.

NEAR TERM — Allow independent resolvers and mirrors.

NEAR TERM — Define a portable signed bundle format.

MEDIUM TERM — Multi-vendor governance.

MEDIUM TERM — Multiple independent registry implementations.

MEDIUM TERM — Domain authorities remain sovereign.

LONG TERM — A neutral foundation may coordinate the interoperability profile but should own as little semantic content as possible.

The model should be closer to Internet protocol infrastructure than an app store.

Standards strategy

The current public status makes formal standardization premature. The registry does not yet expose a published concept corpus, much less independent implementations.

That matters because serious standards processes value implementation evidence. W3C's Recommendation Track explicitly requires wide review, consensus-building and adequate implementation experience, while IETF culture strongly emphasizes rough consensus and running code.

NEAR TERM — Publish an open implementation profile, not a “standard.”

Call it:

Semantic Identity Interoperability Profile, experimental version.

NEAR TERM — Standardize extensions inside ecosystems before standardizing the universal layer.

Likely first venues:

• OpenAPI Initiative for an annotation convention;
• AsyncAPI for message metadata;
• CloudEvents/CNCF for an event extension;
• A2A/Linux Foundation ecosystem for semantic skill/capability metadata;
• MCP/Agentic AI Foundation ecosystem for semantic tool metadata;
• potentially a W3C Community Group for URI/JSON-LD alignment.

The Linux Foundation's Agentic AI Foundation already provides a neutral umbrella around agent-oriented open projects including MCP, making the broader LF ecosystem particularly relevant if semantic agent interoperability gains traction.

MEDIUM TERM — W3C becomes relevant if the core is explicitly aligned with Web identifiers, JSON-LD, SKOS or profile negotiation. W3C already standardizes RDF, SKOS, OWL, JSON-LD and data catalog/federation vocabularies.

MEDIUM TERM — IETF becomes relevant only for Internet-protocol-level pieces. Examples might include a registry discovery convention, HTTP semantics, a well-known location, or an identifier/negotiation protocol. It should not become the arbiter of business concepts.

MEDIUM/LONG TERM — OASIS and domain standards organizations matter where domain-specific contracts emerge. OASIS is especially plausible for legal/rule-oriented profiles.

LONG TERM — ISO/IEC JTC 1/SC 42 may matter if a broad AI semantic-interoperability practice is demonstrated. SC 42 is ISO/IEC's AI committee.

LONG TERM — HL7/SNOMED, GS1, OPC Foundation, NIEM and similar organizations should be partners/authorities, not targets for semantic replacement.

Proof required before standardization

A serious standardization attempt should wait until at least the following recommended gates are met:

These are proposed research gates, not claims about present adoption.

Risks of premature standardization

Premature standardization would create several pathologies.

First, it could freeze the wrong abstraction—perhaps Concept identity turns out to be useful only as JSON-LD/SKOS metadata.

Second, it could create several years of committee work around a problem developers do not actually pay to solve.

Third, it could encode current implementation details before public experiments reveal the right distinction between Concept, revision, mapping, assertion and authority.

Fourth, standardization itself can create false credibility: users may infer that “standardized semantic ID” means “correct semantic interpretation.”

Fifth, it can produce a namespace before there is an ecosystem, making governance disputes the project's primary activity.

Recommendation: NEAR TERM — deliberately resist formal-standard language.

Risks of vendor lock-in

Vendor lock-in could arise through:

• proprietary Concept IDs;
• required central resolution;
• proprietary mappings;
• non-exportable private registries;
• private signing roots;
• proprietary compatibility algorithms;
• model-specific semantic vectors;
• closed certification;
• restricted public registry access.

The best prevention mechanism is architectural, not contractual:

Any conforming implementation should be able to resolve a pinned semantic bundle with the vendor's servers turned off.

That should be an explicit conformance test.

Economics and monetization

The most important economic fact is that semantic curation is labor.

The ecosystem will not scale by assuming that everyone will altruistically curate universal concepts.

Authorities participate when publishing semantics reduces some other cost:

• standards bodies reduce interpretation disputes;
• SaaS vendors reduce integration support;
• enterprises reduce mapping duplication;
• agent vendors improve discoverability;
• data teams improve governance;
• platform vendors sell operational tooling.

This means the sustainable economic model is shared open semantic infrastructure plus paid operational/governance services, not rent collection on identifier issuance.

Messaging recommendations

Recommended message:

“Stable governed semantic IDs let independently developed systems refer to the same intended meaning while keeping fuzzy language matching separate from authoritative identity.”

Another good developer-oriented framing:

“Schemas tell you the shape. Semantic IDs tell you what the field is supposed to mean.”

For AI:

“Use models to find meaning; use governed IDs to remember which meaning you selected.”

Avoid:

• “universal language for AI”;
• “semantic internet”;
• “replacement for ontologies”;
• “meaning encoded in Unicode”;
• “deterministic meaning from embeddings”;
• “global source of semantic truth”;
• “DNS for meaning” as anything more than a loose federation analogy;
• “new standard” before independent implementations exist.

Terminology recommendations

NEAR TERM — Prefer “Concept ID” or “Semantic ID” over “ConceptCode” in ecosystem-facing material.

“Code” suggests either a code list, numeric enum or proprietary encoding. “Identifier” accurately describes the invariant.

Recommended vocabulary:

Reserve ConceptCode for an optional compact wire/display alias if existing terminology has value.

Prototypes, experiments, roadmaps, and failure criteria

Ten ambitious prototypes ranked by information gain

The ranking asks a specific question: Which experiment most quickly tells us whether stable semantic identities are actually necessary, rather than merely elegant?

Prototype details

NEAR TERM — Cross-API semantic type checker.

Take two real, independently developed APIs with overlapping concepts.

Baseline:

• OpenAPI only;
• names/descriptions;
• normal schema matching;
• optional LLM mapping.

Treatment:

• same APIs plus Concept IDs and approved mappings.

Measure:

• false matches;
• missed matches;
• human review time;
• number of hand-maintained adapter rules;
• change effort after version evolution;
• ability to explain each mapping.

This experiment directly tests the core thesis.

NEAR TERM — Semantic event router.

Use at least three producers with differently named event schemas.

A router should subscribe based on a Concept ID rather than producer-specific event-type strings, while still enforcing native schema compatibility.

CloudEvents' stated purpose is interoperability of event metadata; a semantic extension would test whether a second layer genuinely adds value rather than duplicating that work.

NEAR TERM — Agent capability negotiation.

Create three independently implemented agents exposing equivalent and near-equivalent capabilities using A2A/MCP-compatible descriptions.

Compare:

• text/LLM selection;
• exact Concept-ID selection;
• Concept-ID plus mapping;
• hybrid selection.

Include hard negatives where names sound similar but side effects differ.

NEAR TERM — Durable memory migration.

Build an agent memory corpus using model A.

Store:

• raw evidence;
• vector A;
• Concept assertions.

Upgrade to embedding model B.

Re-embed corpus and measure whether:

• retrieval neighborhoods change;
• Concept-based filters remain stable;
• previously approved semantic associations survive;
• curation savings justify the additional layer.

This complements the current Embedded Semantics evaluation methodology, which already emphasizes hard negatives, cross-language agreement and abstention.

NEAR TERM/MEDIUM TERM — Federation prototype.

Run:

Public registry
Enterprise private registry A
Enterprise private registry B
Offline client

Demonstrate:

• namespace uniqueness;
• private mappings;
• no central runtime requirement;
• export;
• cache;
• authority key rotation;
• conflicting mappings;
• deterministic trust policy.

NEAR TERM — SKOS/JSON-LD interoperability prototype.

Import a small SKOS concept scheme, expose it through the ES developer API, export it again, and quantify semantic loss.

A failure here would be highly informative: if ES requires a proprietary model merely to reproduce SKOS's basic identity/label/mapping features, its ecosystem rationale weakens substantially.

Demonstrations that would actually prove the idea

The current public site needs demonstrations that answer “why not X?” rather than demonstrations that merely show the resolver can return a ConceptCode.

The strongest public demo would show:

Two unrelated APIs
    ↓
different names
different schemas
different languages
    ↓
same governed semantic identities
    ↓
automatic compatibility diagnostics
    ↓
schema changes
model upgrade
    ↓
identities remain stable

A second demo should show a hard negative:

"cancel order"
vs
"cancel payment"

An embedding may consider these close.

The semantic layer must preserve their distinction.

A third demo should show an unknown expression and abstain rather than forcing a mapping.

A fourth should run entirely offline from a pinned bundle.

A fifth should use a registry implementation built by someone other than Embedded Semantics' creator.

That last one is far more persuasive than adding another feature to the reference implementation.

Critical experiments before committing to architecture

NEAR TERM — Baseline against plain SKOS/JSON-LD. The key question is whether the proposed abstraction is materially easier, not whether it can reproduce semantic IDs.

NEAR TERM — Baseline against strings plus schema plus LLM mapping. If a well-prompted LLM plus schema descriptions handles the target use case cheaply and safely enough, the governed identity layer may not justify curation.

NEAR TERM — Measure semantic curation economics. Record reviewer minutes per new Concept, mapping and change. The cost model may kill the platform even if the technology works.

NEAR TERM — Test identity-preserving versus identity-breaking changes. Give multiple reviewers realistic change cases and measure agreement about whether a new Concept ID is required.

NEAR TERM — Independent implementation test. Give only the public specification to an outside team and see whether their resolver behaves identically.

MEDIUM TERM — Malicious federation test. Introduce contradictory authorities, expired keys, stale data and deceptive equivalent mappings.

MEDIUM TERM — Scale mapping conflicts, not merely concept count. Ten thousand concepts are trivial compared with thousands of disputed mappings.

MEDIUM TERM — Test disconnected/offline operation.

MEDIUM TERM — Measure semantic contract false positives/negatives.

Research questions requiring academic collaboration

MEDIUM TERM — Programming languages/formal methods: What is the correct formal model of semantic nominal typing across independently governed namespaces? Under what conditions is semantic subtyping decidable and useful?

MEDIUM TERM — Semantic Web: How much of the proposed registry can be cleanly expressed as SKOS/RDF/OWL/SHACL, and what minimal additional operational semantics are genuinely missing?

MEDIUM TERM — NLP: How should multilingual candidate resolution be calibrated so that abstention is meaningful and comparable across languages?

MEDIUM TERM — Distributed systems: What consistency model is appropriate for immutable semantic assertions, supersession and registry federation?

MEDIUM TERM — Security: How should trust in mapping assertions propagate, especially when semantic mappings influence authorization or tool execution?

LONG TERM — Cryptography: What transparency and signature mechanisms provide useful guarantees without introducing unnecessary ledger complexity?

LONG TERM — Knowledge representation: How can concept identity persist through legitimate definitional evolution without causing either identity fragmentation or semantic drift?

LONG TERM — Governance/economics: What incentive model produces high-quality mappings between independently governed vocabularies?

Potential paper topics

NEAR TERM: Governed Nominal Semantic Types for API Interoperability.

NEAR TERM: Abstention-Aware Multilingual Concept Resolution Under a Registry Authority Model.

NEAR TERM: Stable Semantic Anchors Across Embedding Model Upgrades in Agent Memory.

MEDIUM TERM: Federated Semantic Registries with Signed Cross-Namespace Mapping Assertions.

MEDIUM TERM: Semantic Identity Versus Structural Schema: Measuring Integration Maintenance Cost.

MEDIUM TERM: A Trust Model for Machine-Actionable Semantic Mappings.

MEDIUM TERM: Static Validation of Semantic Contracts Across Independently Authored APIs.

MEDIUM TERM: Immutable Assertion Replication Without Semantic Consensus.

LONG TERM: A Restricted Algebra for Composable Governed Semantic Types.

LONG TERM: Security Failure Modes in Semantic Capability Negotiation for AI Agents.

Potential standards proposals

NEAR TERM — Semantic annotation profile. A simple interoperable record for embedding Concept IDs in OpenAPI/AsyncAPI/JSON Schema/CloudEvents metadata.

NEAR TERM — Registry interchange format. Portable concept, mapping, provenance and authority records with deterministic serialization and test vectors.

MEDIUM TERM — Agent semantic-capability extension. An A2A/MCP-compatible extension rather than a new agent protocol.

MEDIUM TERM — Signed semantic assertion format. Prefer reuse of existing signature/data-integrity standards where practical instead of creating a custom cryptographic scheme.

MEDIUM TERM — Registry federation/discovery profile.

LONG TERM — Semantic contract profile. Only after multiple implementations prove a useful static compatibility model.

SPECULATIVE — General semantic-expression standard. Do not pursue unless domain-specific experiments demonstrate repeated interoperability that existing OWL/rule approaches do not serve.

Partnership categories

The highest-value partners are complementary infrastructure rather than organizations that would need to abandon their standards.

Twelve-month ecosystem roadmap

NEAR TERM — First quarter: reduce the idea to a falsifiable core.

Publish Semantic Identity Core 0.x containing only:

• Concept ID;
• authority;
• immutable revision;
• definition;
• multilingual labels;
• lifecycle;
• provenance;
• typed mapping;
• exact resolver behavior;
• candidate resolver behavior;
• abstention;
• portable bundle format.

Publish a non-empty reference registry. The current public state of zero deployed concepts should not persist once external evaluation begins.

Publish conformance tests before federation.

Demonstrate import/export with JSON-LD/SKOS.

NEAR TERM — Second quarter: attack the strongest alternatives.

Build:

• OpenAPI semantic annotations;
• AsyncAPI/CloudEvents demo;
• MCP/A2A capability demo;
• memory-model-upgrade demo.

Every demo must include a comparison against a simpler baseline.

Recruit at least two outside implementation teams.

NEAR TERM — Third quarter: prove enterprise viability.

Ship:

• private registry;
• namespace isolation;
• offline bundles;
• signing;
• RBAC hooks;
• audit history;
• schema-registry connector;
• data-catalog connector prototype.

Run at least three pilots where semantic mappings already exist as spreadsheets, code or integration rules.

Measure labor before and after.

NEAR TERM — Fourth quarter: prove ecosystem independence.

Require:

• an externally operated namespace;
• an independently implemented resolver;
• registry export/import interoperability;
• documented governance charter;
• semantic-change policy;
• security threat model.

Only then draft a federation proposal.

Do not seek ISO/W3C/IETF standard status during this first year.

Three-year ecosystem roadmap

MEDIUM TERM — First year: prove the thin layer.

Goal: determine whether a semantic ID profile has measurable developer and integration value.

The product is not “global semantics.” It is developer tooling around interoperable semantic identifiers.

MEDIUM TERM — Second year: federate and commercialize operations.

If year-one evidence is positive:

• support multiple authorities;
• launch managed private registries;
• ship mapping/governance workflows;
• build ecosystem adapters;
• add signed bundles;
• implement transparent publication history;
• establish neutral governance;
• move key protocol assets away from unilateral corporate control;
• create concept-package distribution and lockfiles.

The “semantic package manager” should resemble dependency management:

semantic-package manifest
    namespace dependencies
    accepted revisions
    content hashes
    signatures
    mapping profiles

Applications then build against a deterministic semantic environment rather than live-changing global state.

MEDIUM TERM — Third year: standardize proven extension points.

Only if independent adoption exists:

• submit agent capability extension to appropriate agent community;
• submit API/event annotation conventions upstream;
• establish neutral registry interchange specification;
• begin W3C/IETF work only for portions that clearly fall under their architectural remit;
• form domain working groups led by actual domain authorities.

Do not standardize a universal semantic algebra at this point.

Five-year technical roadmap

NEAR TERM / Year one — Identity.

Prove:

stable ID
versioning
authority
mappings
abstention
SDKs
offline resolution

MEDIUM TERM / Year two — Federation and trust.

Add:

private/public overlays
signed assertions
portable bundles
authority discovery
mapping provenance
trust policies

MEDIUM TERM / Year three — Semantic contracts.

Add where proven:

API semantic typing
agent capability negotiation
event semantic compatibility
static validator
revision negotiation

LONG TERM / Year four — Restricted composition.

Research and deploy domain-specific expression languages only where multiple implementations demand them.

Add formal verification for selected compatibility operations.

LONG TERM / Year five — Multi-vendor infrastructure.

A successful outcome would look like:

• independent registries;
• independent resolvers;
• multiple credible authorities;
• vendor-neutral governance;
• API/event/agent tooling support;
• stable mapping interchange;
• externally maintained namespaces;
• optional standardized federation.

SPECULATIVE / beyond year five — Semantic runtime.

Only then reconsider:

• broader semantic algebra;
• provenance-based authorization;
• machine-native semantic negotiation;
• sophisticated trust graphs;
• highly distributed semantic caches;
• semantic policy engines.

What not to build prematurely

Several attractive ideas should explicitly be deferred or rejected.

SPECULATIVE — Global semantic consensus mechanism: reject for now. Governance disagreement is not a Byzantine-consensus problem.

SPECULATIVE — Blockchain registry: reject absent a concrete requirement.

SPECULATIVE — Purely content-addressed Concept IDs: reject as canonical identity. Use hashes for revisions instead.

SPECULATIVE — Universal semantic algebra: reject unless restricted experiments succeed.

SPECULATIVE — Executable Concepts: keep code and meaning separate.

SPECULATIVE — Replace natural-language agent communication with ConceptCodes: likely harmful.

MEDIUM TERM — Transparency log: useful eventually, unnecessary before signed multi-authority publishing exists.

MEDIUM TERM — CRDT semantics: replicate assertions, never pretend to merge disagreements into truth.

Kill criteria

The project needs explicit falsification conditions because the easiest failure mode is to spend years building increasingly sophisticated infrastructure around an idea that developers admire but do not need.

Kill or radically narrow the platform thesis if, after approximately twelve months of serious pilots, fewer than three independent organizations continue using Concept IDs in production-oriented systems.

Kill the new-data-model thesis if straightforward SKOS/JSON-LD representation delivers essentially the same benefit and developer experience. In that case, Embedded Semantics should become a developer-friendly SKOS/semantic-web profile and tooling project rather than a new semantic substrate.

Kill the registry-network thesis if users want semantic IDs only inside individual applications. Local enums or ordinary stable keys are cheaper.

Kill the global-federation thesis if organizations will not publish or maintain cross-namespace mappings.

Kill the commercial-platform thesis if customers value the capability only as a minor feature of existing schema/catalog tools and show no willingness to pay for governance operations.

Kill or redesign the curation model if maintaining Concept mappings costs as much as maintaining today's integration mappings. This is perhaps the most important economic test.

A practical target would be to demonstrate at least a material double-digit reduction in recurring mapping/change effort in multiple pilots; otherwise, adding another registry is difficult to justify. This is a recommended falsification threshold, not a claim about current performance.

Kill the semantic-type thesis if static compatibility decisions still require arbitrary human interpretation in most cases.

Kill the agent-capability thesis if text descriptions plus existing A2A/MCP metadata and an LLM consistently produce equivalent reliability at lower operational cost.

**Kill the durable-memory thesis if Concept IDs are rarely reused in retrieval, policy, evaluation or migration and merely become extra metadata.

Kill the “stable identity” claim immediately if materially changed meanings are routinely kept under the same identifier.** That would destroy the central guarantee.

Do not standardize if no independent implementation exists.

Do not standardize if the only meaningful namespace is operated by the original project.

Do not standardize if interoperability demos require access to a proprietary hosted service.

Bottom-line strategic recommendation

The project should not attempt to become “the world's semantic registry.”

Its highest-probability path is:

NEAR TERM — become the thinnest credible governed-semantic-ID layer that application developers can add to existing APIs, events and agent interfaces.

Its most defensible intellectual position is:

Schemas provide structural types. Concept IDs provide nominal semantic types. Models provide probabilistic interpretation. Authorities provide governance.

Its best AI-specific opportunity is:

stable semantic anchors across agent capability descriptions, memory, schemas and model upgrades.

Its best enterprise opportunity is:

turning manually maintained semantic mappings into portable, versioned, governed runtime metadata.

Its most important design constraint is:

never make probability look like authority.

Its most important ecosystem constraint is:

never make one registry operator the owner of meaning.

And its most important skeptical test is:

Does carrying a stable Concept ID through real systems remove enough recurring integration work that developers voluntarily keep it after the experiment ends?

Until that question has a strong empirical answer, semantic algebra, consensus mechanisms, executable Concepts, universal registries and formal standardization are distractions.

Bibliography

Embedded Semantics and related public material

Embedded Semantics, public homepage and architectural description: registry-backed multilingual identity, stable ConceptCodes, provenance, exact reviewed resolution, experimental semantic retrieval, and separation of vectors from semantic authority.

Embedded Semantics, Concept Registry: public registry and concept-publication surface.

Embedded Semantics, public status page: deployment status, concept/expression counts and semantic-runtime status as observed August 23, 2026.

Embedded Semantics, research methodology: evaluation of concept resolution, hard negatives, multilingual behavior, retrieval and abstention.

Embedded Semantics, FAQ: exact reviewed expressions, vectors as evidence, unknown/ambiguous resolution behavior.

Embedded Semantics, public API registry response.

JustAnIota, IOTA-1 public authority description: registry, canonicalization, validation, Unicode substrate and AI handoff framing.

JustAnIota implementation material: validator/evidence-pack and implementation-track positioning.

Protocol5 public rules/evidence material: semantic cues, registries, candidate ranking and evidence workbench.

Mike Kappel public site: agent identity, persistent memory, governance and multi-agent coordination material.

Semantic-web and data-model standards

W3C, RDF 1.2 Concepts and Primer: IRIs and RDF identity model.

W3C, SKOS Reference: URI-identified concepts, schemes and mappings.

W3C, OWL 2: formally defined vocabularies and semantic relationships.

W3C, SHACL Core: graph constraints and validation.

W3C, JSON-LD 1.1: Linked Data semantics in JSON.

W3C, DCAT 3: decentralized data catalogs and interoperability.

W3C, Content Negotiation by Profile: profile-oriented representation negotiation.

W3C Web of Things Thing Description: JSON-LD-based semantics for IoT descriptions.

Registry, trust and distributed-identity precedents

IETF RFC 8126, Guidelines for Writing an IANA Considerations Section: namespace design, registration policies and hierarchical delegation.

Sigstore Rekor documentation: append-only transparency-log model and auditable signing records.

IPFS CID documentation: content-addressed identifiers.

W3C Decentralized Identifiers and DID Resolution: decentralized identifier/resolution architecture and method ecosystem.

API, event and schema infrastructure

OpenAPI Specification: language-agnostic API descriptions, schemas and extension mechanism.

OpenAPI Initiative Extensions Registry: JSON-LD/semantic extension precedents.

Protocol Buffers documentation: stable field numbers, wire compatibility and dangers of identifier reuse.

CloudEvents specification: common, vendor-neutral event metadata and extensibility.

AsyncAPI Specification and schema-registry guidance: machine-readable message-driven APIs and external schema management.

Apicurio Registry documentation: multi-format schema/API artifacts, lifecycle and data-contract metadata.

Confluent Schema Registry documentation: schema compatibility and evolution.

Agent infrastructure

Model Context Protocol specification: discoverable tools/resources and tool metadata/schema model.

Agent2Agent specification: Agent Cards, skills, capability metadata and URI-addressed extensions.

Linux Foundation, Agentic AI Foundation: current neutral-foundation context around open agent infrastructure.

AGNTCY/Linux Foundation material: open agent discovery, identity, messaging and observability infrastructure.

Healthcare

SNOMED International documentation: unique machine-readable concept identifiers and clinical meaning.

LOINC documentation: standardized identifiers for health measurements, observations and documents.

HL7 FHIR terminology documentation: CodeSystem, ValueSet and ConceptMap.

SNOMED CT compositional grammar: structured expressions composed from clinical concepts.

Finance, legal and government

ISO 20022 Repository and Business Model: governed financial-services concepts and data dictionary.

GLEIF, Legal Entity Identifier and Global LEI Index/System: globally unique entity identifiers and federated issuance model.

OASIS LegalRuleML: formal representation of legal norms.

OASIS Akoma Ntoso/LegalDocML: structured legislative, parliamentary and judicial documents.

European Legislation Identifier material: persistent identification and modeling of legislation.

NIEMOpen documentation: common vocabulary, domain stewardship, extensions, persistence and open governance.

Industrial, observability, commerce, localization and robotics

OPC Foundation, OPC UA Companion Specifications and dictionary references: machine-readable industrial semantic models and external semantic dictionaries.

OpenTelemetry Semantic Conventions: common semantic attribute meanings and stability policies.

GS1 Web Vocabulary and System Architecture: product semantics, Linked Data and cross-standard harmonization.

Unicode LDML/CLDR: standardized locale data, canonical language/locale identifiers and open reconciliation process.

ROS 2 documentation: topics, services, actions and typed interfaces.

Embeddings and AI-memory considerations

Vejendla, Drift-Adapter: A Practical Approach to Near Zero-Downtime Embedding Model Upgrades in Vector Databases: embedding-space migration and index-upgrade problem.

Research on single-vector embedding limitations and compositional retrieval sensitivity, illustrating why similarity should not be conflated with deterministic identity.

Research on evolving LLM-agent memory discussing memory poisoning, semantic drift and retrieval conflict as governance concerns.

Standards and governance process

W3C Process Document: wide review, implementation experience, consensus and royalty-free patent-policy expectations on the Recommendation Track.

IETF RFC 7282 and IETF process material: rough-consensus model.

IETF RFC 7942, Improving Awareness of Running Code: implementation/running-code considerations in standards work.

ISO standards-development material: consensus-based technical committee process.

Linux Foundation open-governance material: neutral technical governance for multi-party open infrastructure.