Semantic Router: Schema-Aware Propagation Replacing Address-Based Forwarding

by Nick Clark | Published March 27, 2026 | PDF

The semantic router is a propagation module that decides where a request may travel by comparing the semantic content of the request against the declared capability of each candidate destination. Routing is not performed by matching addresses, ports, or topic strings; it is performed by evaluating whether the request, taken as a typed object with policy references and lineage fields, falls within the bounded semantic distance of a target's published capability schema. Non-matching routes are refused at the substrate. The router is therefore not a forwarder but a structural gate that converts addressability into eligibility, and eligibility into a deterministic, auditable propagation decision.


Mechanism

A propagation event begins when a sending agent emits a request bearing three structural payload regions: a context envelope describing the operation in semantic terms, a policy reference identifying the governing zone and constraint set, and a lineage tail recording prior mutations and the host devices that produced them. The semantic router does not inspect the request as an opaque payload to be relayed. It parses the context envelope into a typed feature vector and compares that vector against the capability descriptors registered for each candidate destination within the routing horizon.

Capability descriptors are themselves schema objects. Each destination publishes the operation classes it accepts, the policy references it honors, the lineage preconditions it requires, and the maximum semantic distance it will tolerate from a canonical exemplar. These descriptors are signed by the destination's identity slope and committed into the substrate's capability registry. The router consults this registry at evaluation time, not at configuration time, so capability changes propagate without redeployment.

The matching step is a bounded semantic comparison. The router computes a distance metric between the request's context vector and each candidate's capability exemplar. The metric is type-aware: fields are compared within their declared types rather than as raw byte strings, and structural fields such as policy references and lineage hashes are compared as graph fragments rather than as scalars. A candidate becomes eligible only if the computed distance falls below the threshold the candidate itself declared in its capability descriptor. The threshold is not a global constant; each destination sets its own admissible radius, and the router enforces the destination's choice.

When more than one destination is eligible, the router applies a deterministic tiebreaker drawn from the substrate's commitment chain: among eligible destinations, the one whose capability descriptor has the smallest declared radius wins, and ties at that level are broken by the lexicographic order of capability descriptor hashes. This produces a unique, reproducible routing outcome for any request and any substrate state, which is the property the audit layer relies upon.

When no destination is eligible, the router refuses the route. Refusal is not a silent drop. The router emits a refusal record that names the request, the candidate set considered, the distances computed, and the thresholds that were exceeded. The refusal record is appended to the requesting agent's lineage tail and to the substrate's commitment chain. This means a refused route is itself an auditable event, indistinguishable in evidentiary weight from an accepted route.

The router never forwards by address. Even when the destination is co-located on the same host, the same evaluation occurs. This eliminates the failure mode in which a node accepts traffic because a stale forwarding rule pointed at it, even though its current capability no longer matches the request. Capability is the only thing the router consults, and capability is always evaluated against the live, signed descriptor.

Operating Parameters

The semantic distance metric is parameterized along three axes: the type-weight vector that scales the contribution of each context field, the structural-weight vector that scales the contribution of each lineage and policy field, and the admissible radius that each destination publishes. Type weights are configured per operation class and are part of the substrate's signed configuration; they are not tunable per-request. Structural weights are derived from the policy reference's declared sensitivity profile. The admissible radius is bounded above by the substrate's maximum-radius constant, which prevents a destination from declaring a permissive infinite-radius capability that would degrade the router into an address forwarder.

Capability descriptors carry a declared validity window expressed in commitment-chain depth rather than wall-clock time. A descriptor remains valid for evaluation until either its successor descriptor is committed or the validity depth elapses. This binds capability lifetime to the same ordering the audit layer uses, which removes the class of failures in which time skew between routers permits a request to be matched against a stale capability on one node and a current one on another.

The router maintains no per-flow state. Each request is evaluated independently against the current capability registry and the current substrate commitment height. There is no flow table, no cached forwarding decision, and no session affinity. The deterministic tiebreaker is sufficient to produce stable routing without flow state, and the absence of flow state eliminates the class of attacks that exploit accumulated forwarding context.

Refusal records are size-bounded. The router records the candidate set, the distance vector, and the threshold vector at fixed precision. This bounds the storage cost of refused traffic at a constant multiple of accepted traffic and prevents an attacker from exhausting audit capacity by issuing requests that are guaranteed to be refused.

Alternative Embodiments

The capability registry may be embodied as a single substrate-wide commitment tree, as a hierarchy of zone-scoped registries that delegate to one another through signed cross-references, or as a fully replicated registry maintained by a quorum of validator nodes. The matching algorithm is independent of the registry topology and operates correctly so long as the registry returns a consistent view of capability descriptors at the substrate height the router observed when the request entered.

