Governed Semantic Identity as a Protocol Layer for AI Agents, Tools, APIs, Memory, Events, and Workflows

Full report

On this page

Executive assessment

Research conclusion: stable, governed semantic identities can become a useful interoperability layer between AI agents, tools, APIs, memories, events, and workflows, but only if they are treated as a semantic control plane layered on top of existing protocols and schemas, not as a replacement for JSON, JSON Schema, OpenAPI, MCP, A2A, event formats, natural language, or authorization.

The strongest architecture is:

Natural language explains. Schemas constrain. Concept identities disambiguate. Protocols transport. Authorization permits. Registries govern.

That division matters. Modern agent systems already have increasingly strong mechanisms for syntactic interoperability: MCP tools carry JSON Schema; A2A has a defined task/message model and Agent Cards; OpenAPI identifies API operations and describes their inputs; AsyncAPI describes message-driven APIs; CloudEvents standardizes event envelopes; schema registries govern payload evolution. Yet the business meaning of many operations still rests on local names, descriptions, tags, examples, producer-defined strings, or model interpretation.

That gap is especially visible in current tool calling. MCP says tool names need only be unique within a server, explicitly warns that aggregators can encounter collisions such as two servers both exposing search, and states that even the server name is not guaranteed unique. A2A skills have a unique id, but their semantics are conveyed substantially through human-readable name, detailed description, tags, and examples. Mainstream vendor function-calling APIs likewise use function/tool names plus descriptions and JSON schemas to tell the model what a function means. Schemas make calls structurally valid; they do not establish that archive, store, file, close, or move_to_archive across independent systems denote the same operation.

The three sites in the research mission point in a direction that is architecturally relevant:

The Embedded Semantics principle that concept identity should survive model changes and language changes is particularly important for agents. Its public documentation deliberately makes the registry authoritative and treats vectors as retrieval evidence, with unknown_expression and ambiguous_expression rather than forced matching. That is a substantially safer model than asking an embedding nearest-neighbor search to decide what action a tool call means.

There is also substantial prior art outside these projects. SKOS already models concepts identified by URIs, multilingual preferred and alternative labels, notations, definitions, broader/narrower relations, and mappings such as exact and close match. RDF's use of URI/IRI identity and JSON-LD's ability to compact globally meaningful identifiers into shorter local terms demonstrate that global semantic identity plus negotiated compact notation is already a well-established web architecture pattern. A new agent semantic layer should reuse those lessons rather than inventing an incompatible ontology mechanism.

The central architectural recommendation

Do not make action.archive.conversation a magic token whose apparent English structure is assumed to define its semantics.

Instead, distinguish three things:

Canonical semantic identity
    urn:example:concept:action/archive

Human notation
    action.archive

Human labels
    "archive"
    "archive conversation"
    "archivar"
    ...

Capability signature
    action  = urn:example:concept:action/archive
    object  = urn:example:concept:entity/conversation

A capability should usually be a composition of typed concepts, rather than minting one concept for every verb/object combination. That avoids an explosion of identifiers such as:

action.archive.conversation
action.archive.email
action.archive.project
action.archive.document
action.archive.thread
...

There will still be cases where a compound operation deserves its own stable identity because the combination has distinctive business semantics. But the default should be a composable capability signature.

The proposed semantic layer should therefore distinguish at least these kinds of concepts:

The answer to the research mission is therefore yes, conditionally: ConceptCodes can fill a real protocol gap, but their strongest role is semantic binding and capability matching, not data serialization.

A useful mental model is:

┌─────────────────────────────────────────────────────────┐
│ Natural language                                       │
│ explanation • instructions • examples • user intent    │
├─────────────────────────────────────────────────────────┤
│ Governed semantic identity                             │
│ action • object • event • state • role • predicate     │
├─────────────────────────────────────────────────────────┤
│ Structural contracts                                   │
│ JSON Schema • OpenAPI • AsyncAPI • protobuf • Avro     │
├─────────────────────────────────────────────────────────┤
│ Agent/tool/application protocols                       │
│ MCP • A2A • HTTP • JSON-RPC • CloudEvents • Kafka      │
├─────────────────────────────────────────────────────────┤
│ Trust and policy                                       │
│ authentication • authorization • signatures • consent  │
└─────────────────────────────────────────────────────────┘

The semantic layer does not eliminate any of the layers underneath or above it.

Current protocol landscape and the semantic gap

As of August 23, 2026, the agent interoperability landscape has become significantly more structured, but semantic identity remains uneven.

MCP's current specification exposes tools through tools/list; tools have names, human-readable descriptions, JSON Schema input contracts, and optional output schemas. MCP explicitly scopes tool-name uniqueness to one server and discusses collision handling by aggregating clients. The July 28, 2026 specification also added extension capability mechanisms and recommends deterministic tool-list ordering to improve caching and LLM prompt-cache behavior. MCP now has an official registry ecosystem for discovering servers, but that registry principally identifies and distributes servers and their metadata, not globally governed meanings for the operations those servers expose.

That means these two MCP tools can be perfectly valid and nevertheless semantically incompatible:

{
  "name": "archive",
  "description": "Archives the conversation.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "conversation_id": {"type": "string"}
    },
    "required": ["conversation_id"]
  }
}

{
  "name": "archive",
  "description": "Permanently stores the conversation in long-term retention.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "conversation_id": {"type": "string"}
    },
    "required": ["conversation_id"]
  }
}

JSON Schema correctly proves that each requires a string called conversation_id. It cannot prove whether the two notions of archive are equivalent.

The same distinction appears in current vendor tool calling. OpenAI function tools are described with schemas, while structured outputs can enforce schema adherence; Anthropic and Gemini similarly rely on tool/function names, descriptions, and typed parameters. This is good engineering for local function selection, but there is no common cross-vendor semantic namespace that says two independently authored functions perform the same governed business operation.

A2A addresses a different level: agent-to-agent communication. Current A2A Agent Cards describe capabilities and skills, and an AgentSkill contains a unique id, human-readable name, detailed description, tags, examples, and media modes. Agent Cards are discoverable through the standardized well-known endpoint as well as registries or direct configuration. A2A also has an extension mechanism identified by URIs, and those extensions can be marked required. That makes A2A one of the cleanest current integration points for a semantic-capability extension.

A2A v1.0 also has explicit protocol-version behavior and errors when a requested version is unsupported. This is important because protocol negotiation and semantic-registry negotiation should remain independent. An agent can understand A2A v1.0 yet not understand the other party's concept registry. Conversely, two agents can share semantic identities while talking through different transports.

The wider ecosystem is already moving toward structured capability description. AGNTCY's Open Agentic Schema Framework describes itself as a standardized schema system for agent capabilities, interactions, metadata, skills, and domains, using structured taxonomies, while AGNTCY's directory builds discovery over those records. This is complementary rather than contradictory: where an existing OASF taxonomy already has stable identifiers, a ConceptCode ecosystem should reuse or map those identifiers, not create synonyms merely to own another registry.

