Multi-Class Operator Parameterization

by Nick Clark | Published April 25, 2026 | PDF

Marker-track route parameters are not specified as a flat schema applied uniformly to every operating environment. Provisional Application 64/049,409 specifies a multi-class schema in which route parameters are serialized under one of a defined set of operating classes, and each class admits class-specific tolerances and class-specific cross-validation rules. The disclosure identifies four canonical classes: Class A, linear roadway; Class B, branching road network; Class C, enclosed campus; and Class D, maritime. Each class corresponds to a topology and a regulatory environment that demands its own consistency rules, its own permissible parameter ranges, and its own validation logic. The architecture parameterizes across classes through schema selection, not through per-class re-implementation, so that a single marker-track agent can interoperate across classes by switching the class binding at the segment boundary.


Mechanism

A marker-track segment carries a serialized payload that authorizes a vehicle to traverse the segment under specified parameters. The payload is structured under a class-tagged schema. The class tag selects the schema variant that governs the remainder of the payload's interpretation. Without the class tag, the remainder of the payload has no defined interpretation; the schema is not a flat record onto which class-specific extensions are bolted.

Class A, linear roadway, is the topology of an arterial or freeway. Parameters under Class A include longitudinal speed envelope, lateral position tolerance referenced to a single guidance line, headway minima, and merge/diverge authorization at named ramps. Cross-validation under Class A is dominated by longitudinal coherence: successive segments must agree on speed at their shared boundary within a tolerance, and lateral references must compose into a continuous guidance line.

Class B, branching road network, is the topology of a road graph in which multiple downstream segments succeed each segment. Parameters under Class B include the set of admissible successor segments, turn authorizations, intersection-entry conditions, and right-of-way binding to other classes operating in the same junction. Cross-validation under Class B is dominated by graph consistency: successor sets must be reachable, turn authorizations must compose with intersection geometry, and right-of-way bindings must be reciprocal across the participating segments.

Class C, enclosed campus, is the topology of a private operating environment such as a port terminal, an industrial yard, a warehouse interior, or a controlled depot. Parameters under Class C include zone-entry preconditions, dwell-time bounds, interaction protocols with fixed equipment, and interlock states. Cross-validation under Class C is dominated by interlock coherence: zone occupancies must not contradict, equipment-interaction states must compose with vehicle state, and dwell bounds must compose with downstream zone availability.

Class D, maritime, is the topology of an open or constrained waterway. Parameters under Class D include track corridor with three-dimensional tolerance, current and tide compensation envelopes, separation minima referenced to other vessel classes, and authorization to cross designated lanes. Cross-validation under Class D is dominated by environmental composition: corridors must compose with tidal windows, separation minima must compose with vessel-class declarations on adjacent corridors, and crossing authorizations must compose with lane-traffic schedules.

Class binding is performed at the segment boundary by the issuing authority and is verified at admission by the consuming agent. The agent does not infer class from payload contents; it reads the class tag, selects the corresponding schema, and validates the remainder against that schema. Mismatch between class tag and payload structure is a hard rejection.

Operating Parameters

Each class declares a tolerance vector specifying the permissible deviation between the agent's executed trajectory and the parameters serialized in the segment payload. Class A tolerances are dominated by longitudinal and small lateral terms; Class B tolerances additionally include graph-position terms; Class C tolerances are dominated by zone-occupancy and interlock-state terms; Class D tolerances are dominated by three-dimensional position and current-compensation terms. The tolerance vector is part of the schema, not external to it.

Each class declares a cross-validation rule set specifying which composition checks must succeed for adjacent segments to be admitted as a coherent route. The rule sets are class-specific because the topologies are class-specific; a longitudinal-coherence rule appropriate for Class A is meaningless under Class C, and an interlock-coherence rule appropriate for Class C is meaningless under Class A.

Each class declares an admission-precondition set specifying the agent state required before the segment is consumed. Preconditions include sensor-mode requirements, prior-segment-completion requirements, and external-authority acknowledgment requirements. Preconditions are evaluated against agent telemetry at admission and constitute a hard gate.

Each class declares a fault-handling regime specifying agent behavior when a tolerance is exceeded or a cross-validation rule fails mid-segment. Regimes range from in-place hold to controlled exit to handoff-to-alternate-class, and the regime is selected as part of the segment authorization rather than as a global agent setting.

The schema versioning parameter is class-scoped. A Class A schema may evolve independently of a Class C schema, and an agent may carry multiple schema versions simultaneously to interoperate with authorities that have not yet upgraded. Versioning is part of the class binding so that schema evolution does not require coordinated cutover across classes.

Alternative Embodiments

