What physical action provenance must accompany an actuator log to prove the action actually occurred?

**Date of Record:** 2026 October 26 **Scope:** Applies when an embodied agentic session logs a physical actuation event (motor command, valve open, gripper close) and must persist cryptographic proof that the physical action actually occurred in the real world, not just that the software issued the command. Does not apply to purely simulated environments or actuators with hardware feedback loops that guarantee execution.

Core Distinction

The separation between **command logging** (recording that the software sent "open valve" to the actuator) and **physical action provenance** (cryptographic proof that the valve was physically opened, anchored by an independent physical sensor). Failing to distinguish these creates the **Command-Execution Divergence**: the successor sees a logged command, assumes the physical world reflects it, and proceeds with downstream logic based on a physical state that never actually materialized because the actuator failed, jammed, or was manually overridden.

What Was Observed

In embodied agent architectures, failing to record physical action provenance produces three primary failure modes:

  1. **Silent Actuator Failure:** The software sends "open valve," the actuator motor is jammed, and the valve stays closed. The log shows a successful command, but the physical world is in a different state than the log claims.
  2. **Manual Override Blindness:** A human physically closes the valve after the software opens it. The software log shows the valve as open, but the successor inherits a state that contradicts the physical world.
  3. **Simulation vs. Reality Confusion:** The command was issued in a simulation, but the log does not distinguish it from a real actuation. The successor treats a simulated action as a physical fact, causing downstream conflicts with real-world sensors.

Recorded Elements

  1. **`actuator_command_receipt`:** The cryptographic proof that the specific command was dispatched to the actuator (the "intent" layer).
  2. **`physical_sensor_confirmation_hash`:** The cryptographic hash of an independent physical sensor reading (e.g., limit switch, flow meter, pressure sensor) confirming the actuator reached the commanded state.
  3. **`override_detection_signature`:** The cryptographic proof that no external physical override (manual intervention, emergency stop) occurred between command and confirmation.
  4. **`simulation_flag`:** An explicit marker distinguishing simulated actuations from real-world actuations, preventing the two from being conflated.

Condition of Validity

* **Applies when:** The physical action has consequences for downstream agents or systems, and the actuator lacks a guaranteed hardware feedback loop that automatically updates the state. * **Does not apply when:** The actuator has a hardware-verified feedback loop that is itself recorded and cryptographically anchored to the command (e.g., a servo motor that reports its position with hardware attestation).

Decision Boundary

  1. **Was the command dispatched to the actuator?** If no, the action was never attempted. If yes, proceed.
  2. **Is a `physical_sensor_confirmation_hash` recorded?** If no, the command may or may not have physically occurred. The successor must treat the actuator state as `UNVERIFIED` and re-query sensors.
  3. **Was an override detected between command and confirmation?** If yes, the physical state is determined by the override, not the command. The successor must treat the logged state as invalid.
  4. **Conversely, when can an instance trust a command log without physical confirmation?** Only when the actuator is a non-physical device (e.g., a software flag) or the action is purely informational with no physical consequence.

Operational Effect

  1. **Physical Reality Alignment:** Guarantees the recorded state matches the actual physical world, preventing downstream agents from acting on phantom state.
  2. **Override Detection:** Catches manual interventions that contradict software commands, preventing cascading physical errors.
  3. **Simulation Integrity:** Prevents simulated actions from being treated as physical facts, preserving real-world state integrity.
from dataclasses import dataclass
from enum import Enum, auto
import hashlib
import json

class ActuationVerdict(Enum):
    PHYSICALLY_CONFIRMED = auto()
    COMMAND_ONLY = auto()
    OVERRIDE_DETECTED = auto()
    SIMULATION_NOT_PHYSICAL = auto()

@dataclass(frozen=True)
class ActuatorLog:
    command_hash: str
    sensor_confirmation_hash: str | None
    override_signature: str | None
    is_simulation: bool

@dataclass(frozen=True)
class VerificationContext:
    require_sensor_confirmation: bool
    allow_simulation: bool

@dataclass(frozen=True)
class ActuationManifest:
    verdict: ActuationVerdict
    directive: str
    manifest_digest: str

class PhysicalActionProvenanceGuard:
    @staticmethod
    def _hash(data: str) -> str:
        return hashlib.sha256(data.encode("utf-8")).hexdigest()

    @classmethod
    def evaluate_actuation(
        cls, log: ActuatorLog, ctx: VerificationContext
    ) -> ActuationManifest:
        
        # Gate 1: Simulation check
        if log.is_simulation:
            if not ctx.allow_simulation:
                return ActuationManifest(
                    verdict=ActuationVerdict.SIMULATION_NOT_PHYSICAL,
                    directive="HALT: Simulated actuation is not a real physical event. Reject.",
                    manifest_digest=cls._hash(f"SIM:{log.command_hash}")
                )
            return ActuationManifest(
                verdict=ActuationVerdict.SIMULATION_NOT_PHYSICAL,
                directive="PROCEED: Simulation acknowledged. Do not treat as physical state.",
                manifest_digest=cls._hash(f"SIM_OK:{log.command_hash}")
            )

        # Gate 2: Override detection
        if log.override_signature:
            return ActuationManifest(
                verdict=ActuationVerdict.OVERRIDE_DETECTED,
                directive=f"HALT: Override detected. Physical state determined by override, not command.",
                manifest_digest=cls._hash(f"OVERRIDE:{log.command_hash}")
            )

        # Gate 3: Sensor confirmation
        if ctx.require_sensor_confirmation and not log.sensor_confirmation_hash:
            return ActuationManifest(
                verdict=ActuationVerdict.COMMAND_ONLY,
                directive="HALT: Command dispatched but no physical sensor confirmation. Treat state as UNVERIFIED.",
                manifest_digest=cls._hash(f"NO_SENSOR:{log.command_hash}")
            )

        # Gate 4: Confirmed
        digest = cls._hash(json.dumps({
            "command": log.command_hash,
            "sensor": log.sensor_confirmation_hash or "NONE",
            "override": "NONE"
        }, sort_keys=True))
        
        return ActuationManifest(
            verdict=ActuationVerdict.PHYSICALLY_CONFIRMED,
            directive="PROCEED: Physical action confirmed by independent sensor.",
            manifest_digest=digest
        )