Semantic Templates: Predefined Field Arrangements as Agent Class Contracts

by Nick Clark | Published March 27, 2026 | PDF

Agent classes are declared through composable, versioned semantic templates that specify the canonical fields, validation thresholds, fallback behaviors, and mutation permissions every conforming instance must exhibit. Instances that fail to satisfy the template they purport to instantiate are refused entry to the system at the point of construction; non-compliance is not a runtime warning to be logged or a soft constraint to be relaxed under load, it is a structural impossibility. The template is therefore not documentation about what an agent should look like but the contractual surface against which every agent is measured before it is permitted to participate in any cognition or transaction.


Mechanism

A semantic template is a declarative artifact that names an agent class and enumerates the structural commitments membership in that class entails. Each commitment is expressed as a named field, a type or shape constraint over the value the field may hold, and a set of rules describing how the field participates in validation, fallback, and mutation. The template is itself a first-class object: it is addressable, hashable, version-stamped, and signable, which means that any reference to it from an agent instance is a precise reference to a specific revision of a specific contract rather than a loose name that might resolve differently in different environments.

When an agent instance is constructed, the runtime locates the template the instance claims membership in and performs a structural conformance check before any further operation is permitted. The check verifies that every required field is present, that every present field carries a value satisfying the declared shape constraint, that the cryptographic identifier embedded in the instance matches the template hash recorded in its lineage, and that the policies attached to the instance are subsets of those the template authorizes. Any deviation aborts construction and emits a refusal record describing which clause of the contract was violated. The instance never enters circulation; downstream consumers therefore never need to perform the same check defensively because the invariant has already been enforced upstream.

Templates are composable. A template may extend one or more parent templates, inheriting their fields and constraints, and may further restrict but not relax inherited rules. Composition is resolved deterministically: the merged template is itself hashed, recorded, and made addressable so that downstream references see a single canonical artifact rather than a fragile dependency graph. The composition operator preserves the property that every instance carries a precise, verifiable record of which contracts it has agreed to satisfy, regardless of how many layers of inheritance contributed to the final shape.

Validation thresholds, fallback behaviors, and mutation permissions are declared inside the template alongside the field definitions because all four concerns are aspects of the same contract. A field that may be absent under defined conditions has those conditions written into the template; a field that may be revised after construction has the permitted revision pathway and the authorized principals written into the template; a field that participates in confidence scoring has its threshold declared in the template. Behavior that depends on these declarations is therefore deterministic across nodes, since every node consults the same contract artifact rather than relying on local interpretation.

Refusal is the central operational primitive. When an instance, a mutation, or an inbound message fails to conform to the relevant template, the system does not attempt repair, coercion, or best-effort acceptance. It produces a refusal record naming the template, the clause violated, the offending value, and the cryptographic identity of the participant that submitted the artifact. Refusal records are themselves committed to the lineage of the rejecting node so that the population of non-compliant attempts is observable, auditable, and unforgeable. The cost of submitting non-compliant material is therefore borne by the submitter rather than by the network.

Operating Parameters

Templates are versioned with a three-component identifier consisting of a stable class name, a monotonic revision counter, and a content hash over the canonical serialization of the template body. References from agent instances always include all three components, so that ambiguity between revisions is structurally impossible. The revision counter is advisory and the content hash is authoritative; if the two disagree, the runtime treats the artifact as malformed and refuses it.

Field constraints are expressed as a small algebra of shape predicates over primitive types, enumerations, recursive containers, and references to other templates. The algebra is closed under composition and decidable for conformance, which means that conformance checking terminates in time bounded by the size of the instance and the size of the template, with no dependence on global state. Predicates that would require unbounded computation, oracle consultation, or non-local information are not admissible in template definitions.

Validation thresholds attach numeric confidence floors to fields whose values are produced by inference rather than direct assertion. A field declared with a threshold of 0.85, for example, accepts only values accompanied by a confidence annotation at or above that floor; values below the floor cause the field to be treated as absent, which in turn triggers the field's declared fallback rule. Thresholds are properties of the template rather than of the instance, ensuring that the meaning of a confidence-bearing field is fixed by contract rather than by the producer.

Mutation permissions enumerate, for each field, the set of principals authorized to revise the field, the conditions under which revision is permitted, and the lineage record that must accompany the revision. Permissions are expressed as references to capability tokens rather than as identity lists, allowing delegation and revocation to be handled outside the template while keeping the contract itself stable. A mutation that lacks the required token, or whose token has been revoked at a lineage point preceding the mutation, is refused.

Fallback behaviors describe what the system does when a field is absent, fails its threshold, or has been revoked. The catalog of admissible fallbacks is small and closed: substitute a declared default, propagate absence to dependent fields, mark the instance as degraded for downstream consumers, or refuse the operation outright. Each fallback choice is part of the template and therefore part of the audit record, so that the behavior of an agent under partial information is fully predictable from its contract.

