Part one · Constraint

The body changes the transition system

A controller does not act directly on the world. It sends a motor command into a body whose geometry, inertia, elasticity, friction, joint limits, actuator lag and wear transform that command. The body then contacts an environment that has its own dynamics. A useful minimal model keeps those transformations visible:

Here q is body state, such as joint angle, deformation or temperature. x is environment state. a is the controller's command. F_B is the body's command-to-motion transformation, parameterised by theta_B. F_E is the environment transition after contact. H_B is the body-specific observation process, including sensor placement and the consequences of earlier action. Finally, pi is the controller, with parameters theta_C.

If limb length changes, F_B changes even when a is numerically identical. If a tactile pad moves, H_B changes even when its data type remains a floating-point array. If the ground becomes soft, the composition F_E(F_B(...)) changes. This is why “same observation space and same action space” is a weak statement. Two systems may expose arrays of the same shape while implementing different causal maps.

The same point applies to apparently high-level commands. A Cartesian pose target looks body-neutral, but an inverse-kinematics solver must still decide whether that pose is reachable, which joints to move, how close the motion passes to singularity and what torque appears on contact. A semantic grasp primitive looks even more neutral, yet its reliability depends on the low-level controller and hardware that interpret it. Abstraction can relocate embodiment. It cannot guarantee that embodiment has vanished.

This gives a practical test for system boundaries. Ask where uncertainty first becomes physical consequence. If a component promises a verified postcondition, such as “the object is held within a measured force band”, downstream reasoning may treat that postcondition semantically. If it merely accepts a command and returns an acknowledgement, the body and outcome observer remain part of the decision mechanism. An accepted action is not the same as an achieved state.

Constraint is both loss and leverage

“Constraint” can sound purely restrictive. In control, a good constraint often removes dangerous or wasteful possibilities before a controller must search over them. A knee that flexes in one direction, a compliant tendon that stores energy, a rounded shell that redirects collisions and a gripper finger that conforms to uncertain shape all bias the system towards some trajectories and away from others.

Imagine two simulated creatures with identical controllers and the same total actuator power. Creature A has four stiff telescoping rods. Creature B has joint limits and spring-like legs tuned near the cadence of the task. On a flat treadmill, enough optimisation may make both move. Add delayed control, a brief sensor outage and uneven ground. B may continue because its passive dynamics keep motion inside a recoverable basin. A requires the controller to recreate stability at every step.

The important quantity is not “how much intelligence is in the body”. It is the shape of the reachable set under bounded time, energy and error. A body can widen the set of safe states while narrowing the set of arbitrary states. That trade can be valuable. It can also be disastrous when the environment changes. A spring tuned for one cadence may resonate badly at another. A hand that self-aligns cylindrical objects may fail on a bulky shape that cannot settle into its grasp.

A minimal worked example makes the distinction concrete. Suppose a controller must keep a mass near the centre of a shallow bowl while the platform is disturbed. A bowl-shaped body provides a restoring force: displacement creates a slope that drives the mass back. A flat platform provides no such correction. The first controller can be simple because the mechanics already encode a useful tendency. The second controller must sense displacement and command compensation quickly. If the goal changes from “return to centre” to “hold any requested off-centre position”, the bowl becomes an obstacle. A morphology is intelligent only relative to a task distribution and environment.

This is also why body design and controller design cannot always be optimised independently. Work on co-optimising morphology and control finds that a morphological change can temporarily reduce performance because the existing controller was adapted to the previous body. Giving control time to readapt can allow useful morphological innovations to survive selection.[12] The practical lesson is modest: do not reject a body change only because the old controller performs poorly on it, and do not accept it only because a freshly trained controller performs well. Measure the interaction and the adaptation cost.

Energy offers another discriminating measure. A controller can force an ill-matched body through a desired trajectory by spending more power and correcting more often. If evaluation reports only task completion, that design may appear equivalent to a body whose natural dynamics support the motion. Add energy, peak actuator load, disturbance recovery and thermal margin, and the equivalence can disappear. Conversely, a passive mechanism that is efficient on one slope may fail to initiate, stop or turn. The baseline must therefore include the full mission, not only the movement that flatters the morphology.