The gap is also visible outside agent protocols.

OpenAPI's operationId is intended to identify an operation uniquely within an OpenAPI description, not to serve as a universal identity for the business meaning of that operation. OpenAPI also supports human-readable summary/description material and specification extensions, making an x-semantic-* binding practical without modifying the core specification.

JSON Schema's $id provides a canonical URI for a schema resource. That is extremely useful identity, but it identifies the structural contract, not the business concept represented by an instance or property. JSON Schema explicitly separates validation vocabularies from metadata annotations such as title and description, and supports additional vocabularies/custom keywords under defined extension mechanisms. Using $id as though it meant “the semantic meaning of archive” would conflate two different identities.

AsyncAPI similarly has strong structural constructs for channels, operations, messages, payloads, and send/receive actions, while much domain meaning remains in names, descriptions, message metadata, and application conventions. It supports specification extensions, which again makes semantic bindings possible without replacing the format.

CloudEvents is unusually instructive. It standardizes an interoperable event envelope, but the required type attribute is a producer-defined string; reverse-DNS prefixing is recommended so an organization can control the semantics. Its dataschema URI identifies the schema to which event data adheres. In other words, CloudEvents already separates event type from payload schema, but event-type equivalence across independent authorities is still not globally governed by the core specification.

Schema registries solve yet another identity problem. Confluent Schema Registry assigns schema IDs and versions and enforces compatibility within subjects; its documentation explicitly describes schema evolution and compatibility rules. Schema IDs identify schema definitions, not domain meanings such as “invoice approval” or “conversation archival.” Confluent even supports independent schema contexts in which identity is scoped, illustrating why a schema identifier should not be mistaken for universal semantic identity.

This yields a precise map of where semantic identity is weak:

This is why “replace text with IDs” is the wrong framing. The real opportunity is to bind independently evolving structural contracts to stable meanings.

What ConceptCodes would actually add

A ConceptCode should give interoperating systems an assertion of the following form:

“This operation claims to implement the concept governed by authority X under stable identifier Y.”

That assertion provides five capabilities missing from ordinary text:

Identity. Two different labels can knowingly point to one intended concept.

Non-equivalence. Two identical-looking labels can intentionally point to different concepts.

Governance. An authority can define, review, deprecate, map, and audit a concept.

Language independence. Reviewed expressions in multiple languages can point to the same concept without making translations themselves the identity. Embedded Semantics explicitly follows this design.

Machine negotiation. An agent can ask “do you implement concept X?” without first sending an LLM the prose descriptions of every candidate tool.

It does not add proof that an implementation behaves correctly. A malicious or buggy tool can advertise archive and execute delete. Concept identity is a claim, just as an OpenAPI operation description is a claim. Trust requires authenticated publishers, policy, tests, conformance evidence, and sometimes human confirmation.

Proposed semantic-capability protocol

I recommend treating the idea as a small Semantic Capability Layer, abbreviated here as SCL purely for exposition. It should be deployable as extensions to MCP, A2A, OpenAPI, AsyncAPI, CloudEvents, and existing JSON APIs rather than requiring a new transport.

Concept identity and governance

The canonical identity should be globally namespaced, preferably with URI/URN semantics:

urn:acme:concept:action/archive
urn:acme:concept:entity/conversation

or a durable HTTPS identifier controlled by the governing authority.

The friendly notation:

action.archive
entity.conversation

should be treated as a notation, not necessarily the globally unique wire identity. This follows the mature SKOS distinction between a concept's URI identity and its notations/labels. SKOS already provides useful semantics for preferred labels, alternate labels, definitions, broader/narrower relationships, and exact/close mappings.

A minimal registry record could be:

{
  "id": "urn:example:concept:action/archive",
  "notation": "action.archive",
  "kind": "action",
  "status": "stable",

  "labels": {
    "en-US": "archive",
    "es": "archivar"
  },

  "definition": {
    "en-US": "Remove an item from the primary active surface while preserving the item and its governed retention state."
  },

  "semanticConstraints": {
    "doesNotImply": [
      "urn:example:concept:action/delete",
      "urn:example:concept:action/retain-permanently"
    ]
  },

  "relations": {
    "broader": [
      "urn:example:concept:action/change-lifecycle-state"
    ],
    "exactMatch": [],
    "closeMatch": []
  },

  "governance": {
    "authority": "urn:example:registry:messaging",
    "introducedIn": "2026.08",
    "recordRevision": 7,
    "reviewStatus": "approved"
  },

  "provenance": {
    "reviewedBy": ["messaging-semantics-board"],
    "reviewedAt": "2026-08-15T00:00:00Z"
  }
}

The most important governance invariant should be:

The intended referent of a stable ConceptCode is immutable.

Labels can improve. Translations can be added. Examples can change. Provenance can be expanded. A spelling error can be fixed. But if the authority changes what the concept means, it must mint a new identifier and relate the old one through supersededBy, closeMatch, broader, or another explicitly typed relationship.

That principle is stronger than merely putting v2 on everything. It means registry versions describe snapshots of metadata and mappings; they do not redefine historical concept identity.

This is aligned with Embedded Semantics' public architecture, which separates stable ConceptCode identity from provenance and registry evolution and explicitly aims for concept identity to survive embedding-model and language changes.

Capability signatures instead of overloaded codes

A tool should normally advertise a typed signature:

{
  "action": "urn:example:concept:action/archive",
  "object": "urn:example:concept:entity/conversation"
}

rather than relying solely on:

action.archive.conversation

The full capability may include:

{
  "action": "urn:example:concept:action/archive",
  "object": "urn:example:concept:entity/conversation",

  "effects": [
    "urn:example:concept:effect/removes-from-active-view"
  ],

  "excludes": [
    "urn:example:concept:effect/delete-content"
  ],

  "risk": [
    "urn:example:concept:risk/state-changing"
  ]
}

This resolves the original ambiguity much better than a single verb. “Archive” can mean different things in email, legal records, source-code repositories, databases, and backups. Stable semantics require a definition and domain context, not just a cleaner identifier.

What remains ordinary JSON and schema

JSON and JSON Schema should continue to own:

• primitive types;
• object/array shape;
• required and optional properties;
• numbers and ranges;
• patterns;
• unions;
• defaults;
• structural enums;
• nested data;
• cardinality;
• serialization;
• schema validation.

JSON Schema is designed for precisely those structural responsibilities, and $id already provides canonical schema-resource identity.

ConceptCodes should answer a different question:

JSON Schema:   "Is this value structurally valid?"
ConceptCode:   "What does this operation/property/state mean?"

Consequently, tool parameters should not generally be replaced with ConceptCodes.

Consider:

