Mechanism
Capability-native computation is the paradigm in which the determination of whether execution can occur is itself a first-class computation that produces a structured, auditable, and governable result. It is not a pre-check, a validation step, or a guard clause that precedes the real computation. It is the real computation in its initial phase: the system computes whether an executable form of the objective can exist on the candidate substrate, and the output of that computation is a structurally valid result rather than a preliminary gate that must be passed before meaningful work begins.
The computation evaluates the intersection of three structured inputs: the objective's formal requirements, the substrate's capability envelope, and the current temporal-uncertainty state. Capability here is a computed determination, not a metric, a score, a probability, or a heuristic assessment. It describes a structural condition: whether an executable form of a given objective can exist on a given execution substrate. The determination resolves to one of a bounded set of determinate outcomes, each a valid computational result and none an error condition, a timeout, or a default.
The Evaluation Sequence
The evaluation proceeds through a defined sequence of steps. First, the system extracts the objective's capability requirements from the semantic agent's intent field and context block, producing a structured requirements vector that specifies, for each capability dimension, the minimum substrate characteristics required for execution. Second, the system retrieves the candidate substrate's current capability envelope, ensuring that the envelope reflects the substrate's present state rather than a cached or historical state. Third, the system performs a dimension-by-dimension comparison between the requirements vector and the capability envelope, producing a match result for each dimension.
The capability envelope against which the requirements vector is matched is a structured description of the substrate's affordances along defined dimensions, including compute class, memory architecture, model access, locality, execution guarantees, and, for embodied substrates, sensor and actuator interfaces. The envelope is a living description of the substrate's present affordances: it is updated 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 computation does not rely on stale or statically configured capability information.
Per-Dimension Match Results
The match result for each dimension is not binary. Each dimension produces one of three outcomes. A dimension is satisfied when the substrate's capability meets or exceeds the requirement. A dimension is unsatisfied when the substrate's capability falls short of the requirement in a manner that cannot be resolved through temporal deferral or reconfiguration. A dimension is conditionally satisfiable when the substrate's capability currently falls short but could be brought into satisfaction through a temporal deferral, in which the required resource will become available at a forecasted future time, through a reconfiguration of the substrate, or through a partial decomposition that isolates the unsatisfied dimension to a sub-objective routable to a different substrate.
The conditionally satisfiable outcome prevents the premature rejection of a substrate that could, with appropriate coordination, satisfy the objective's requirements. The specific unsatisfied or conditionally satisfiable dimensions are recorded and propagated to the routing, deferral, and decomposition subsystems, so the system can make informed decisions about where to route the objective or how to decompose it into sub-objectives that can be individually matched to available substrates.
The Aggregate Determination
The aggregate capability determination is computed from the individual dimension match results according to a defined composition rule, and resolves to one of four determinate outcomes. If all dimensions are satisfied, the aggregate determination is structurally possible. If one or more dimensions are unsatisfied and no conditional path exists, the determination is structurally impossible. If one or more dimensions are conditionally satisfiable and the conditions can be evaluated within a bounded time horizon, the determination is structurally deferred: execution cannot occur now but may occur within a forecasted temporal window. If one or more dimensions are unsatisfied on the candidate substrate but satisfied on an alternative substrate known to the system, the determination is rerouted: execution is possible but must occur on a different substrate.
Each of these four outcomes is a valid computational result. The treatment of the inability to execute as a structurally valid outcome rather than as a failure requiring error handling, retry logic, or escalation is what distinguishes this paradigm from conventional approaches, in which a task is dispatched to a node and the node either executes the task or returns a failure. Here the determination that no executable form can exist is computed, recorded, and acted upon with the same rigor applied to a determination that execution is possible.
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 structured record ensures that 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, by inspecting the recorded inputs and the per-dimension match results that produced the aggregate determination.
Pre-Synthesis Ordering
Capability-native computation occupies a designated computational position that is evaluated prior to the construction of any executable process, and this ordering is enforced at the architectural level. The system does not construct an execution plan and then check whether the plan can be executed. The system first determines whether any executable form of the objective can exist on the candidate substrate, and only if the capability determination resolves affirmatively does the system proceed to execution synthesis.
This pre-synthesis evaluation eliminates an entire class of computational waste, namely the construction of execution plans that cannot be carried out, and ensures that the absence of capability is detected and handled at the structural level rather than discovered at runtime through execution failure. Because capability is evaluated before synthesis, the resulting capability state can also feed the agent's confidence computation, so that an agent may be suspended from execution before it attempts an operation it cannot structurally perform.
Capability Distinguished from Permission
Capability as computed here is structurally and semantically distinct from permission, authorization, and access control. Permission, authorization, and access control each answer the question of whether an operation is allowed. Capability answers a categorically different question: whether an operation can structurally exist. The two are maintained in architecturally separate subsystems with no bidirectional dependency. The capability envelope subsystem does not consult governance policies when computing capability determinations, and the governance subsystem does not consult capability envelopes when evaluating permission requests.
This separation produces the operational quadrant in which an agent is authorized but not capable: the agent has permission to execute, but the substrate lacks the structural characteristics required. Here no executable form can be constructed, and the system routes, defers, or decomposes the objective, not because execution is prohibited but because execution is structurally impossible. The capability-native computation distinguishes a structural incapability, which no amount of waiting or retrying will resolve, from a transient resource shortage, which is a temporal condition, and routes accordingly rather than retrying on a structurally incapable substrate.
Disclosure Scope
Capability-native computation, comprising the evaluation of the intersection of the objective's formal requirements, the substrate's capability envelope, and the current temporal-uncertainty state; the defined sequence of requirements extraction, current-envelope retrieval, and dimension-by-dimension comparison; the per-dimension satisfied, unsatisfied, and conditionally satisfiable match results; the aggregate determination resolving to structurally possible, structurally impossible, structurally deferred, or rerouted; the structured capability determination record persisted in the agent's lineage; the pre-synthesis ordering of the computation; and the architectural separation of capability from permission, authorization, and access control, is disclosed in the cognition filing (U.S. Application No. 19/647,395 and its international counterpart) at Section 6.4. This article describes that disclosed mechanism. The scope extends to capability envelopes whose dimensions differ from those enumerated and to substrate classes not enumerated, provided the determination of whether an executable form of the objective can exist is computed as a first-class result prior to execution synthesis and resolves to one of the bounded determinate outcomes.