In one embodiment, classes are extended beyond the four canonical classes to address specialized topologies: subterranean (mining, tunneling), aerial low-altitude (drone corridors), and amphibious (transitions between Class A and Class D). Each extended class follows the same multi-class discipline: it declares a schema, a tolerance vector, a cross-validation rule set, an admission-precondition set, and a fault-handling regime.

In another embodiment, the class tag is hierarchical. A Class B segment may be sub-tagged as urban-arterial or as roundabout, with sub-tags inheriting the Class B base schema and adding sub-class-specific terms. The hierarchy is bounded to two levels in the canonical disclosure but is extensible.

In a third embodiment, a single physical environment is dual-classed. A maritime channel approaching a port may be authorized concurrently under Class D for the open-water portion and Class C for the terminal-approach portion, with the transition itself a recorded class-change event subject to its own admission rules.

In a fourth embodiment, the cross-validation rule set is supplied not by the schema but by a policy module bound at deployment, with the schema constraining the input and output types of the rule set. This permits jurisdictions to extend cross-validation without modifying the on-the-wire payload format.

In a fifth embodiment, the agent operates in observe-only mode under a class for which it does not hold execution authorization, accumulating telemetry against the schema for later validation against an authoritative reference. This embodiment supports certification of new agents into existing class regimes without granting them operational authority during certification.

Composition

A serialized segment payload comprises: a class tag from the defined enumeration; a schema-version tag scoped to the class; the parameter record encoded under the class schema; the tolerance vector instance for the segment; the cross-validation rule references that bind the segment to its predecessors and successors; the admission-precondition set; the fault-handling regime selection; an issuing-authority signature; and a payload integrity hash. The payload is self-describing under its class tag and self-validating under its signature.

A class schema, in turn, comprises: the parameter-field type definitions; the tolerance-vector field type definition; the cross-validation rule type catalog; the admission-precondition type catalog; the fault-handling regime enumeration; and the schema-version identifier. The schema is a published artifact addressable by class and version, permitting agents and authorities to negotiate compatible versions before route exchange.

The signature on each segment payload binds the issuing authority to the class tag as well as to the parameter record. An authority that is not credentialed to issue a given class cannot produce a payload that admits under that class, even if the parameter record itself would otherwise be well-formed. This binding prevents authorities from issuing across classes outside their scope and is enforced at admission rather than only at audit.

A composed route comprises: an ordered sequence of segment payloads; a route-level class trace recording the class of each segment; a class-change event log for transitions between classes within the route; and route-level integrity metadata binding the sequence as a whole. The route is admissible only when each segment is admissible under its class and each class-change event is admissible under the transition rules of the participating classes.

Prior-Art Posture

Flat route-parameter schemas in existing AV and ITS infrastructures encode a single set of parameters across all operating environments, with environment-specific behavior implemented in the consuming agent's logic rather than in the schema. The present mechanism moves environment classification into the schema itself, making the agent's interpretation of a payload class-determined rather than logic-determined.

Per-class re-implementation, in which a separate stack is built per vehicle or environment class, is the dominant pattern in current commercial deployment. The present mechanism inverts this pattern: a single architectural mechanism handles all classes, with class-specific behavior expressed as schema variation rather than as code variation.

Geo-fenced operating-design-domain definitions in current AV practice describe regions in which a system is authorized to operate, but do not provide a structured cross-validation discipline across region boundaries. The present mechanism provides explicit class-change events and cross-validation rules at boundaries.

Generic policy engines that bind environment-specific rules at runtime address a related concern but operate on a flat schema with environment as one of many fields. The present mechanism elevates environment to the schema-selection level, so that the rules that apply, the tolerances that are admissible, and the validations that are required are all determined before policy evaluation begins rather than as part of it. This is structurally different from environment-as-input policy engines because it forecloses cross-environment misinterpretation at the parser, not at the engine.

Maritime e-navigation standards and road-network HD-map standards each encode their respective domains under domain-specific schemas, but they do not interoperate. The present mechanism encompasses both as classes within a single multi-class architecture, supporting agents that operate across the domains and routes that cross between them.

Disclosure Scope

The disclosure encompasses: the multi-class schema discipline and its enumeration of canonical classes A through D; the class-tag selection mechanism and its hard-rejection semantics on mismatch; the tolerance-vector, cross-validation-rule, admission-precondition, and fault-handling components of each class schema; the class-change event and its admission rules; the schema-versioning regime scoped per class; and the alternative embodiments enumerated above, including hierarchical sub-classes, dual-classed environments, externalized rule sets, and observe-only operation. The disclosure expressly contemplates method, system, and computer-readable-medium formulations, dependent claims directed to specific class enumerations and specific cross-validation rule families, and dependent claims directed to class-change events between specified class pairs. Claim scope is reserved across the canonical classes and across reasonable extensions thereof consistent with the disclosed multi-class discipline.

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