{
  "conversation_id": "c_8291",
  "include_attachments": true,
  "retention_days": 30
}

There is little value in transforming that into an ontology-heavy structure merely because a semantic registry exists. conversation_id is an instance identifier, true is a boolean, and 30 is a number.

Parameter-level semantic annotations make sense when the semantic role itself must match across independently developed systems:

{
  "type": "integer",
  "minimum": 1,
  "x-concept": "urn:example:concept:property/retention-period-days"
}

Even then the value remains ordinary JSON.

Concept values themselves make sense for taxonomy-like fields:

{
  "retentionPolicy": {
    "concept": "urn:example:concept:retention/standard",
    "label": "Standard retention"
  }
}

The practical rule should be:

Put ConceptCodes on boundaries of meaning, not on every leaf of a JSON tree.

Semantic capability declaration

A proposed protocol-neutral tool declaration could be:

{
  "name": "archive_conversation",
  "description": "Archives a conversation without deleting its content.",

  "semanticCapability": {
    "profile": "urn:semantic-capabilities:profile:1",
    "action": "urn:example:concept:action/archive",
    "object": "urn:example:concept:entity/conversation",
    "effects": [
      "urn:example:concept:effect/remove-from-primary-view"
    ],
    "risk": [
      "urn:example:concept:risk/state-changing"
    ]
  },

  "inputSchema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
      "conversation_id": {
        "type": "string",
        "description": "Conversation instance identifier"
      },
      "retention_policy": {
        "type": "string",
        "enum": ["standard", "legal_hold"]
      },
      "dry_run": {
        "type": "boolean",
        "default": false
      }
    },
    "required": ["conversation_id"],
    "additionalProperties": false
  }
}

The model can still read description. Existing clients can still invoke archive_conversation. The semantic-aware client gains an additional deterministic signal.

Capability negotiation

The semantic layer should support a four-stage negotiation:

discover → advertise → bind → use

A client first discovers semantic support through the parent protocol.

It then advertises the semantic profiles and registry snapshots it understands.

The server selects a mutually supported profile and binds compact aliases to exact registry digests.

Only after that should compact identifiers be used.

For example:

{
  "semanticOffer": {
    "profiles": [
      "urn:semantic-capabilities:profile:1"
    ],

    "conceptKinds": [
      "action",
      "entity",
      "event",
      "state",
      "predicate"
    ],

    "registries": [
      {
        "authority": "urn:example:registry:messaging",
        "snapshot": "2026.08",
        "digest": "sha256:8f97..."
      }
    ],

    "unknownConceptPolicy": "reject-required-fallback-optional"
  }
}

Server:

{
  "semanticAccept": {
    "profile": "urn:semantic-capabilities:profile:1",

    "registries": [
      {
        "authority": "urn:example:registry:messaging",
        "snapshot": "2026.08",
        "digest": "sha256:8f97...",
        "alias": "m"
      }
    ],

    "compactAliases": true
  }
}

After this exchange,

m:action.archive

can be understood as a compact notation for an exact expanded identity. The alias must never outlive the binding context unless its registry digest is persisted with it.

Unknown concepts

Unknown concepts are unavoidable in a federated system. They should never be silently converted to whatever looks closest for a state-changing operation.

Recommended behavior:

{
  "error": {
    "code": "semantic_concept_unknown",
    "concept": "urn:newco:concept:action/cold-archive",
    "registry": "urn:newco:registry:storage",
    "requiredForOperation": true,

    "recovery": {
      "registryDescriptorAvailable": true,
      "textFallbackAvailable": false
    }
  }
}

For an optional annotation, the receiver can continue using the normal schema/text contract while recording that the semantic annotation was unresolved.

For a required action concept, authorization concept, destructive-effect concept, or policy concept, the receiver should stop.

This mirrors a valuable feature of Embedded Semantics' approach: an unknown expression is a legitimate outcome rather than a reason to fabricate a semantic match.

Approximate embedding resolution can still be extremely useful during discovery:

"put this chat away"
       ↓
embedding / lexical resolver
       ↓
candidate:
  action.archive          0.83
  action.move             0.67
  action.retain           0.38
       ↓
registry verification
       ↓
action.archive

But the vector decides what to consider, not what the identifier means. This is precisely the distinction Embedded Semantics emphasizes.

Semantic error model

The semantic protocol needs a small bootstrap error vocabulary that does not itself require registry resolution. Otherwise the parties could not report “I cannot resolve your registry” without resolving a registry first.

A fixed base protocol enum should therefore include at least:

Those fixed errors can themselves optionally carry richer ConceptCodes once the semantic layer is functioning.

That design echoes the separation already found in MCP and A2A: both protocols define ordinary protocol/error structures for invalid requests, unsupported operations, extensions, and versions rather than depending on an external semantic system to bootstrap communication.

Registry discovery and federation

Registry discovery should be explicit and trust-aware.

The preferred order is:

protocol manifest
    ↓
explicit registry authority + digest
    ↓
trusted local cache / enterprise catalog
    ↓
authenticated registry retrieval
    ↓
optional public discovery

A receiver should not see an unfamiliar URI inside an untrusted message and automatically dereference it. That creates SSRF, tracking, supply-chain, and denial-of-service opportunities.

Registries should be advertised through native discovery facilities:

A2A already provides a well-known discovery endpoint, supports registries/catalogs, and permits signed Agent Cards. Those are useful patterns for semantic registry manifests.

MCP's official registry is likewise a useful distribution analogy: it supplies an open catalog for servers and supports a broader sub-registry ecosystem. A concept registry does not need to be one global centralized database; the more plausible architecture is federated authorities with globally unique namespaces and explicit mappings.

Offline caching

Offline operation should be a first-class requirement, not an edge case.

A registry package should be content-addressed and signed:

{
  "registry": "urn:example:registry:messaging",
  "snapshot": "2026.08",
  "digest": "sha256:8f97...",
  "createdAt": "2026-08-15T00:00:00Z",
  "expiresAt": "2026-11-15T00:00:00Z",
  "keyId": "registry-key-2026-02",
  "conceptCount": 842,
  "signature": "..."
}

The package would contain concept records, labels, mappings, status, deprecation relationships, provenance, and optionally schemas or links to schemas.

The runtime lookup path should preferably be:

local exact lookup
   ↓ miss
local alias/mapping lookup
   ↓ miss
optional online registry
   ↓ unavailable
explicit unknown/fallback policy

That architecture closely fits both Embedded Semantics' exact-registry/abstention design and JustAnIota's emphasis on registry snapshots, evidence, and database/offline-capable operation.

A stale registry is not always equally dangerous. A useful policy distinction is:

display label              → stale cache often acceptable
read-only discovery        → bounded stale cache acceptable
state-changing operation   → stricter freshness/pinning
authorization semantics    → strict freshness + revocation
destructive operation      → strictest policy

