Mechanism
Chapter 6 of the cognition disclosure introduces capability as a first-class computational state variable within the platform architecture. Capability, as the term is used throughout the chapter and the claims, is a structural condition describing whether an executable form of a given objective can exist on a given execution substrate. 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.
Treating capability this way differs from conventional distributed computing, in which capability is assumed, implicitly inferred from resource availability, or conflated with authorization. In a conventional system a task is dispatched to a node and the node either executes it or returns a failure, with the dispatch-time check reduced to resource availability (memory, CPU cycles, bandwidth) or a static, manually maintained capability registry. The disclosure identifies three deficiencies of that approach: resource availability is necessary but insufficient for capability, since a node may have ample memory and compute yet lack the instruction set, accelerator, model weights, sensor array, or physical actuator required to produce an executable form; static registries do not capture the temporal dynamics of capability as hardware is provisioned or deprovisioned and models are loaded or unloaded; and conventional systems treat inability to execute as a failure requiring error handling rather than as a structurally valid result that informs routing, deferral, or decomposition.
Evaluation Before Synthesis
Capability 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. 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 evaluation eliminates an entire class of computational waste, 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.
The determination is conditioned on three jointly evaluated dimensions: the structural capability of the execution substrate, the forecasted temporal window during which execution could occur, and the explicit uncertainty associated with the capability and temporal assessments. These dimensions, capability, time, and uncertainty, are not evaluated independently. They are evaluated as a joint condition that must be simultaneously satisfied for execution synthesis to proceed. A substrate may possess structural capability but lack a temporally viable window; it may possess both yet carry uncertainty, in one or both assessments, that exceeds the threshold at which synthesis is warranted.
Distinction From Permission and Authorization
Capability is structurally and semantically distinct from permission, authorization, and access control, and the distinction is architecturally enforced. Permission, authorization, and access control each answer whether an operation is allowed. Capability answers a categorically different question: whether an operation can structurally exist. The independence produces four operational quadrants the system must recognize. An agent may be authorized and capable, the standard case in which synthesis proceeds. It may be authorized but not capable, in which case no executable form can be constructed and the system must route, defer, or decompose, not because execution is prohibited but because it is structurally impossible. It may be capable but not authorized, in which case the system recognizes the structural possibility of execution but withholds synthesis pending governance resolution. Or it may be neither.
To preserve this independence, 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 determinations, and the governance subsystem does not consult capability envelopes when evaluating permission requests. The two produce independent determinations that are combined at the execution synthesis gate, where both must be satisfied. A substrate does not become more capable because an agent is highly authorized, and an agent does not become more authorized because a substrate is highly capable.
The Capability Envelope
Each execution substrate advertises a capability envelope: a structured data object describing 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 disclosure enumerates dimensions including compute class (processor type, instruction set architecture, word size, vectorization characteristics), memory architecture (addressable memory, bandwidth, cache topology, coherency model, supported access patterns), model access (the inference models, knowledge bases, embedding spaces, and learned representations loaded or loadable on the substrate), locality (geographic region, data center identity, network position, latency characteristics, jurisdictional classification), execution guarantees (reliability, availability, and determinism characteristics), and sensor and actuator interfaces for embodied substrates.
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. Each dimension is represented as a structured descriptor with defined semantics, value ranges, and comparison operators, which enables formal matching between an objective's requirements and a substrate's envelope: a capability match is achieved when every requirement dimension is satisfied, and the specific unsatisfied dimensions of a mismatch are recorded and propagated to the routing, deferral, and decomposition subsystems.
Capability-Native Computation
The system implements capability-native computation, a paradigm in which the determination of whether execution can occur is itself a first-class computation that produces structured, auditable, and governable results. 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 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 extracts the objective's capability requirements from the semantic agent's intent field and context block into a structured requirements vector, retrieves the candidate substrate's current envelope, and performs a dimension-by-dimension comparison.
The match result for each dimension is not binary. Each dimension produces one of three outcomes: satisfied, where the substrate meets or exceeds the requirement; unsatisfied, where it falls short in a manner that cannot be resolved through deferral or reconfiguration; or conditionally satisfiable, where it currently falls short but could be brought into satisfaction through a temporal deferral, a reconfiguration, or a partial decomposition that isolates the unsatisfied dimension to a routable sub-objective. The aggregate determination is composed from the per-dimension results: all dimensions satisfied yields structurally possible; an unsatisfied dimension with no conditional path yields structurally impossible; a conditionally satisfiable dimension within a bounded time horizon yields structurally deferred; and an unsatisfied dimension on the candidate but satisfied on a known alternative yields rerouted. The computation produces a structured capability determination record, persisted in the agent's lineage and available to governance infrastructure, capturing the evaluated substrate, the extracted requirements, the retrieved envelope, the per-dimension results, the aggregate determination, the uncertainty bounds, and, for deferred or rerouted determinations, the forecasted conditions under which the determination may change.
Synthesis and Non-Synthesis as Symmetric Outcomes
Execution synthesis is the process by which the system constructs an executable form of an objective on a substrate, and it occurs only when three conditions are simultaneously met: the capability determination has resolved to structurally possible, or transitioned to it on arrival of the forecasted window; the temporal executability window is currently open; and the aggregate uncertainty is below the configured threshold. When any condition is not met, the result is designated non-synthesis, and non-synthesis is treated as a valid computational result, not an error, a timeout, a failure, or an exceptional condition. It is a positive determination: the system has computed that non-execution is the appropriate result and records, reports, and acts on it with the same rigor and governance it applies to successful synthesis.
This produces an architectural symmetry in which synthesis and non-synthesis are both valid outputs of the capability-native pipeline rather than a desired and an undesired result. An agent that receives a non-synthesis determination 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 error. The non-synthesis record captures the evaluated substrate, the objective, the specific capability dimensions that were unsatisfied or conditionally unsatisfiable, the temporal and uncertainty conditions that were unmet, and, where determinable, whether non-synthesis is permanent, temporal, conditional, or indeterminate.
Composition With Confidence, Discovery, and Lineage
The capability determination feeds directly into the confidence computation, establishing a structural linkage to the confidence governor. Capability sufficiency is one dimension of the agent state input to the confidence evaluation, and when the determination resolves to any state other than structurally possible with full dimension satisfaction and negligible uncertainty, a reduction function computes a confidence decrement proportional to the severity of the insufficiency. A minor gap may reduce confidence to a warning zone; a major gap may reduce it below the authorization threshold, triggering execution suspension. This enables a pre-emptive pattern: the agent may be suspended before it attempts an operation it cannot structurally perform, transitioning to a non-executing cognitive mode in which it can still forecast, plan, inquire, and revise.
Capability also modulates discovery traversal. Certain semantic neighborhoods in the adaptive index require specific computational affordances to evaluate, and when the discovery object encounters a candidate transition into such a neighborhood, the system evaluates whether the current substrate's envelope encompasses the required affordances, excluding, deferring, or decomposing the transition otherwise. Capability compatibility is included as a scoring factor alongside semantic relevance, policy compliance, and affective compatibility, so traversal paths converge on results that are both semantically relevant and computationally evaluable. Every determination, envelope change, and capability genealogy entry is recorded in the agent's lineage as a structured, append-only record subject to the same cryptographic integrity protections that apply to the lineage generally.
Embodied, Biological, and Experiential Extensions
The capability envelope framework extends to embodied and robotic systems whose substrates include physical bodies. There the envelope encompasses physical affordances: the degrees of freedom of 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 of the sensor suite, and the power budget for sustained operation. A motor objective such as grasping an object or traversing terrain carries physical requirements matched against this envelope in the same formal manner as computational requirements. The disclosure distinguishes the capability envelope from an Operational Design Domain: an ODD defines environmental conditions of operation, whereas the envelope describes the structural affordances of the substrate itself, independent of environmental conditions.
The framework further extends to human operators in hybrid systems through a biological capability envelope populated from biological identity signals rather than credentials, and to the agent's own experiential capability evaluated against its identity schema through policy-defined domain gating rules. Experiential capability is structurally independent of substrate capability and governance authorization, producing a three-axis model in which a semantic agent may be substrate-capable, governance-authorized, and yet experientially unqualified for a semantic domain. Rather than a binary permit-or-deny, the experiential evaluation produces a comprehension level, selected from a policy-defined set, that modulates response generation and feeds the composite admissibility determination alongside the affective state, integrity field, confidence assessment, and capability envelope.
Disclosure Scope
The treatment of capability as a first-class computational state variable, the bounded determinate outcomes of structurally possible, structurally impossible, structurally deferred, and rerouted, the architecturally enforced evaluation of capability prior to execution synthesis, the joint evaluation of capability, time, and uncertainty, the distinction of capability from permission and authorization and the four operational quadrants, the dynamic capability envelope and its enumerated dimensions, capability-native computation with its three-valued per-dimension matching and structured determination record, the symmetric treatment of synthesis and non-synthesis, the linkage to confidence and to capability-modulated discovery traversal, and the embodied, biological, and experiential extensions, are disclosed in the cognition filing (U.S. Application No. 19/647,395 and its international counterpart) at Chapter 6. This article describes that disclosed mechanism. The disclosure is independent of the specific substrate, of the specific predicate language used for capability matching, and of the specific physiological or identity-schema attributes used in the biological and experiential extensions.