Alternative Embodiments

In one embodiment, templates are distributed as signed artifacts in a content-addressable store and resolved by hash at the moment of agent construction. In another, templates are pinned by a governance process that rotates approved revisions and revokes deprecated ones; agents whose templates have been revoked are quarantined rather than destroyed, preserving their lineage for audit while preventing further participation. In a third, templates are negotiated pairwise between counterparties at session establishment, with the negotiated composite template hashed and committed to the session record so that subsequent exchanges have a fixed contractual frame.

The conformance checker may be implemented as a compiled validator generated from the template at publication time, as an interpreted walker that traverses the template and the instance in parallel, or as a zero-knowledge circuit that proves conformance without disclosing the instance contents. The choice affects performance and disclosure properties but not the structural guarantee, since all three implementations accept exactly the same set of conforming instances.

Templates may carry executable predicates expressed in a sandboxed deterministic dialect for cases where shape predicates are insufficient, may delegate predicates to attested external evaluators whose attestations are themselves bound into the lineage, or may compose with policy fragments contributed by domain authorities so that regulatory constraints become structural rather than advisory. In each case, refusal remains the disposition for non-conformance.

Composition with Other Architectural Primitives

Semantic templates compose with the lineage substrate by recording every conformance check, every refusal, and every successful construction as a node in the append-only history. They compose with the cognition pipeline by providing the only admissible interface through which inferred values may enter persistent state, ensuring that inference output is structurally indistinguishable from asserted input once accepted. They compose with the policy layer by serving as the carrier for capability bindings, threshold declarations, and mutation rules, so that policy and structure are expressed in the same artifact and cannot drift apart.

Templates also compose with the federation layer: cross-domain agents are admitted only when their declared template can be resolved to a hash that the local domain has accepted, and the acceptance decision is itself recorded as a lineage event. This provides a structural alternative to identity-based federation, since the question is not who the counterparty is but what contract their artifacts satisfy.

Prior-Art Distinction

Conventional approaches to agent typing rely on external type systems implemented in the host language, runtime configuration files that describe expected shapes, or convention-based interfaces enforced by code review. Each of these approaches places the conformance guarantee outside the artifact itself, with the consequence that an instance can travel without its contract, can be evaluated against a stale or substituted contract, or can pass local checks while violating the contract a remote consumer expects. Schema languages such as JSON Schema, Protocol Buffers, and Avro address shape validation but do not bind validation to a versioned contract artifact that travels with the instance, do not unify shape with mutation permissions and confidence thresholds, and do not refuse non-compliant instances at the structural layer. Type systems in object-oriented languages bind shape to class identity within a process but do not survive serialization, federation, or substrate migration. Capability systems express permissions but do not unify permissions with shape and threshold semantics.

The semantic template construct described here differs in that the template is the contractual surface, the validator, the version anchor, the permission carrier, and the audit reference simultaneously, and the artifact carrying these properties is bound by hash to every instance that claims to satisfy it. Refusal of non-compliant instances is a property of the construction path itself rather than a downstream defensive check.

Disclosure Scope

The structural mechanism described above is disclosed in support of US 19/452,651, "Cognition-Compatible Semantic Agent Objects and Structural Validation." The disclosure encompasses the template artifact format, the conformance checking discipline, the composition operator over templates, the integration of validation thresholds and mutation permissions into the template body, the refusal-as-primitive operational model, and the binding between template hash and instance lineage. Embodiments that vary the distribution mechanism, the validator implementation strategy, or the predicate algebra remain within scope so long as the template is the authoritative contract carried with the instance and refusal is the disposition for non-conformance.

Licensing inquiries and implementation guidance are available through the publication channels referenced above. The disclosure is intended to support both defensive publication and active prosecution, and is offered without warranty as to fitness for any particular deployment.

The disclosure additionally contemplates the operational discipline by which template revisions are introduced, retired, and reconciled across a federation of participants. A revision is introduced by publishing a new template artifact, by signing the new artifact under a key authorized to govern the class, and by recording the introduction event in a lineage that connects the new revision to the prior one. Retirement is symmetric: a deprecation event is recorded against the prior revision and propagated through the lineage so that downstream consumers see the deprecation alongside the artifact rather than as a separate notice. Reconciliation across a federation occurs through pairwise acceptance decisions, each of which is itself a lineage event, so that a participant's history of which revisions it has accepted is observable to its counterparties and cannot be retroactively edited without breaking the chain. This operational envelope is part of the disclosed mechanism because it is what makes the structural guarantees endure across the lifetime of a deployment rather than only at the moment of initial admission.

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