Invariant began as an execution-observability layer for a robot arm. Each node in a workflow emits an event carrying a node identifier, stage, status, timestamp, latency, references to its input and output, and a failure reason when applicable. The schema is small and the storage is an append-only JSONL file.
The schema itself is unremarkable. What proved interesting is the set of capabilities it enabled as it was applied to progressively harder problems.
From logging to per-node diagnostics
The first extension follows directly from having structured events: log the same DAG in simulation and on hardware, then diff them per node. The result is not an aggregate sim-to-real gap but a specific node whose latency distribution or output reference diverges from its simulated counterpart. That converts a general research problem into a localized defect.
The second extension attaches end-effector pose to each event. Robot failures cluster spatially. They concentrate where reach is marginal, where a camera faces a glare source, or where a joint operates near the limit of its calibrated range. Spatially indexed events expose that structure, which a time-ordered log does not.
The third extension is a proprioceptive veto: compare the high-level policy's intended action against low-level sensor and motor telemetry, and halt on disagreement. The comparison carries information only if the two signals are independent, which raised the question that reorganized the rest of the project.
Independence as a design requirement
A monitor sharing the policy's cameras, clock, and learned representation fails under the same conditions the policy fails under. Correlated failure is the default outcome when a system is monitored by a component that resembles it, and querying the same model twice yields no additional information.
Useful independence requires different sensors, different timing, and preferably a different model class. In the Jenga safety-gate experiment this is why tower state is extracted with classical CV while the anomaly signal comes from a distilled world model. The two have uncorrelated failure surfaces, so agreement between them is evidence rather than an artifact of shared training data.
Attestation in construction robotics
Applied to construction, the same structure functions as an attestation layer rather than a debugging tool.
The constraint on unattended autonomous work at a job site is not task capability. For a growing set of bounded tasks the capability exists. The constraint is that parties carrying liability will not accept the output without evidence, and a general contractor, a surety, or an inspector is not positioned to evaluate a neural network. What they can evaluate is an auditable execution record produced by something other than the system under review.
That reframes the monitor's specification. Its function is not to improve safety in the abstract but to make execution legible to a third party with an incentive to find problems. The requirements follow:
- Independence is mandatory, not an optimization. A monitor sharing the policy's perception stack has negligible evidentiary value.
- The record is append-only and complete, including runs that failed. A log that can be curated retroactively is not evidence.
- Blocked actions are recorded with the state that triggered them. The count of declined actions and their justification is the portion an inspector examines first.
- Diversity outperforms redundancy. Replicated identical monitors fail simultaneously. Heterogeneous monitors disagree, and the disagreement carries information.
Event structure
The schema used in the Jenga experiment is the same minimal one applied to a domain small enough to complete.
Six stage types, six statuses, one append-only log. Two statuses exist specifically for the attestation use
case: blocked, recording a vetoed action, and flagged, recording an anomaly noted but
permitted through as advisory.
{
"node_id": "gate_decision-4f2a9c1b",
"stage": "gate_decision",
"status": "blocked",
"timestamp": 1755712043.118,
"latency_ms": 3.7,
"input_ref": "ep-0d41:117",
"output_ref": "block",
"failure_reason": null,
"robot_id": "so101-default",
"spatial_pose": [0.212, -0.038, 0.094]
}One record identifies the deciding node, its stage, its latency, the episode and timestep it acted on, the arm's pose at decision time, and the decision itself. Aggregated across a deployment, these records constitute a reviewable execution history, which is the artifact the liability-carrying party actually requires.
Position
The binding constraint in field robotics is not policy performance. It is the absence of infrastructure that allows a policy's behavior to be audited by someone who was not present during execution. Capability is improving without intervention. Accountability is not, and accountability is what currently gates deployment.