Field Interaction Rules: Deterministic Constraints Between Canonical Fields

Mechanism

A field interaction rule is a triple comprising a predicate identifier, a set of participating field selectors, and an outcome specification. The predicate identifier names a deterministic function whose body is fixed at schema authoring time and whose code path is reachable from every conforming runtime. The participating field selectors enumerate the canonical fields whose values are inputs to the predicate; selectors may reference whole fields, named subfields, or specific value paths within structured field contents. The outcome specification declares the action to be taken when the predicate evaluates to false, ranging from refusal of the write, to refusal of the surrounding transition, to refusal of the entire object construction.

Rules are attached to the schema as first-class declarations rather than to individual instances. A schema therefore carries, in addition to its field definitions, an ordered list of interaction rules whose evaluation order is itself part of the schema. Because rules are schema-level, they cannot be added, removed, or reordered by a participant interacting with an instance; any change to the rule set produces a new schema version with a distinct identifier, and instances reference the schema version under which they were validated.

Evaluation occurs at three well-defined moments. First, at object construction, every interaction rule is evaluated against the proposed initial field values, and the construction is refused if any rule returns false. Second, at every field write, the rules whose selectors include the written field are evaluated against the post-write candidate state, and the write is refused if any such rule returns false. Third, at every transition that produces a new object version, the full rule set is evaluated against the candidate post-transition state, and the transition is refused if any rule returns false. Because all three evaluation points operate on candidate states rather than committed states, refusals leave the canonical record unchanged.

Refusal is not a soft signal. A refused interaction produces no observable mutation, no partially applied state, and no recoverable intermediate. The lineage record for the object captures the refusal as an event with the rule identifier, the participating field selectors, and the candidate values that triggered it, but the object's committed state is the state that existed before the attempted interaction. Consumers reading the object after a refusal cannot distinguish, from the committed state alone, that a refusal occurred; they must consult the lineage to observe refusal events. This separation between committed state and event history preserves the determinism of reads while preserving the auditability of attempted writes.

Rule predicates are required to be pure and total. They must produce the same output for the same input, must terminate, and must not consult external state. The schema authoring environment enforces these requirements by restricting the language in which predicates may be expressed: predicates are written against a constrained expression grammar that excludes input/output, unbounded loops, and references to non-field state. This restriction is what makes determinism a structural property rather than a discipline.

Operating Parameters

The operating envelope of field interaction rules is defined by four parameters: the rule cardinality, the predicate complexity bound, the rule-set version identifier, and the refusal scope. Rule cardinality refers to the number of rules attached to a single schema; the architecture imposes no upper bound, but evaluation cost grows linearly with cardinality and authors are encouraged to consolidate rules whose participating field sets overlap heavily. Predicate complexity is bounded by the constrained expression grammar referenced in the mechanism section; the bound is expressed as a maximum evaluation step count derived from the abstract syntax of the predicate, and any predicate exceeding the bound is rejected at schema authoring time.

The rule-set version identifier is a content hash over the ordered list of rules. Two schemas with identical field definitions but differing rule sets receive distinct version identifiers, and the version identifier is part of the schema reference embedded in every conforming instance. This ensures that an instance can always be re-validated against the exact rule set under which it was originally validated, even after the schema has evolved through subsequent versions. Migration between rule-set versions is itself a transition governed by the rule sets of both source and target versions.

Refusal scope is configurable per rule. A rule may declare its refusal scope as "field," meaning that violation refuses only the specific write that triggered it; as "transition," meaning that violation refuses the entire transition of which the write was a part; or as "object," meaning that violation invalidates the candidate object construction in its entirety. The default scope for newly authored rules is "transition," chosen because field-scope refusal can produce surprising partial outcomes when multiple writes occur in a single transition, and object-scope refusal is rarely the intent.

Performance characteristics follow directly from these parameters. Evaluation cost per rule is dominated by the predicate's abstract step count and is independent of the size of unwritten fields. For schemas with rule cardinality below several dozen and predicates within typical complexity bounds, the per-write evaluation overhead is small relative to the cost of the canonical object commit itself. Rule evaluation is parallelizable across rules whose participating field selectors are disjoint, and conforming runtimes are permitted but not required to exploit this parallelism.

Alternative Embodiments

