Mechanism
A capability envelope is a structured data object that each execution substrate advertises to describe the substrate's current structural characteristics along a plurality of defined dimensions. It is not a permission list, a service catalog, or a self-reported performance benchmark. It is a formal description of the substrate's affordances: the structural properties that determine what forms of execution the substrate can support. The capability envelope exists to answer a categorically different question from the one access control answers. Permission, authorization, and access control each answer whether an operation is allowed; the capability envelope is consumed to determine whether an executable form of an objective can structurally exist on a given substrate.
Capability, as the term is used in the disclosure, is a first-class computational state variable. It is not a metric, a score, a probability, or a heuristic assessment. It is a computed determination, derived from the structural characteristics of the execution substrate, the structural requirements of the objective, and the current state of the execution environment, that resolves to one of a bounded set of determinate outcomes: execution is structurally possible, execution is structurally impossible, execution is structurally deferred, or execution must be rerouted to an alternative substrate. Each of these is a valid computational result; none is an error condition, a timeout, or a default. The capability envelope is the substrate-side object against which this determination is computed.
The Envelope Dimensions
The capability envelope comprises at least the following dimensions. Compute class classifies the substrate's computational architecture, including processor type (general-purpose CPU, graphics processing unit, tensor processing unit, field-programmable gate array, application-specific integrated circuit, neuromorphic processor, quantum processing unit), instruction set architecture, word size, and vectorization characteristics. Memory architecture describes the memory hierarchy, including total addressable memory, memory bandwidth, cache topology, memory coherency model, and support for access patterns such as gather-scatter or atomic operations. Model access describes the inference models, knowledge bases, embedding spaces, and learned representations currently loaded or loadable on the substrate; a substrate that lacks access to a required model cannot produce an executable form of an objective that needs that model, regardless of its computational power or memory capacity.
Locality describes the substrate's physical and network position, including geographic region, data center identity, network topology position, latency characteristics to other substrates, and jurisdictional classification, which determines whether the substrate satisfies positional requirements such as data sovereignty or proximity to a data source or actuator. Execution guarantees describe reliability, availability, and determinism characteristics, including mean time between failures, redundancy configuration, checkpoint-and-restore capability, real-time scheduling support, and deterministic execution mode availability. Sensor and actuator interfaces describe the physical input and output devices accessible through the substrate, including cameras, microphones, LiDAR arrays, force-torque sensors, motor controllers, manipulator arms, locomotion systems, and environmental control interfaces.
Each dimension is represented as a structured descriptor with defined semantics, value ranges, and comparison operators. This structured representation is what enables formal matching between an objective's capability requirements and a substrate's envelope. The system evaluates, for each requirement dimension, whether the substrate's corresponding envelope dimension satisfies the requirement, and the specific unsatisfied dimensions are recorded and propagated to the routing, deferral, and decomposition subsystems rather than collapsed into an undifferentiated failure.
The Envelope Is a Living Object
Capability envelopes are dynamic data objects updated in response to changes in the substrate's structural characteristics. When hardware is provisioned or deprovisioned, when models are loaded or unloaded, when network conditions change, or when other agents consume or release shared substrate resources, the envelope is updated to reflect the substrate's current state. The system does not rely on stale or statically configured capability information; the envelope is a living description of the substrate's present affordances. This distinguishes it from static capability registries, which record manually maintained lists of what each node can do and do not capture the temporal dynamics of capability.
Because the envelope is consulted before any executable process is constructed, the absence of capability is detected at the structural level rather than discovered at runtime through execution failure. The system does not construct an execution plan and then check whether the plan can be executed; it first determines whether any executable form of the objective can exist on the candidate substrate, and only if the capability determination resolves affirmatively does it proceed to execution synthesis. This pre-synthesis ordering is enforced at the architectural level and eliminates the construction of execution plans that cannot be carried out.
Capability Is Not Permission
The disclosure enforces a structural separation between the capability envelope and governance authorization. Capability envelopes and governance policies are maintained in architecturally separate subsystems with no bidirectional dependency: the capability subsystem does not consult governance policies when computing capability determinations, and the governance subsystem does not consult capability envelopes when evaluating permission requests. The two produce independent determinations that are subsequently combined at the execution synthesis gate, where both conditions must be satisfied for synthesis to proceed. This ensures capability evaluation is not contaminated by governance state (a substrate does not become more capable because an agent is highly authorized) and governance evaluation is not contaminated by capability state.
The independence produces four operational quadrants. An agent may be authorized and capable, the standard case in which synthesis proceeds; authorized but not capable, in which no executable form can be constructed and the objective must be routed, deferred, or decomposed; capable but not authorized, in which the system recognizes the structural possibility but withholds synthesis pending governance resolution; or neither authorized nor capable. The authorized-but-not-capable quadrant is the one conventional systems handle poorly, returning a generic error without distinguishing a structural incapability (the substrate lacks the required architecture, and no waiting or retrying will help) from a transient resource shortage (the substrate possesses the architecture but the temporal window during which resources are available has not arrived). The capability envelope makes this distinction explicit.
Capability-Native Computation
The determination of whether execution can occur is itself a first-class computation, not a pre-check or guard clause that precedes the real work. The capability-native computation evaluates the intersection of three structured inputs: the objective's formal requirements, the substrate's capability envelope, and the current temporal-uncertainty state. The system first extracts the objective's capability requirements from the semantic agent's intent field and context block, producing a structured requirements vector; second, it retrieves the candidate substrate's current envelope, ensuring it reflects present state rather than a cached state; third, it performs a dimension-by-dimension comparison between the requirements vector and the envelope.
The per-dimension match result is not binary. Each dimension produces one of three outcomes: satisfied, indicating the substrate meets or exceeds the requirement; unsatisfied, indicating it falls short in a manner that cannot be resolved through deferral or reconfiguration; or conditionally satisfiable, indicating it currently falls short but could be brought into satisfaction through temporal deferral, reconfiguration, or partial decomposition. The conditionally-satisfiable outcome prevents the premature rejection of a substrate that could, with appropriate coordination, satisfy the objective. From the individual results, the aggregate determination is computed under a defined composition rule: all dimensions satisfied yields structurally possible; one or more unsatisfied with no conditional path yields structurally impossible; conditionally satisfiable within a bounded time horizon yields structurally deferred; and unsatisfied here but satisfied on a known alternative yields rerouted.
The Capability Determination Record
The capability-native computation produces a structured capability determination record that is persisted in the agent's lineage and made available to governance infrastructure. The record includes the identity of the evaluated substrate, the capability requirements extracted from the objective, the capability envelope retrieved from the substrate, the per-dimension match results, the aggregate determination, the uncertainty bounds associated with the determination, and, for deferred or rerouted determinations, the forecasted conditions under which the determination may change. This structure ensures capability determinations are auditable, reproducible, and traceable: a governance auditor can examine why a particular objective was routed to a particular substrate, or why execution was deferred rather than immediately attempted, without replaying the original evaluation.
When capability evaluation resolves to a state other than structurally possible, the corresponding non-synthesis condition is itself recorded as a positive determination rather than an error. The non-synthesis record identifies the unsatisfied dimensions, the unmet temporal conditions, the uncertainty conditions that exceeded threshold, and, where determinable, whether non-synthesis is permanent, temporal, conditional, or indeterminate. An agent that receives such a record has received useful information that enables informed rerouting, deferral, decomposition, or objective revision, decisions that are structurally impossible in systems that report non-execution only as an undifferentiated failure.
Envelopes for Embodied and Biological Substrates
The envelope framework extends to embodied and robotic systems whose execution substrates include physical bodies with motor systems, sensor arrays, and environmental interaction surfaces. For such substrates the envelope encompasses not only computational affordances but physical affordances: the degrees of freedom available to the manipulators, the force and torque limits of the actuators, the reach envelope of the arms, the locomotion capabilities of the mobility platform, the sensory modalities available through the sensor suite, and the power budget for sustained operation. A motor objective such as grasping an object or traversing terrain carries physical capability requirements matched against the physical envelope in the same formal manner that computational requirements are matched against a computational envelope. The disclosure distinguishes this envelope from an Operational Design Domain: the ODD defines environmental conditions under which a system is designed to operate, whereas the envelope describes the structural affordances of the substrate itself, independent of environmental conditions.
The framework further extends to human operators in hybrid human-machine systems, where a biological capability envelope describes assessed physical affordances (motor precision, physical endurance, sensory acuity, locomotion capability) and cognitive affordances (domain expertise, cognitive load capacity, reaction time, decision quality under stress). The biological envelope is populated through the biological identity module's signals rather than through credentials or self-reported assessments, and is subject to strict privacy governance: no raw biological data is stored, no biometric templates are retained, and assessments are ephemeral and context-scoped. The same four-quadrant separation applies. A surgeon whose signals indicate fatigue-induced motor imprecision may be governance-authorized to perform a procedure yet biologically incapable at the present moment, in which case the system defers the objective until the operator's envelope recovers or routes it to an alternative operator.
Disclosure Scope
The capability envelope, comprising the structured per-substrate description across the compute class, memory architecture, model access, locality, execution guarantees, and sensor and actuator interface dimensions, its representation as structured descriptors with defined comparison operators, its dynamic update in response to substrate changes, the architectural separation of the envelope from governance authorization, the dimension-by-dimension formal matching producing satisfied, unsatisfied, and conditionally satisfiable results, the aggregate determination resolving to structurally possible, impossible, deferred, or rerouted, the capability determination record persisted to lineage, and the extension of the envelope to embodied robotic and biological substrates, is disclosed in the cognition filing (U.S. Application No. 19/647,395 and its international counterpart) in Chapter 6. This article describes that disclosed mechanism. The scope extends to envelope dimensions not enumerated whose values admit structured comparison against an objective's requirements, and to substrate classes, computational, robotic, and biological, whose affordances are described by such an envelope, provided the envelope is consulted before execution synthesis and held architecturally independent of governance authorization.
