Embodied Capability Envelopes

Mechanism

The embodied capability envelope is constructed at agent initialization from three structured sources: the kinematic and dynamic specification of the platform (link lengths, joint ranges, peak torques, accelerations, payload limits), the sensor manifest (modality, field of view, range, refresh rate, occlusion model, calibration confidence), and the actuator manifest (class, latency, repeatability, end-effector tooling, contact force budget). These sources are resolved into a single canonical record, the envelope object, which carries a stable identifier, a version, and a hash over its constituent fields. The hash is what permits downstream stages to cite the envelope they evaluated against, so a recorded decision can later be replayed against the exact envelope state that produced it.

During task evaluation the planner does not query controllers or attempt motion to test feasibility. It performs a structural match: the task's required capability tuple, drawn from the canonical fields of the task descriptor, is compared dimension by dimension against the envelope. Reach is checked against the planned workspace volume; sensor coverage is checked against the set of poses the task requires the agent to perceive; actuator class is checked against the operations the task names. Each dimension yields an independent verdict, and the verdicts are combined under a policy-defined rule that may require unanimity, a weighted majority, or domain-specific exemptions for graceful degradation. The result is a feasibility record that names the envelope version, the task version, and the per-dimension outcomes.

The envelope is a live object. Self-test routines, calibration drift detection, and reported faults from low-level controllers update specific fields and bump the envelope version. The cognitive layer subscribes to these changes, so any plan that was admitted under an earlier envelope version is automatically marked for re-evaluation when the envelope it cited is no longer current. This subscription is structural rather than heuristic: there is no rule that says "rebuild plans when something feels wrong," there is a deterministic invalidation triggered by a hash mismatch.

A consequence of this design is that the envelope object becomes the single point of contact between the cognitive layer and the substrate. The planner never speaks directly to a joint, a controller, or a sensor driver; it speaks to the envelope, and the envelope is constructed from those lower-level sources by a declared assembly procedure. Replacing a sensor with a higher-resolution unit, swapping an end-effector tool, or recalibrating a payload limit changes the assembly inputs, regenerates the envelope, increments its version, and propagates through the cognitive layer without any code change above the envelope boundary. This separation is what permits a single cognitive policy to be reused across hardware generations and across mixed fleets in which different agents present envelopes with the same schema but different field values.

The envelope is also a privacy boundary. Internal hardware details that an operator considers sensitive, such as exact torque curves or proprietary sensor calibration data, do not need to leave the envelope-assembly stage. The cognitive layer consults the canonical envelope fields, not the underlying source data, so the same envelope can be exposed to internal planners with full fidelity and to external counterparties with reduced projections, without changing the planner's interface to it.

Operating Parameters

Several parameters govern envelope behavior. The granularity parameter controls how finely each dimension is decomposed; a coarse setting may treat reach as a single scalar maximum, while a fine setting represents reach as a discretized workspace map with per-cell payload limits. The confidence parameter attaches a calibrated uncertainty to each field, so a sensor whose calibration is two weeks stale is admitted with a wider error bar than one calibrated this morning. The conservativeness parameter shrinks declared limits relative to nominal hardware specifications, providing a margin between what the envelope claims and what the substrate can actually deliver; this margin is the engineering knob that trades throughput against safety.

The refresh policy governs when the envelope is recomputed. Some fields, such as link length, are static for the lifetime of the platform. Others, such as battery-bounded payload or thermally-bounded duty cycle, change continuously and are recomputed on a fixed cadence. A third class, such as end-effector tool identity, changes on discrete events and triggers an immediate version bump. The policy reference declares which class each field belongs to, removing implicit timing assumptions from the cognitive layer.

A scope parameter determines whether the envelope describes the agent in isolation or the agent in its current cell, including known fixtures, known co-workers, and known obstacles. Cell-scoped envelopes are richer but invalidate more often; agent-scoped envelopes are stabler but require a separate environmental model to be combined with them at planning time. Both modes are supported under the same structural schema.

The combination rule, finally, governs how dimensional verdicts aggregate into an overall feasibility determination. Unanimity is the strict default; weighted majority is admitted for non-safety dimensions; domain-specific exemptions may permit graceful degradation by allowing a plan to proceed with reduced performance when only soft dimensions are violated. The combination rule is declared in policy and is itself versioned, so a deployment cannot quietly relax safety semantics by changing aggregation behavior without leaving an auditable record.

Alternative Embodiments