Several alternative embodiments of field interaction rules are contemplated and fall within the scope of this disclosure. In one embodiment, predicates are expressed in a domain-specific expression language whose grammar is fixed and whose evaluator is supplied by the conforming runtime; this is the default embodiment described in the mechanism section. In a second embodiment, predicates are expressed as references to a registry of pre-compiled deterministic functions, with the registry itself being content-addressed and embedded in the schema by hash; this embodiment trades expression flexibility for evaluation speed and is suited to schemas whose rules are drawn from a small, well-known catalog.

In a third embodiment, predicates are expressed as zero-knowledge circuits, allowing a producer to demonstrate that a given write satisfies the rule without revealing the values of fields participating in the rule. This embodiment is useful in federated deployments where the producer and the validator are distinct parties and where the producer is unwilling to disclose participating field values to the validator. The rule-set version identifier in this embodiment is a hash over the circuit definitions rather than over an expression-language source.

In a fourth embodiment, the rule set is partitioned into a mandatory subset evaluated unconditionally and an optional subset evaluated only when an instance opts in by declaring an extended profile. The mandatory subset enforces invariants required for cross-instance interoperation; the optional subset enforces invariants relevant only to specific use cases. Profile declarations are themselves part of the instance's schema reference and cannot be changed after construction.

In a fifth embodiment, refusal events emitted under field-scope or transition-scope refusal are forwarded to a recovery handler whose only authority is to propose an alternative candidate state for re-evaluation. The recovery handler runs under the same constrained expression grammar as the rules themselves and cannot bypass the rule set; it can only suggest a different candidate that may itself satisfy the rules. This embodiment is useful for ergonomic error recovery in interactive applications without weakening the structural guarantee.

Composition With Other Schema Capabilities

Field interaction rules compose cleanly with the other structural capabilities of the agent schema. With canonical field typing, rules operate on values that have already been coerced to their canonical representation, eliminating the need for rules to defend against representational ambiguity. With partial validity declarations, rules may inspect the gap declarations of an instance and skip evaluation for fields whose values are explicitly absent; this allows partially valid instances to satisfy the rule set without being forced to supply placeholder values that would themselves trigger refusals.

With lineage commitment, rule refusal events become part of the cryptographically committed history of the object and cannot be selectively redacted by a participant attempting to obscure prior policy violations. With schema versioning, a rule set evolves through migrations whose own validity is governed by both old and new rule sets, ensuring that no migration can introduce a state that would have been refused under the new rules. With access policy fields, rules may participate in access decisions by treating policy values as inputs to the predicate, allowing policy-dependent invariants to be enforced uniformly across read and write paths.

The composition is associative in the sense that the outcome of evaluating a rule set in the presence of other capabilities is independent of the order in which the capabilities are introduced into the schema. This property is what permits rule sets to be reasoned about locally even when the schema as a whole is large.

Distinction From Prior Art

Conventional approaches to cross-field validation fall into three families. The first family relies on application-level validation code executed by the producer before submission; this approach offers no structural guarantee because the validator and the producer are the same party. The second family relies on database-level constraints such as check constraints and triggers; this approach offers a structural guarantee within the database but loses that guarantee when the data leaves the database, when constraints are altered without coordinated client updates, or when multiple databases are federated.

The third family relies on schema-level type systems such as JSON Schema or XML Schema augmented with cross-field assertions; this approach offers portability of the rules but typically lacks deterministic evaluation semantics, lacks rule-set versioning tied to the instance, lacks refusal semantics that distinguish field, transition, and object scope, and lacks integration with a lineage-committed event record. The capability described here differs from all three families by combining schema-level declaration, deterministic evaluation under a constrained grammar, instance-bound rule-set versioning, scope-aware refusal, and lineage commitment of refusal events into a single structural primitive.

Disclosure Scope

This disclosure encompasses the use of schema-declared, deterministically-evaluated predicates over canonical agent fields whose violation produces a structurally-bounded refusal recorded in lineage; the versioning of such predicate sets by content-addressed identifier embedded in instance schema references; the partitioning of refusal scope into field, transition, and object levels; the partitioning of rule sets into mandatory and profile-gated optional subsets; the expression of predicates in a constrained expression grammar, in a content-addressed function registry, or in zero-knowledge circuit form; and the composition of such rule sets with canonical typing, partial validity, lineage commitment, schema versioning, and access policy capabilities. Variations in predicate language surface syntax, in the precise form of the content-addressed identifier, in the choice of refusal-event encoding, and in the implementation of recovery handlers fall within the scope of this disclosure provided they preserve the structural properties described in the mechanism and operating parameters sections.