The semantic distance metric admits several embodiments. A field-weighted Euclidean form is suitable for scalar context fields. A graph edit distance form is suitable for structural fields. A hybrid form computes per-field distances under the appropriate metric and combines them through a signed aggregation function. The substrate may register multiple metric embodiments and require destinations to declare which they expect; mismatched metric declarations produce a refusal at evaluation time rather than a silent route to an incompatible target.

The router itself may be embodied as a co-resident library invoked by every sending agent, as a dedicated routing process per host, or as a distributed routing service that participating hosts consult through an authenticated channel. In every embodiment the determinism property holds because the inputs to the evaluation, namely the request, the capability registry view, and the substrate height, are the same across embodiments. Two routers operating on the same inputs produce the same routing outcome, which is the property the substrate's correctness proof depends upon.

Capability descriptors may be expressed in a typed schema language native to the substrate, in a declarative policy language imported from an external governance system, or in a hybrid that compiles policy-language statements into the native schema at registration time. The router operates on the native form. Compilation to the native form is performed once at registration and the result is committed; the router never executes policy-language code at evaluation time, which preserves the bounded evaluation cost the substrate guarantees.

Composition With Other Substrate Primitives

The semantic router does not stand alone. It composes with the substrate's identity layer, its lineage layer, and its trust zone overlay. From the identity layer the router consumes the signed capability descriptors and the host mutation tokens that prove a destination is currently executing the host that registered the descriptor. From the lineage layer the router consumes the policy reference and the lineage tail that travel with each request. From the trust zone overlay the router consumes the zone membership of the requesting agent and of each candidate destination, and refuses any route that would cross a zone boundary without a signed cross-zone authorization in the request's policy reference.

The composition is structural, not advisory. The router does not check zone membership only when it remembers to; it cannot evaluate a route at all without consulting the zone overlay because zone membership is part of the capability descriptor. This eliminates the class of bugs in which a routing decision is made under one policy assumption and audited under another. The same descriptor produces both the decision and the audit record.

The router's refusal records compose with the substrate's commitment chain. A refused route advances the chain in the same way an accepted route does, which means the chain records the complete sequence of routing intentions, not merely the subset that succeeded. Investigators can therefore reconstruct what an agent attempted to do, not only what it succeeded in doing, which is the property regulated environments require.

Distinction Over Prior Art

Address-based routers, including IP routers, message-queue topic routers, and service-mesh sidecars that match on header fields, decide forwarding by comparing a request's destination identifier against a forwarding table. They do not consult the semantic content of the request and they do not evaluate whether the destination is currently capable of accepting the operation the request describes. A stale forwarding entry, a misconfigured topic, or a service that has changed its capability without updating its registration produces a route that is syntactically valid but semantically wrong. The semantic router does not have this failure mode because it does not consult a forwarding table.

Content-based routers and publish-subscribe systems that match on payload predicates approach the problem from a closer direction but typically lack three properties the semantic router enforces: bounded semantic distance with per-destination thresholds, signed capability descriptors committed to a substrate chain, and refusal records of equal evidentiary weight to acceptance records. A content-based router that drops non-matching messages silently cannot serve as the audit substrate for a regulated agent system.

Service-discovery systems that match on capability tags resemble the semantic router in intent but operate as advisory lookup rather than as a structural gate. The discovered service is reachable through ordinary address-based forwarding once discovery completes, which means the discovery decision and the forwarding decision can diverge. The semantic router collapses discovery and forwarding into a single evaluation against the live capability registry, which removes the divergence window.

Disclosure Scope

This disclosure is part of the cognition-native execution platform described in US 19/230,933. The semantic router is one of several substrate primitives that together produce the platform's structural guarantees. The disclosure covers the matching algorithm, the capability descriptor format, the bounded distance metric, the refusal record schema, the deterministic tiebreaker, and the composition with the identity, lineage, and trust zone overlay primitives. The disclosure does not cover any single embodiment exclusively; the alternative embodiments enumerated above are presented as variants that fall within the same structural design and the same claim scope.

Implementations that use address-based forwarding as a fallback when capability matching fails fall outside the disclosure. Implementations that omit refusal records, omit signed capability descriptors, or omit the bounded admissible radius likewise fall outside the disclosure because they fail to produce the audit and determinism properties the platform requires. Implementations that retain all of these properties but vary the metric, the registry topology, or the router's process embodiment fall within the disclosure.

Nick Clark Invented by Nick Clark Founding Investors:
Anonymous, Devin Wilkie
72 28 14 36 01