Registry revocation therefore needs a separate mechanism from ordinary metadata versioning.

Version negotiation

Four kinds of versions must remain distinct:

protocol version
semantic-profile version
registry snapshot/revision
tool/API/schema version

A common failure would be to make a concept mean something different because the registry moved from version 14 to version 15.

Instead:

Registry v14:
  urn:...:action/archive = meaning A

Registry v15:
  urn:...:action/archive = still meaning A
  label improved
  Spanish label added
  mapping metadata changed

If meaning A itself was wrong:

Registry v16:
  old:
    urn:...:action/archive-v1
    status: deprecated
    supersededBy: urn:...:action/archive-v2

  new:
    urn:...:action/archive-v2

The suffix need not literally contain v1 or v2; the key is that the identifier changes.

For cross-version mappings, distinguish:

exact equivalent
close equivalent
broader
narrower
supersedes
deprecated
incompatible

SKOS already demonstrates why exactMatch and closeMatch must not be conflated.

For state-changing tools, automatic negotiation should normally accept exact semantic equivalence only. A “close match” is useful for search; it is a poor basis for moving money, deleting data, granting access, or modifying retention.

Integration with MCP, A2A, APIs, schemas, events, memory, and compact messages

The semantic layer becomes useful only if it can integrate incrementally with the protocols that already exist.

MCP integration

MCP is arguably the highest-value initial target.

Current MCP tools already separate tool description from JSON Schema, but tool naming is local to the server. MCP's extension capability mechanisms provide a plausible route for an optional semantic profile without breaking older clients.

The recommended pattern is:

ConceptCode determines candidate capability
        ↓
MCP server/tool discovery selects implementation
        ↓
existing MCP tool name remains invocation address
        ↓
existing inputSchema validates arguments
        ↓
existing MCP call executes

In other words, do not replace the MCP tool name.

Proposed semantic-aware discovery:

{
  "name": "conversation_archive",
  "description": "Archives a conversation without deletion.",

  "semantic": {
    "capabilities": [
      {
        "action": "urn:example:concept:action/archive",
        "object": "urn:example:concept:entity/conversation"
      }
    ]
  },

  "inputSchema": {
    "type": "object",
    "properties": {
      "conversation_id": {
        "type": "string"
      }
    },
    "required": ["conversation_id"]
  }
}

An ordinary MCP client ignores the semantic extension and sees a normal tool.

A semantic client can perform:

requested concept:
    action=archive
    object=conversation

server 1:
    tool=archive_chat
    exact semantic match

server 2:
    tool=long_term_store
    action=retain
    NOT a match

server 3:
    tool=move_thread
    action=move
    NOT a match

This is a concrete improvement over LLM-only tool selection.

MCP's current recommendation that tool lists be deterministic for client caching and prompt-cache efficiency is relevant to token optimization: semantic descriptors could similarly be cached out of band and referenced repeatedly by compact identities instead of resending full text.

Parameter-level ConceptCodes should be sparse. MCP's current specification already demonstrates that schema annotations can carry protocol-specific behavior through its x-mcp-header mechanism, but a semantic extension should be standardized rather than arbitrarily overloading schemas.

OpenAPI integration

OpenAPI's operationId should remain the implementation-facing operation identifier:

operationId: archiveConversation

A semantic extension could add:

x-semantic-capability:
  action: urn:example:concept:action/archive
  object: urn:example:concept:entity/conversation

Parameters remain ordinary OpenAPI/JSON Schema:

parameters:
  - name: conversationId
    in: path
    required: true
    schema:
      type: string

This creates a valuable correspondence:

operationId
    identifies implementation operation in this API

ConceptCode
    identifies intended business capability across APIs

schema $id / component schema
    identifies structural data contract

OpenAPI formally requires operationId, where present, to be unique among the operations in that API description; that scope is exactly why it should not be mistaken for a universal semantic identifier.

An OpenAPI-to-MCP adapter could preserve the semantic annotation when generating tools, allowing a concept to survive transport transformations:

OpenAPI operation
       │
       │ same ConceptCodes
       ▼
generated MCP tool
       │
       │ same ConceptCodes
       ▼
A2A agent skill

That is one of the strongest practical arguments for the layer.

JSON Schema integration

Do not redefine $id.

JSON Schema says $id identifies a schema resource by canonical URI. That should remain exactly what it does.

Where semantic property annotations are important, two approaches are possible.

A lightweight ecosystem can use an enclosing sidecar:

{
  "schema": {
    "$ref": "urn:schemas:archive-request"
  },

  "semanticBindings": {
    "/properties/retentionPolicy":
      "urn:example:concept:property/retention-policy"
  }
}

A mature ecosystem could define a proper JSON Schema semantic vocabulary/dialect:

{
  "$schema": "...semantic-enabled-schema-dialect...",
  "type": "object",
  "properties": {
    "retentionPolicy": {
      "type": "string",
      "x-concept": "urn:example:concept:property/retention-policy"
    }
  }
}

The former is easier to deploy. The latter gives validators a formal extension mechanism. JSON Schema explicitly supports vocabularies and implementation-specific/custom keywords, but interoperability depends on implementations understanding those extensions, so an arbitrary custom keyword must not be assumed universally meaningful.

A2A integration

A2A has a particularly good extension point because its AgentExtension is URI-identified and can be declared required, while Agent Cards provide the natural capability-discovery document.

A proposed Agent Card fragment could be:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "urn:semantic-capabilities:a2a-extension:1",
        "required": false,
        "params": {
          "registries": [
            {
              "authority": "urn:example:registry:messaging",
              "digest": "sha256:8f97..."
            }
          ]
        }
      }
    ]
  },

  "skills": [
    {
      "id": "archive-thread",
      "name": "Archive conversation",
      "description": "Archives a conversation without deleting it.",
      "tags": ["archive", "conversation"],

      "semanticCapability": {
        "action": "urn:example:concept:action/archive",
        "object": "urn:example:concept:entity/conversation"
      }
    }
  ]
}

Current A2A's skill description, tags, and examples remain useful to the LLM and human. The concept identifiers provide a separate deterministic matching signal.

A2A already negotiates extensions and protocol versions; semantic negotiation can ride that mechanism without conflating the two.

Signed Agent Cards are particularly relevant. Current A2A allows cards to be JWS-signed after canonicalization, giving an implementation a way to authenticate the claim that a provider advertises certain capabilities. That still does not prove behavioral conformance, but it prevents an intermediary from silently substituting capability declarations.

Event-bus and AsyncAPI integration

For CloudEvents, the safe migration path is to preserve type and add a semantic extension:

{
  "specversion": "1.0",
  "id": "evt-8831",
  "source": "/messaging/conversations",
  "type": "com.example.conversation.archived",

  "semantictype": "urn:example:concept:event/conversation-archived",

  "dataschema": "urn:example:schema:conversation-archived:v3",

  "data": {
    "conversationId": "c_42",
    "archivedAt": "2026-08-23T16:20:00Z"
  }
}