The same envelope construct applies to non-robotic embodiments. A software agent's envelope includes the set of tool integrations it is provisioned for, the rate limits and quotas attached to each integration, the credential scopes it currently holds, and the latency budget of the runtime it is hosted in. A medical-device agent's envelope includes the set of sterile-field operations its current configuration permits, the consumables present, and the expiry of each consumable. A vehicle agent's envelope includes road-class certifications, weather tolerances, and currently functional sensor redundancy.

Envelopes can be hierarchical. A multi-arm platform may publish a top-level envelope covering whole-body reach plus per-arm sub-envelopes, and the planner may choose to evaluate against either depending on whether the task is whole-body or arm-local. They can also be composite: a mobile manipulator combines a base envelope with an arm envelope, and the composite is recomputed whenever the base reports a new pose. Composite envelopes carry the version hashes of their constituents, so invalidation propagates correctly without ad hoc plumbing.

Envelopes can be projected. A query-time projection exposes only the dimensions a counterparty is authorized to see, supporting privacy and competitive constraints in shared workspaces. A second agent does not need the full kinematic specification of a peer to coordinate with it; it needs the projected reach and the projected sensor coverage in the shared cell.

Envelopes can be conditioned. A conditional envelope describes what the agent could do if a specified precondition were satisfied, such as a tool change, a recalibration, or a battery exchange. Conditional envelopes are useful in planning long missions because they let the planner reason about the cost-benefit of preconditioning operations without first executing them. The conditional form preserves the same schema and version-hash discipline as the base envelope; the only addition is a precondition reference whose state determines whether the conditional envelope is currently realized.

Envelopes can be heterogeneous across modalities that traditional capability descriptions struggle to express. A surgical agent's envelope can include the set of tissue interactions its current configuration is certified for; a logistics agent's envelope can include the set of package classes it is rated to handle, with class-specific reach and force limits. The schema is dimensional rather than prescriptive: any operator-meaningful capability axis can be added to the envelope so long as it is given a name, a type, a refresh policy, and an evaluation rule.

Composition with Other Mechanisms

Embodied envelopes compose with envelope negotiation: when two agents' envelopes overlap in workspace or in shared resource, the negotiation protocol uses the named envelope versions as the basis for assigning scope. They compose with temporal forecasting: the forecaster takes the current envelope and a planned action sequence and produces a predicted envelope trajectory, which the planner can check against the task before committing. They compose with the lineage system: every plan, decision, and outcome record cites the envelope hash it relied on, so post-hoc analysis can distinguish failures caused by an inaccurate envelope from failures caused by a correct envelope and a misjudged plan.

The envelope is also the natural integration point for safety cases. Regulators reviewing a deployment can examine the envelope schema, the policy that governs its construction, and the audit log of envelope versions encountered in the field. Demonstrating that the agent never executed outside its declared envelope becomes a structural property checkable in the lineage rather than an empirical claim defended by test reports alone.

Distinction from Prior Art

Conventional robotic stacks treat capability implicitly. Reach is encoded in a URDF, payload in a controller parameter, sensor coverage in a perception module, and feasibility is discovered by attempting motion and observing failure or by running a planner that internally consults these scattered representations. Authorization systems sit on top and grant permission to attempt operations, conflating the right to act with the ability to act. Failures emerge as runtime exceptions, motor stalls, or unsafe contact, and post-mortem analysis has to reconstruct what the system believed it could do at the moment of failure.

The embodied envelope mechanism is structurally different. The envelope is a named, versioned, hashed object that exists prior to any plan and is consulted before any commitment. Feasibility is a structural verdict, not a behavioral observation. Authorization is a separate axis applied to feasible plans, and the two cannot silently merge. The envelope is auditable end to end because it is declared rather than emergent.

Digital twins, capability registries, and asset-management systems hold related information but operate out of band, consulted by humans during deployment planning rather than by agents at decision time. The envelope is not a registry entry; it is a live, hashed input to the cognitive evaluation loop, and its structural participation in commitment is what distinguishes it from offline catalogs. A registry can describe what a robot is in principle; only an envelope describes what this robot, in this configuration, with this calibration state, can be relied upon to do in the next planning step, and only an envelope can be cited by the lineage record of the decision that relied on it.

Disclosure Scope

This article discloses the construction, parameterization, refresh policy, and composition properties of embodied capability envelopes as defined in Chapter 6 of the cognition patent. The disclosure covers single-agent, hierarchical, composite, and projected envelopes, and identifies the integration points with negotiation, forecasting, and lineage. Specific numerical thresholds, tuning curves, and platform-specific calibration procedures are reserved for licensee implementation guidance and are not part of this public disclosure.