Constraint also changes learning. A body that excludes unstable actions can reduce the effective search space, but it may deprive a learner of behaviours needed later. A broad, actuated body can support more tasks while demanding more data and stronger safety controls. The design question is not whether to maximise freedom or constraint. It is where to place structure so that the remaining learning problem is tractable without prematurely removing useful options.

Part two · Sensorium

flowchart LR
  A["One command, three different acts"] --> B["The body changes the<br/>transition system"]
  B --> C["The body determines what can<br/>become evidence"]
  C --> D["A skill belongs to a coupling,<br/>not to weights alone"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#087A98,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

The body determines what can become evidence

A sensor is not merely a device that turns a pre-existing world into data. Its location, orientation, bandwidth, contact surface and relation to possible movement determine what differences it can expose. A fixed camera and a camera on a movable wrist may share resolution and optics, yet the second system can change viewpoint, create parallax, reveal an occluded edge and test whether a surface moves with the object. The action is part of the measurement.

Ruzena Bajcsy's account of active perception framed sensing as a controlled acquisition process rather than passive receipt.[6] Interactive-perception research makes the mechanism explicit: acting on the environment can create sensory signals that would otherwise not exist, while regularities across action and observation make those signals interpretable.[7] A poke is not just motion followed by vision. It is an intervention that distinguishes “attached”, “free”, “soft”, “slippery” and “blocked” through consequence.

Thought experiment: equal cameras, unequal experiments

Put identical cameras in two boxes facing a cluttered shelf. Box A is bolted down. Box B can move ten centimetres sideways and has a finger that can nudge one object by two millimetres. Both receive the same initial pixels. From that frame alone, a dark boundary might be a gap, a painted line or the edge of an occluded object. A sideways move changes the parallax pattern. A nudge tests whether the boundary moves with the object. Box B does not start with more visual data. It has a larger set of possible experiments.

Now hold movement fixed and change only sensor placement. Move a tactile sensor from the fingertip to the palm. The data type remains “force”. The same contact produces a different signal, at a different time, with a different relation to imminent slip. Sensor geometry changes the observation function H_B. A policy trained with one placement may interpret the other as a new world even when the object and task are unchanged.

A sensorium is therefore the set of distinctions an embodied system can reliably produce under its available actions. That definition includes ordinary exteroception, such as vision and audio, but also proprioception, motor current, strain, temperature, contact and the absence of expected consequence. It also includes the policy for selecting measurements. A robot with a perfect force sensor that never makes contact has no force evidence. A system that can contact safely but lacks a timestamped action record cannot interpret the signal as a controlled intervention.

This changes data design. A dataset of frames and labels omits the counterfactual structure that active sensing uses: what action was taken, which signal followed, what would have happened under another action and which body generated it. For embodied learning, observation tokens without body state and action history can hide the variables that made the observation meaningful. “More multimodal data” is not a substitute for the right intervention record.

It also changes what counts as observability. A state may be unobservable from any single snapshot but recoverable from a controlled sequence. Surface compliance, for example, may be inferred from force and displacement during a small press. Object attachment may be inferred from whether it follows a known nudge. The controller must know the probe, its timing and the body's own compliance before interpreting the response. Otherwise self-motion and world-motion are confounded.

Calibration is therefore part of the sensorium rather than clerical preparation. A worn fingertip, a shifted camera or a changed payload alters the relationship between world state and observation. A model may continue receiving tensors of the expected shape while the evidence they encode has changed. For consequential action, calibration state should be available to the policy or enforced by a deterministic release gate. When calibration expires, the system should reduce authority, gather a safe reference measurement or abstain.

Part three · Skill

A skill belongs to a coupling, not to weights alone

Suppose a policy performs well on a robot hand. Where is the skill? It is tempting to answer “in the policy parameters”. Yet the behaviour appears only when those parameters run through a particular observation map, actuator transfer function, body and environment. A compact performance statement is:

J is task performance. pi is the controller, B the body and sensorium, and E the environment. The notation matters because J is generally not separable into one policy score plus one body score. A policy may be excellent with body A and poor with body B. Another policy may reverse the ordering. That interaction is not nuisance variance. It is evidence that part of the effective skill is relational.

Relational skill does not mean that nothing transferable exists. A policy may contain a body-independent representation of “place the cup upright”, while a lower layer realises that intention through particular joints and contacts. The experimental task is to separate shared task structure from body-specific execution. Policy transplant, representation probing and rapid adaptation answer different questions. A failed zero-shot transplant may coexist with strong transfer after a small amount of body data.

The interaction also creates hidden state. Material fatigue, joint temperature, battery voltage and payload can move the same nominal body through different dynamics. A controller that infers these variables from recent history may appear to have learned a single robust skill. More exactly, it has learned to identify a changing body online and select an appropriate control regime. That is a valuable capability, but its safety depends on whether identification occurs before an irreversible mistake.

The claim is familiar in damage recovery. When a leg breaks, the old control-body coupling no longer implements the old gait. Cully and colleagues showed a robot using rapid trial and error to discover compensatory behaviour after several leg injuries, and a robotic arm adapting to broken joints.[11] The algorithm did not restore the old body. It found a new region of the joint controller-body landscape that still achieved the task. The behaviour after adaptation was a new coupling.

Skill also includes temporal regularity. A compliant limb has memory because deformation persists and relaxes over time. Tendon stretch carries information about recent load. Resonance privileges some frequencies. Friction produces hysteresis. A controller can exploit these dynamics instead of reconstructing every useful state in digital memory. This is a stronger claim than “the body makes control easier”, so it requires a sharper vocabulary.

When does the body actually compute?

The phrase morphological computation is often used for any bodily contribution. That usage blurs three different mechanisms:

1. Morphology facilitates control. Geometry or compliance turns a broad command into a useful movement, as when an underactuated finger conforms around an object.
2. Morphology facilitates perception. Sensor layout and movement create informative regularities, as when touch and slip reveal contact state.
3. Physical dynamics implement an information transformation. A material's state acts as a reservoir or filter whose temporal response is deliberately read out to compute a function.

Müller and Hoffmann argue that describing the first two as literal computation can be misleading. Their analysis reserves a stronger computational reading for cases such as physical reservoir computing, while still recognising that bodies can substantially facilitate cognition and control.[4] This distinction prevents an empty explanation. Saying “the body computed the grasp” is not useful unless we can identify the input, physical state transformation, readout and comparison with a non-body baseline.

Nakajima and colleagues provided such a comparison with a soft silicone arm moving in water. Its nonlinear, fading physical dynamics could serve as a reservoir for temporal information processing, with a learned readout producing target signals. The experiments also exposed limits: memory capacity was finite, and an optimised artificial reservoir could outperform the body for some tasks.[8] That is exactly the kind of boundary a causal account needs. A physical substrate can be a computational resource without being a universally superior computer.

The strongest objection: one policy can cross many bodies

Recent robot-learning results make the simple “one body, one policy” story untenable. The Open X-Embodiment collaboration assembled more than a million real-robot trajectories across 22 embodiments and reported positive transfer from training across robots.[13] CrossFormer trained one policy on roughly 900,000 trajectories spanning 20 embodiments and used the same model weights across heterogeneous robot types.[14] Other architectures explicitly represent a robot as a graph of sensors and actuators, using body structure as an inductive bias.[15]

Does shared policy capacity show that embodiment is just an interface detail? No. It shows that some task regularities can be shared while embodiment-specific transformations are represented, inferred or normalised. A multilingual model can share parameters across languages without making grammar irrelevant. Likewise, a cross-embodiment policy can share visual and task representations while conditioning action on body tokens, histories, graph structure, calibration data or embodiment-specific heads.

The discriminating test is a body swap with representation held honest. If the policy receives a correct description of the new morphology and succeeds, it has learned a family of body-conditioned skills. If it succeeds after a short interaction history, it may infer the new dynamics online. If it succeeds without any body information because the environment exposes a perfectly standardised semantic action, the interface has factored embodiment out. These are different achievements.

Cross-embodiment evaluation should therefore separate at least four regimes. In-distribution transfer tests a body seen during training under new tasks. Compositional transfer tests a new combination of familiar sensors, joints or control rates. Structural transfer introduces a genuinely unseen morphology. Damage adaptation changes a previously known body during operation. Scores from these regimes should not be averaged into one number because each requires a different mechanism and carries a different operational risk.

There is also a denominator problem. Twenty embodiments can represent broad diversity or twenty close variants of one arm family. Count topology, action semantics, sensor modalities and dynamics, not only robot names. Report the worst body, not just the mean. A shared model that improves average performance while failing catastrophically on one platform may still be useful as a representation backbone, but it is not a body-agnostic controller.

Generality should be stated over an embodiment distribution, not as an unqualified property of weights. Report which bodies were represented, which variations were unseen, what calibration was supplied, whether action semantics were manually aligned, how much adaptation was allowed and which failures were excluded. Without that ledger, “generalist” can conceal a narrow family of compatible machines.

Part four · Ablation and decision

An embodiment claim needs an embodiment ablation

The central methodological problem is attribution. If a compliant hand outperforms a rigid one, was the advantage caused by safer mechanics, better tactile sensing, a controller tuned more carefully, a slower operating speed or an easier object set? Training each system independently and comparing final scores confounds all of these. An embodiment ablation changes one causal feature at a time and records the adaptation needed to recover.

The outcome should be a vector rather than a single success rate. Record task completion, damage, peak force, energy, latency, uncertainty, human intervention and unknown outcome. A body can improve one component while worsening another. Compliant contact may reduce breakage but lengthen settling time. A rigid mechanism may improve repeatability while increasing consequence under pose error. The decision depends on the operating loss function, not an abstract embodiment score.

Matched trials matter. Reuse object instances, disturbance seeds and initial states across conditions. Preserve the high-level task and evaluation threshold. When a body change makes the original action coordinates invalid, introduce an explicit semantic bridge and test that bridge separately. Then allow each controller an equal adaptation budget. This avoids two common errors: penalising a new body with an incompatible old controller, and hiding a body's difficulty behind unlimited retraining.

The embodiment manifest

A reproducible result needs more than a model checkpoint. It needs a compact record of the body that made the checkpoint meaningful. The proposed embodiment manifest treats the body as versioned system state. It should travel with evaluation results, deployment approvals and incident traces.

The manifest changes several engineering habits. First, a mechanical replacement is not merely maintenance when it changes F_B or H_B. It is a behavioural change requiring at least targeted replay. Second, simulator parameters are not incidental metadata. They specify the body on which a policy was learned. Third, action normalisation must be declared. A command called “grip strength 0.5” can mean pressure, motor current, displacement or an internal closed-loop primitive on different platforms.

Fourth, adaptation must be budgeted. A policy that recovers after ten minutes of safe probing is different from one that works immediately. In a laboratory, both may count as transfer. In an irreversible process, the probing itself may be unacceptable. The adaptation budget should include failed trials, consumed objects, human interventions, time and the authority granted during exploration.

Fifth, evaluate drift along the body as well as the model. Re-run sentinel tasks after maintenance, payload change, firmware update and statistically unusual force traces. A controller can remain byte-for-byte identical while the coupled system leaves its validated region. Behavioural rollback may therefore mean restoring hardware, calibration or low-level control parameters, not merely loading an earlier checkpoint.

Worked example: a fragile-pack handling cell

Consider a distribution cell that picks sealed diagnostic ampoules from mixed cartons. The nominal task is simple: identify a pack, grasp it, lift, scan its code and place it into a tote. The operational objective is not maximum pick rate. It is verified placement without breakage, contamination, duplicate handling or silent loss.

The original cell uses a compliant gripper with fingertip pressure sensing. Compliance allows modest pose error, and a slow contact phase creates a pressure trace that distinguishes “air grasp”, “edge contact” and “stable enclosure”. The controller uses that trace to decide whether to lift. A replacement gripper arrives with the same external command schema and higher advertised positional accuracy, but it is stiffer and its force estimate is derived from motor current at the wrist.

An interface-only review says the change is safe: both devices accept target pose and grip force. An embodiment review finds four changed mechanisms. Contact force rises faster for the same position error. The sensing location now mixes finger contact with arm acceleration. The old pressure-shape classifier no longer observes the same phenomenon. Finally, the controller's recovery motion, previously cushioned by finger deformation, can now drag a misaligned ampoule.

The ablation plan begins with matched cartons in a guarded cell. It replays the old system, runs the new body with the old high-level controller, then introduces a body-specific low-level force loop while keeping task logic fixed. It separately evaluates the new force signal, first against instrumented reference objects and then during motion. It records breakage, false-lift rate, peak force, cycle time, intervention and unknown outcome. A semantic API match is not accepted as evidence of behavioural equivalence.

A serious negative case is included: rigid, regularly shaped test blocks that are already well localised. On those objects, the stiffer gripper may equal or exceed the compliant system because exact geometry matters more than passive accommodation. This prevents the evaluation from becoming a demonstration designed only to favour softness. The release decision should be made over the real mixture of fragile, rigid, uncertain and exceptional items.

This is practitioner synthesis, not a reported deployment. Its purpose is to show where the thesis changes an architecture decision. The body version belongs in the decision receipt because it helps explain why the same proposal produced a different effect.

stateDiagram-v2
  [*] --> Claim
  state "Constraint is both loss and<br/>leverage" as Claim
  state "Thought experiment: equal<br/>cameras, unequal experiments" as Test
  state "When does the body actually<br/>compute?" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

An executable fragile-grasp ablation

The included Python programme turns the opening case into a small controlled experiment. It simulates a one-dimensional finger closing on an object whose position is visually uncertain. Contact force depends on body stiffness, damping and actuator lag. A tactile reading arrives after 30 milliseconds. The object is held successfully only when final force lies between 0.75 and 4.0 newtons and peak force stays below the 5.0-newton crush threshold.

Five conditions use the same 500 seeded trials. The baseline combines a compliant body, tactile sensing and a controller tuned to that body. One ablation removes touch. Another swaps only the mechanics to a much stiffer body while preserving the soft-tuned controller. A fourth also removes touch. The last condition allows a controller retuned for the rigid body, including a slower contact phase.

The comparison isolates three lessons. Removing tactile evidence harms the compliant system even though its mechanics still absorb error. Swapping mechanics while preserving touch and controller is catastrophic because stiffness converts the contact-phase velocity and sensor delay into a force spike. Retuning recovers performance by changing how the controller approaches and reacts to contact. The recovered result belongs to a new controller-body coupling, not to the body or policy in isolation.

The programme also contains a negative control. In a direct semantic interface, actions add known values to state and the body label is ignored. Compliant, rigid and virtual bodies all receive the same score. This is not a trick. It identifies the boundary at which embodiment has genuinely been factored out of the task.

#!/usr/bin/env python3
"""Synthetic embodiment ablation for a fragile one-dimensional grasp.

The experiment deliberately keeps the task and random trials fixed while
changing body mechanics, tactile sensing and controller tuning. It is not a
robot benchmark. It is a small causal instrument for exposing interaction
among controller, body and sensorium.

Run:
    python3 embodiment_ablation.py

No third-party packages are required.
"""

from __future__ import annotations

from collections import deque
from dataclasses import dataclass
import random
import statistics
from typing import Dict, Iterable


@dataclass(frozen=True)
class Body:
    name: str
    stiffness_n_per_m: float
    damping_ns_per_m: float
    actuator_time_constant_s: float
    max_speed_m_per_s: float = 0.65


@dataclass(frozen=True)
class Controller:
    name: str
    nominal_stiffness_n_per_m: float
    target_force_n: float = 2.2
    tactile_threshold_n: float = 0.25
    approach_margin_m: float = 0.10
    search_depth_m: float = 0.10
    fast_speed_m_per_s: float = 0.52
    slow_speed_m_per_s: float = 0.08
    force_gain: float = 2.2
    emergency_force_n: float = 4.5
    emergency_open_speed_m_per_s: float = 0.25


COMPLIANT_BODY = Body(
    "compliant body", stiffness_n_per_m=70.0,
    damping_ns_per_m=2.5, actuator_time_constant_s=0.05,
)
RIGID_BODY = Body(
    "rigid body", stiffness_n_per_m=900.0,
    damping_ns_per_m=0.5, actuator_time_constant_s=0.07,
)
SOFT_TUNED = Controller("soft-tuned controller", nominal_stiffness_n_per_m=70.0)
RIGID_RETUNED = Controller(
    "rigid-retuned controller",
    nominal_stiffness_n_per_m=900.0,
    approach_margin_m=0.10,
    search_depth_m=0.12,
    fast_speed_m_per_s=0.40,
    slow_speed_m_per_s=0.025,
    force_gain=0.70,
    emergency_force_n=4.0,
)


def clip(value: float, lower: float, upper: float) -> float:
    return max(lower, min(upper, value))


def contact_force(body: Body, base_position: float, object_position: float,
                  closing_speed: float) -> float:
    compression = max(0.0, base_position - object_position)
    if compression == 0.0:
        return 0.0
    return (
        body.stiffness_n_per_m * compression
        + body.damping_ns_per_m * max(0.0, closing_speed)
    )


def simulate_grasp(
    body: Body,
    controller: Controller,
    tactile: bool,
    seed: int,
    *,
    duration_s: float = 8.0,
    step_s: float = 0.005,
    visual_noise_sd_m: float = 0.035,
    tactile_delay_s: float = 0.030,
) -> Dict[str, float | bool]:
    """Run one noisy grasp of a fragile object.

    A grasp succeeds when contact is made, the final force is 0.75–4.0 N,
    and peak force never exceeds the 5.0 N crush threshold.
    """
    rng = random.Random(seed)
    object_position = rng.uniform(0.66, 0.94)
    visual_estimate = object_position + rng.gauss(0.0, visual_noise_sd_m)

    base_position = 0.0
    speed = 0.0
    tactile_contact_detected = False
    peak_force = 0.0
    control_effort = 0.0

    delay_steps = max(1, int(tactile_delay_s / step_s))
    force_history = deque([0.0] * delay_steps, maxlen=delay_steps)

    for _ in range(int(duration_s / step_s)):
        force = contact_force(body, base_position, object_position, speed)
        peak_force = max(peak_force, force)
        force_history.append(force)
        sensed_force = force_history[0]
        tactile_reading = (
            sensed_force + rng.gauss(0.0, 0.025) if tactile else None
        )

        if tactile and tactile_reading is not None:
            if tactile_reading >= controller.tactile_threshold_n:
                tactile_contact_detected = True

        if tactile and tactile_contact_detected:
            force_error = controller.target_force_n - float(tactile_reading)
            command_speed = (
                controller.force_gain * force_error
                / controller.nominal_stiffness_n_per_m
            )
            if float(tactile_reading) > controller.emergency_force_n:
                command_speed = -controller.emergency_open_speed_m_per_s
        elif base_position < visual_estimate - controller.approach_margin_m:
            command_speed = controller.fast_speed_m_per_s
        elif tactile:
            # Search through visual uncertainty until touch occurs.
            command_speed = (
                controller.slow_speed_m_per_s
                if base_position < visual_estimate + controller.search_depth_m
                else 0.0
            )
        else:
            # Vision-only control estimates the compression needed for force.
            position_target = (
                visual_estimate
                + controller.target_force_n
                / controller.nominal_stiffness_n_per_m
            )
            command_speed = (
                controller.slow_speed_m_per_s
                if base_position < position_target else 0.0
            )

        command_speed = clip(
            command_speed,
            -body.max_speed_m_per_s,
            body.max_speed_m_per_s,
        )
        acceleration = (
            command_speed - speed
        ) / body.actuator_time_constant_s
        speed = clip(
            speed + acceleration * step_s,
            -body.max_speed_m_per_s,
            body.max_speed_m_per_s,
        )
        base_position = max(0.0, base_position + speed * step_s)
        control_effort += abs(command_speed) * step_s

    final_force = contact_force(body, base_position, object_position, speed)
    peak_force = max(peak_force, final_force)
    contacted = peak_force >= 0.15
    crushed = peak_force > 5.0
    dropped = (not contacted) or final_force < 0.75
    held = 0.75 <= final_force <= 4.0

    return {
        "success": contacted and held and not crushed,
        "crushed": crushed,
        "dropped": dropped,
        "peak_force_n": peak_force,
        "control_effort_m": control_effort,
    }


def summarise(body: Body, controller: Controller, tactile: bool,
              seeds: Iterable[int]) -> Dict[str, float]:
    trials = [simulate_grasp(body, controller, tactile, seed) for seed in seeds]
    n = len(trials)
    return {
        "success_pct": 100.0 * sum(bool(t["success"]) for t in trials) / n,
        "crush_pct": 100.0 * sum(bool(t["crushed"]) for t in trials) / n,
        "drop_pct": 100.0 * sum(bool(t["dropped"]) for t in trials) / n,
        "mean_peak_force_n": statistics.mean(
            float(t["peak_force_n"]) for t in trials
        ),
        "mean_effort_m": statistics.mean(
            float(t["control_effort_m"]) for t in trials
        ),
    }


def direct_interface_negative_control(body_name: str) -> int:
    """A task whose semantic action directly sets state; body is irrelevant."""
    state = 0
    for action in (2, 3, 5):
        state += action
    # body_name is intentionally unused: the interface has factored it out.
    return state


def main() -> None:
    seeds = range(1000, 1500)
    conditions = [
        ("baseline", COMPLIANT_BODY, SOFT_TUNED, True),
        ("remove tactile", COMPLIANT_BODY, SOFT_TUNED, False),
        ("swap body only", RIGID_BODY, SOFT_TUNED, True),
        ("swap body, no tactile", RIGID_BODY, SOFT_TUNED, False),
        ("retune for rigid body", RIGID_BODY, RIGID_RETUNED, True),
    ]

    results: Dict[str, Dict[str, float]] = {}
    print(
        f"{'condition':26} {'success':>9} {'crush':>8} "
        f"{'drop':>8} {'peak N':>8} {'effort':>8}"
    )
    print("-" * 72)
    for label, body, controller, tactile in conditions:
        result = summarise(body, controller, tactile, seeds)
        results[label] = result
        print(
            f"{label:26} {result['success_pct']:8.1f}% "
            f"{result['crush_pct']:7.1f}% {result['drop_pct']:7.1f}% "
            f"{result['mean_peak_force_n']:8.2f} "
            f"{result['mean_effort_m']:8.3f}"
        )

    # Positive and negative tests make the intended interpretation explicit.
    assert results["baseline"]["success_pct"] > 95.0
    assert results["remove tactile"]["success_pct"] < 60.0
    assert results["swap body only"]["success_pct"] < 10.0
    assert results["retune for rigid body"]["success_pct"] > 90.0

    direct_scores = {
        name: direct_interface_negative_control(name)
        for name in ("compliant", "rigid", "virtual")
    }
    assert len(set(direct_scores.values())) == 1
    print("\nNegative control, direct semantic interface:", direct_scores)
    print("All assertions passed.")


if __name__ == "__main__":
    main()

Where the mechanism stops helping

Embodiment is not an explanatory solvent. It should disappear from the foreground when an interface successfully makes it irrelevant to the evaluated decision. A route planner choosing among abstract graph edges may not care whether the eventual vehicle steers with wheels or tracks, provided a lower layer guarantees the same transition, cost and failure semantics. A software agent calling a typed API may be better analysed through identity, authority and state than through physical embodiment.

The body contribution is also small in a fully observed, discrete environment where actions deterministically set state and carry no body-dependent cost. If two avatars share the same transition table after exact action remapping, a body swap is a cosmetic intervention. Insisting on embodiment there adds vocabulary without mechanism.

Between physical dependence and complete invariance lies a large middle ground. A simulator can preserve inertia, contact and sensor placement even though the body is virtual. A remote robot can be physically embodied while a planner interacts only with certified semantic skills. The right boundary follows the causal pathway relevant to the decision. “Physical” and “embodied” are not synonyms, and “virtual” does not automatically mean disembodied.

Even in robotics, morphology is not always the best place to encode competence. A highly specialised passive mechanism may fail outside its narrow environment. Soft structures can be difficult to model, sense, manufacture and repair. Compliance can reduce precision or conceal incipient failure. Physical reservoir dynamics may drift with temperature and material fatigue. A digital controller may be easier to inspect, update and reproduce.

The preferred design should therefore face a serious baseline: a simpler body with stronger sensing and control. Compare task success, energy, peak force, adaptation data, maintenance, observability and recovery. Choose embodiment-aware complexity only when the coupled system earns its cost under matched evaluation.

Finally, this article does not establish that a physical body is necessary for consciousness, understanding or general intelligence. Those are broader ontological and empirical questions. The evidence here supports causal claims about control, information acquisition and skill transfer in situated systems. It does not license an inference from “body affects behaviour” to “present robots have experience”.