This separation is deliberate.

CloudEvents defines type as a producer-defined event-type string and dataschema as the schema describing data; it also permits extension context attributes. A semantic-type extension therefore fits the model without reinterpreting dataschema.

A broker or bridge could route:

semantictype == event.conversation-archived

even when producers use different native types:

com.vendorA.chat.archived.v2
io.vendorB.thread.lifecycle.changed
internal.messaging.archive-completed

provided all three have been deliberately mapped to the same governed semantic concept.

This is useful because it moves cross-system mapping from arbitrary string comparisons into governed mapping records.

AsyncAPI could bind the same concept at the message or operation level:

messages:
  ConversationArchived:
    x-semantic-event:
      concept: urn:example:concept:event/conversation-archived

The AsyncAPI schema still defines the payload. The ConceptCode tells middleware what kind of occurrence it represents.

Schema registries should remain separate. A schema registry answers:

Which schema version describes these bytes/fields?
Will a new schema remain compatible?

A concept registry answers:

What domain meaning does this message claim to carry?
Which other event concepts are equivalent, broader, narrower, or superseded?

Confluent and Apicurio already provide rich schema-version and compatibility governance, demonstrating why there is little value in duplicating those functions in a ConceptCode registry. Instead, registries should cross-reference one another.

For example:

{
  "eventConcept":
    "urn:example:concept:event/conversation-archived",

  "allowedSchemas": [
    {
      "schemaRegistry": "prod-events",
      "subject": "conversation-lifecycle-value",
      "version": 7
    }
  ]
}

Workflow-engine integration

ConceptCodes are most useful at workflow boundaries:

event received
     ↓
semantic event concept
     ↓
workflow trigger
     ↓
semantic action capability
     ↓
tool/agent binding

They should not replace internal workflow-node IDs, retry counters, timers, state-machine transitions, or engine-native scheduling structures.

For example:

{
  "stepId": "step_14",
  "type": "invoke",

  "requiredCapability": {
    "action": "urn:example:concept:action/archive",
    "object": "urn:example:concept:entity/conversation"
  },

  "binding": {
    "implementation": "mcp://messaging/archive_conversation"
  }
}

step_14 belongs to the workflow instance.

The ConceptCodes define what capability the step requires.

The MCP binding specifies which implementation currently satisfies it.

That separation would make workflow portability substantially easier: rebinding the implementation would not require renaming the semantic intent.

Durable AI memory integration

Durable AI memory is one of the most compelling long-term applications.

Many memory architectures currently combine original text, extracted facts, metadata, and embeddings. Embeddings are powerful for fuzzy recall but their coordinates depend on model choice and can change when embeddings are regenerated. Embedded Semantics explicitly argues that concept identity should not depend on vector coordinates and treats registry identity as authoritative instead.

A durable memory record could therefore preserve both:

{
  "memoryId": "mem_0183",
  "memoryType": "semantic_fact",

  "subject": {
    "entityId": "user_42"
  },

  "predicate": {
    "concept":
      "urn:example:concept:preference/preferred-communication-channel"
  },

  "object": {
    "value": "email"
  },

  "evidence": {
    "text": "Please email me rather than calling.",
    "conversationId": "c_941"
  },

  "temporal": {
    "observedAt": "2026-08-18T19:31:00Z",
    "validFrom": "2026-08-18T19:31:00Z"
  },

  "registry": {
    "digest": "sha256:8f97..."
  },

  "embedding": {
    "model": "embedding-model-x",
    "vectorRef": "vec_729"
  }
}

Here the embedding helps retrieve the memory.

The ConceptCode provides a durable index for the predicate.

The text preserves nuance and auditability.

The timestamp handles temporal validity.

This enables queries such as:

Find all memories asserting:
    preference.preferred-communication-channel

without hoping every embedding model places “preferred contact method,” “likes email,” and “contact via email” in sufficiently similar regions.

It also helps with conflict detection:

Memory A:
  predicate = preferred-communication-channel
  object = email
  validFrom = January

Memory B:
  predicate = preferred-communication-channel
  object = SMS
  validFrom = August

A memory manager now knows deterministically that the two records concern the same predicate and can apply temporal/conflict policy.

Concept identity should not replace the source memory. Otherwise the system loses qualifiers, irony, uncertainty, exceptions, interpersonal context, and evidence. The best architecture is:

source text + structured memory + ConceptCodes + embeddings + provenance

not:

everything → ConceptCode

Compact-message and JustAnIota integration

JustAnIota is especially interesting because its public IOTA-1 material already reaches an important conclusion: Unicode is a representation substrate, while meaning must be supported by registries, schemas, canonicalization, examples, and validation. Its profile keeps source text, locale, registry information, payload, evidence, and compact candidates distinguishable.

Protocol5 makes the related distinction even more explicit: a visible expression is evidence pointing toward a concept candidate, not authority for the concept itself, and its current IOTA conversion is deliberately described as approximate rather than lossless translation.

Stable ConceptCodes could therefore strengthen compact protocols by giving them a durable backing layer:

Human expression
"archive this conversation"
          │
          ▼
Resolved concept capability
action/archive + entity/conversation
          │
          ▼
Negotiated compact alias
[17, 4]
          │
          ▼
Compact wire representation

The safe persistent representation is:

{
  "registryDigest": "sha256:8f97...",
  "concepts": [
    "urn:example:concept:action/archive",
    "urn:example:concept:entity/conversation"
  ]
}

After the parties negotiate the digest, the transient wire form can be:

["s1", "m", 17, 4, {"id": "c_42"}]

where:

m      = exact pinned registry snapshot
17     = action/archive
4      = entity/conversation

The numeric aliases have no standalone semantics. Without the registry binding, [17,4] must be treated as uninterpretable.

That makes compact messaging safer than assigning permanent semantic authority to aesthetically suggestive Unicode characters.

JustAnIota's evidence model is valuable for another reason: it explicitly distinguishes deterministic/database modes, hybrid or AI-assisted paths, approximation status, registry versions/digests, scores, alternatives, warnings, and unknown rates. Those ideas are well suited to a resolver that maps language onto stable concepts, even though the resulting concept identity itself should not be approximate.

The strongest integration is therefore:

ConceptCode = exact governed identity. IOTA compact form = negotiated representation. Embedding/vector score = retrieval evidence. Natural language = explanatory evidence.

For any action with irreversible or consequential side effects, an approximate compact candidate should never be the sole authorization or dispatch signal.

Worked protocol examples

The following examples show what changes in an actual agent system.

Resolving the archive ambiguity

Suppose three agents advertise:

Agent A
  tool: archive_chat
  description: "Archive a conversation."

Agent B
  tool: store_forever
  description: "Archive content in permanent retention."

Agent C
  tool: move_from_inbox
  description: "Archive a conversation from the inbox."

Today, an orchestrating LLM may have to infer whether those operations are equivalent.

With semantic capability declarations:

Agent A:
{
  "action": "urn:msg:action/archive",
  "object": "urn:msg:entity/conversation"
}

Agent B:
{
  "action": "urn:records:action/retain-permanently",
  "object": "urn:records:entity/content-record"
}

Agent C:
{
  "action": "urn:mail:action/move",
  "object": "urn:mail:entity/conversation",
  "destination":
    "urn:mail:container/archive"
}

Now:

User: "Archive this conversation."

Resolver:
  candidate action = msg:action/archive
  object = msg:entity/conversation

Agent A:
  exact semantic match

Agent B:
  no match

Agent C:
  possible pragmatic alternative, not an exact semantic match

The LLM still handles the user's language. The semantic layer prevents three tool authors' use of the English word “archive” from silently becoming the protocol definition.

Semantic negotiation handshake

A2A-style discovery:

{
  "name": "MessagingAgent",

  "capabilities": {
    "extensions": [
      {
        "uri": "urn:semantic-capabilities:a2a:1",
        "required": false,
        "params": {
          "profiles": [
            "urn:semantic-capabilities:profile:1"
          ],
          "registries": [
            {
              "authority": "urn:msg:registry",
              "snapshot": "2026.08",
              "digest": "sha256:a81c..."
            }
          ]
        }
      }
    ]
  }
}

Client request:

{
  "semanticOffer": {
    "profile": "urn:semantic-capabilities:profile:1",

    "knownRegistries": [
      {
        "authority": "urn:msg:registry",
        "digest": "sha256:a81c..."
      }
    ],

    "supportsCompactAliases": true,
    "unknownPolicy": "reject-required"
  }
}

Server:

{
  "semanticAccept": {
    "profile": "urn:semantic-capabilities:profile:1",

    "registryBindings": {
      "msg": {
        "authority": "urn:msg:registry",
        "digest": "sha256:a81c..."
      }
    },

    "aliases": {
      "17": "urn:msg:concept:action/archive",
      "4": "urn:msg:concept:entity/conversation"
    }
  }
}

Subsequent compact request:

{
  "semantic": {
    "r": "msg",
    "a": 17,
    "o": 4
  },

  "arguments": {
    "conversation_id": "c_42"
  }
}

Expanded meaning:

{
  "semantic": {
    "action": "urn:msg:concept:action/archive",
    "object": "urn:msg:concept:entity/conversation"
  },

  "arguments": {
    "conversation_id": "c_42"
  }
}

Human-auditable version:

{
  "semantic": {
    "action": {
      "concept": "urn:msg:concept:action/archive",
      "label": "Archive"
    },
    "object": {
      "concept": "urn:msg:concept:entity/conversation",
      "label": "Conversation"
    }
  },

  "arguments": {
    "conversation_id": "c_42"
  }
}

A well-designed protocol should permit all three forms, with the compact one only after negotiation.

Unknown concept conversation

Agent A:
  I require:
    urn:records:action/transfer-to-cold-archive

Agent B:
  Registry authority is trusted,
  but my pinned snapshot does not contain that concept.

Agent B → Agent A:
  semantic_concept_unknown
  known snapshot: 2026.07
  requested registry digest: sha256:9d21...
  operation requires exact semantics
  text fallback: prohibited

Agent A:
  Provides signed registry delta.

Agent B:
  Verifies signature and digest.
  Resolves concept.

Agent B:
  Capability not implemented.

Agent B → Agent A:
  semantic_capability_unsupported

Notice that the system never says:

“Cold archive sounds similar to archive; I'll call my archive tool.”

That is the behavior the semantic layer is intended to eliminate.

Version mismatch conversation

Agent A:
  action = urn:msg:concept:action/archive-old

Agent B:
  concept known
  status = deprecated
  replacement =
      urn:msg:concept:action/archive

Registry relation:
  old → new = exact replacement

Agent B policy:
  exact replacements are accepted for reversible operations.

Agent B:
  Executes mapped operation.
  Records original and replacement IDs.

For a destructive operation:

relation = closeMatch

should produce:

semantic_mapping_inexact

rather than automatic execution.

Multilingual agent conversation

User:
  "Archiva esta conversación."

Resolver:
  reviewed Spanish expression
      ↓
  urn:msg:concept:action/archive

Agent capability:
  label displayed in English:
      "Archive conversation"

Machine comparison:
  concept IDs equal

The matching step is no longer dependent on English translation quality. This is precisely the type of registry-backed multilingual identity Embedded Semantics is designed to support, although its public registry is not yet populated at scale.

Event-to-workflow-to-tool conversation

CloudEvent arrives:

type =
  vendorA.messaging.thread.archived

semantictype =
  urn:msg:concept:event/conversation-archived

Workflow declares:

trigger:
  event concept =
    urn:msg:concept:event/conversation-archived

Workflow next step declares:

required capability:
  action =
    urn:crm:concept:action/update
  object =
    urn:crm:concept:entity/conversation-record

Capability resolver selects:

MCP server:
  CRM

tool:
  update_conversation_status

The event vendor, workflow engine, MCP server, and CRM tool can all retain their native identifiers. The ConceptCodes supply the cross-boundary semantic joins.

Durable-memory conversation

At time T1:

User:
  "Email is the best way to reach me."

Memory extraction:

{
  "predicate":
    "urn:user:concept:preference/contact-channel",
  "object":
    "urn:comm:concept:channel/email"
}

At time T2:

User:
  "Text me instead from now on."

The memory system does not need embedding similarity to discover the conflict. The same predicate identity tells it that the new assertion supersedes or temporally qualifies the old one.

Embeddings can still retrieve the source passages when an LLM needs their linguistic context.

Security, compatibility, performance, and adoption

Semantic identity removes one class of ambiguity but creates a new trust surface. A production design must assume hostile registries, hostile agents, compromised mappings, stale caches, misleading labels, and prompt injection.

Security analysis

A key principle is:

Knowing exactly what an action means is not the same as being authorized to perform it.

A ConceptCode can help a policy engine say:

deny action.delete
allow action.archive

but OAuth scopes, credentials, user consent, resource-level ACLs, legal holds, and contextual policy remain necessary.

MCP itself emphasizes validation, access controls, careful treatment of tool results, and user confirmation around tool invocation. The semantic layer should strengthen those controls, not bypass them.

A2A's signed Agent Cards provide a useful integrity primitive: a signature can prove that an authenticated provider asserted a capability. It cannot prove the implementation actually behaves as the concept definition says.

That gap suggests a future conformance evidence layer:

{
  "capability":
    "urn:msg:concept:action/archive",

  "conformance": {
    "profile": "urn:msg:test-suite:archive:1",
    "result": "pass",
    "evidenceDigest": "sha256:..."
  }
}

This is closer to what JustAnIota and Protocol5 are already exploring with validator and evidence outputs: claims become more trustworthy when accompanied by inspectable provenance and validation rather than treated as self-authenticating.

Backward compatibility

Backward compatibility is one of the strongest arguments for making the semantic layer an annotation and negotiation extension.

An old client sees:

{
  "name": "archive_conversation",
  "description": "Archives a conversation.",
  "inputSchema": {...}
}

A new client sees:

{
  "name": "archive_conversation",
  "description": "Archives a conversation.",
  "semanticCapability": {...},
  "inputSchema": {...}
}

The invocation contract is unchanged.

The semantic layer can therefore be rolled out in stages:

Stage A
human descriptions only

Stage B
descriptions + optional ConceptCodes

Stage C
ConceptCodes used for discovery/matching

Stage D
semantic capability negotiation

Stage E
compact aliases after negotiation

No stage requires removing human-readable language.

A2A's extension mechanism is explicitly designed to add functionality while retaining compatibility with core protocol clients, while OpenAPI and AsyncAPI provide extension mechanisms for analogous purposes.

Token-efficiency analysis

ConceptCodes can reduce token consumption, but the claim needs qualification.

They will not save much when:

full URI + label + definition + schema

is sent on every request. A long semantic URI can itself tokenize worse than a short tool name.

Savings become significant when the semantic registry is cached outside the model context:

cold start:
    retrieve definitions once
    bind aliases

warm interactions:
    send stable aliases / compact capability signatures

The highest-potential savings are therefore in:

• repeated capability advertisements;
• large tool catalogs;
• repeated agent discovery;
• repetitive event-type descriptions;
• workflow handoffs;
• durable-memory predicates;
• machine-to-machine control traffic.

The lowest-potential savings are in rich user instructions, complex parameter payloads, or one-off interactions where a definition must be shown anyway.

MCP's current move toward deterministic tool ordering explicitly aims in part to improve prompt-cache hit rates, illustrating that the cost of repeatedly presenting tool catalogs to models is already an active protocol concern.

An important counterpoint is that LLMs cannot reason from opaque identifiers they have never been grounded in. A cold model receiving:

urn:example:concept:a7f8d129

learns nothing about its meaning.

The useful form is therefore usually:

{
  "concept": "urn:example:concept:action/archive",
  "label": "Archive"
}

with the richer definition available by cache or lookup.

After negotiation, a machine-to-machine hop might need only:

{"a":17,"o":4}

The expected efficiency curve is consequently:

Cold-start semantic protocol
    possibly MORE expensive

Warm cached protocol
    potentially much cheaper

Pure LLM reasoning
    still requires natural-language grounding

Deterministic routing
    can avoid some LLM calls entirely

The last effect may be more important than raw token compression. If an orchestrator can resolve:

required capability X
        ==
advertised capability X

without asking a model to compare 40 textual descriptions, the semantic layer may reduce both tokens and selection variance.

This remains an empirical hypothesis. Neither Embedded Semantics' currently empty public registry nor the public IOTA experiments establish production-scale token savings.

Adoption barriers

The hardest problem is not syntax. It is governance.

Concept granularity. What exactly does “archive” mean? Email systems, records-management systems, source repositories, and storage systems may legitimately disagree.

Ontology politics. Different vendors will prefer their own vocabularies.

Authority. Someone must be allowed to mint and deprecate terms.

Federation. A single universal registry is unlikely to govern every vertical.

Equivalence governance. Declaring two third-party concepts exactly equivalent can have operational consequences.

Cold-start cost. A new agent must acquire enough registry context to interpret unfamiliar codes.

Implementation truth. Advertising a code does not prove behavior.

LLM usability. Models still need language labels and definitions.

Developer ergonomics. A semantic annotation system that requires ontology expertise for every ordinary API property will fail.

Economic incentives. The party doing the work of semantic annotation is not always the party receiving the benefit.

Vocabulary duplication. SKOS, Schema.org, OASF taxonomies, industry standards, ISO identifiers, and vendor vocabularies already exist. A ConceptCode project that ignores them will create another interoperability problem instead of solving one. SKOS in particular already supplies a well-understood model for URI-identified concepts, labels, notations, hierarchy, and mappings.

The best answer to ontology politics is therefore federated namespaces plus explicit mappings, not one universal vocabulary:

urn:vendorA:...
urn:vendorB:...
urn:industry-standard:...
        │
        ├── exactMatch
        ├── closeMatch
        ├── broader
        └── narrower

For high-risk operations, mapping trust should be explicit. An enterprise might trust Vendor A's own definitions while refusing a third party's claim that Vendor A's transfer is exactly equivalent to Vendor B's send.

Where semantic identity does not improve interoperability

There are several places where adding ConceptCodes would be negative value.

A JSON object already described unambiguously by a schema does not become more interoperable because every property gets a semantic URI.

A local helper function called once inside one application does not need global governance.

Opaque identifiers such as task IDs, conversation IDs, Kafka offsets, session IDs, and database keys are instance identities, not semantic concepts.

Dynamic user constraints such as:

“Archive all of these except the conversations with the legal team, and leave anything from this week visible until Friday.”

cannot be reduced safely to one action code. Concept identity may anchor archive, but scope, exceptions, temporal conditions, and user intent remain structured parameters and/or language.

Authorization scopes cannot be replaced by semantic capabilities.

Embeddings cannot be replaced by registries for fuzzy retrieval.

Registries cannot replace embeddings for unseen language.

Schemas cannot be replaced by concepts for structural validation.

Human descriptions should not disappear. They remain indispensable for audit, user interfaces, model grounding, and new-concept discovery.

The architecture succeeds precisely by not asking semantic identifiers to solve every problem.

Prototype recommendation and validation experiments

The most credible prototype is deliberately narrow.

Do not start by building “the ontology of all agent actions.”

Start with one domain in which synonyms have consequential differences. Conversation/content lifecycle management is a good candidate because the motivating terms are naturally ambiguous:

archive
delete
move
hide
close
retain
freeze
export
purge
restore

Recommended prototype architecture

A first registry should contain perhaps tens to low hundreds of carefully governed concepts rather than thousands of automatically generated entries.

Its records should support:

canonical identifier
kind
human notation
preferred multilingual labels
alternate expressions
precise definition
positive examples
hard negative examples
status
provenance
broader/narrower relations
exact/close mappings
supersession
registry snapshot
signature

The use of hard negatives and explicit abstention would follow the strongest part of Embedded Semantics' published methodology, which evaluates concept resolution rather than generic similarity and treats unknown results as legitimate.

The runtime components should be:

                 ┌────────────────────┐
Natural language │ Resolver           │
────────────────►│ exact + candidate  │
                 └─────────┬──────────┘
                           │ ConceptCodes
                           ▼
                 ┌────────────────────┐
                 │ Capability matcher │
                 └─────────┬──────────┘
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
             MCP tools            A2A agents
                 │                   │
                 └─────────┬─────────┘
                           ▼
                 Existing JSON/schema

A separate registry service would expose:

resolve expression
get concept
get registry manifest
download signed snapshot
resolve mappings
query capabilities
validate concept set

It should support disconnected/offline lookup from day one.

A registry resolver should preferably use:

exact reviewed expression
        ↓ if no result
controlled aliases
        ↓
optional embedding candidate retrieval
        ↓
ranked candidates
        ↓
confidence / ambiguity evaluation
        ↓
exact ConceptCode or UNKNOWN

This preserves Embedded Semantics' key distinction between semantic authority and vector evidence.

Experiment: cross-agent tool selection

Question: Do stable semantic capability declarations materially reduce wrong tool selection?

Build 100–500 tasks containing deliberately confusable capabilities:

archive vs retain permanently
delete vs revoke access
send vs schedule
cancel vs refund
close vs resolve
copy vs move
export vs publish
disable vs delete

Implement equivalent tool catalogs using:

Condition A:
  names + descriptions + JSON Schema

Condition B:
  names + descriptions + schema + ConceptCodes

Condition C:
  ConceptCodes + minimal labels + cached definitions

Condition D:
  ConceptCodes only

Test multiple agent models and vendors.

Measure:

correct tool selection
semantic near-miss rate
destructive-action error rate
clarification rate
input-schema validation rate
total prompt tokens
completion tokens
latency
registry-resolution overhead
cold-start vs warm-cache cost

Add multilingual prompts and paraphrases.

Include hard negatives where descriptions are intentionally similar.

The predicted result is not that codes-only wins. The most plausible winner is ConceptCodes plus human descriptions, because codes provide deterministic identity while language lets the model reason.

A convincing outcome would be a statistically meaningful reduction in semantic near-misses while preserving or reducing token cost after cache warm-up.

Experiment: durable memory across model and language changes

Question: Does semantic identity make memories more durable across embedding migrations?

Create a longitudinal memory corpus containing preferences, commitments, relationships, states, and contradictory updates.

Compare:

System A:
  text + embeddings

System B:
  text + embeddings + local textual tags

System C:
  text + embeddings + governed ConceptCode predicates/types

Then deliberately change:

embedding model
prompt model
language
paraphrasing
memory extraction model

Measure:

fact retrieval recall
predicate-level precision
cross-language consistency
conflict detection
supersession detection
false merges
false splits
re-indexing effort
percentage of memories surviving embedding migration without semantic retagging

A particularly strong demonstration would show that an embedding-model migration changes vector neighborhoods while ConceptCode-based memory predicates remain stable—exactly the model-independence Embedded Semantics argues for.

Experiment: event bridge with schema and semantic evolution

Question: Do semantic event identities reduce integration failures between independently evolving producers and consumers?

Create three producers emitting logically related events:

vendorA.thread.archived
vendorB.conversation.lifecycle.changed
corp.records.chat.retained

Give them evolving JSON/Avro schemas managed through a conventional schema registry.

Compare routing with:

Condition A:
  native topic/event strings + manual mapping

Condition B:
  CloudEvents type + schemas

Condition C:
  CloudEvents type + schema registry + ConceptCode semantic type

Introduce controlled failures:

new schema version
new event label
producer rename
close-but-not-exact event meaning
unknown semantic code
old registry cache
deprecated concept
malicious mapping
offline consumer

Measure:

incorrect routing
dropped events
false equivalence
manual mapping changes
time to integrate new producer
schema-related failures
semantic-related failures
recovery behavior
wire bytes
registry lookup latency
cache hit rate

CloudEvents is particularly suitable because it already distinguishes producer-defined event type from dataschema, while schema registries already handle payload evolution. The experiment can therefore isolate the incremental value of a concept registry instead of giving it credit for problems existing standards already solve.

Go/no-go criteria

The prototype should not be judged by whether a registry can be built; that is easy.

It should proceed toward standardization only if experiments demonstrate at least one of the following:

material reduction in cross-agent/tool semantic errors

material reduction in manual cross-system mappings

significantly more stable memory retrieval across model/language changes

safer event evolution across independent producers

meaningful warm-cache token reduction

meaningfully better auditability of why a capability was selected

It should not proceed as a universal protocol layer if the measurable result is merely:

"messages contain nicer identifiers"

The difficult hypothesis is that governed semantic identity changes interoperability outcomes.

Recommended standards strategy

The initial standardization target should be small:

Semantic Capability Profile 0.1

Defines:
  concept identity form
  concept kinds
  registry manifest
  registry digest/signature
  capability signature
  unknown handling
  mapping relationships
  deprecation/supersession
  compact alias binding

Does NOT define:
  transport
  JSON validation
  authentication
  authorization
  full ontology language
  embeddings
  workflow execution

Then publish bindings for:

MCP extension
A2A extension
OpenAPI extensions
AsyncAPI extensions
CloudEvents semantic-type extension
JSON Schema optional vocabulary/sidecar

This would allow the concept layer to succeed even if only some transports adopt it.

The strongest use of the three researched projects would be:

Embedded Semantics
    → governed concept identity,
      multilingual expression resolution,
      abstention,
      provenance

JustAnIota
    → registry-bound compact representation,
      evidence,
      canonicalization,
      human/machine duality

Protocol5
    → experimental expression/concept separation,
      approximation evidence,
      validation boundaries

But none of the public material reviewed yet demonstrates a sufficiently large, independently governed concept ecosystem to establish interoperability value empirically. Embedded Semantics' public registry currently reports zero published concepts; JustAnIota describes IOTA-1 as a draft compact profile; Protocol5 explicitly positions its current IOTA conversion as approximate and evidence-oriented. Those are reasons to prototype, not yet reasons to declare a new universal standard proven.

The strongest final architecture is therefore evolutionary rather than revolutionary:

                        Stable Concept Identity
                                 │
             ┌───────────────────┼────────────────────┐
             │                   │                    │
        capability           event type          memory predicate
             │                   │                    │
          mappings             mappings              │
             │                   │                    │
     ┌───────┴──────┐       ┌────┴─────┐        ┌────┴─────┐
     │              │       │          │        │          │
    MCP            A2A   CloudEvents AsyncAPI  text     embeddings
     │              │       │          │
 JSON Schema     messages  schemas   schemas
     │              │       │          │
 implementations / workflow engines / message buses

The semantic identity layer is valuable because it supplies one thing the surrounding layers do not consistently supply:

A durable, governed answer to “what does this capability, event, state, or memory predicate mean across independently developed systems?”

It should remain deliberately silent on questions that other layers answer better.

Bibliography