A commit identifies stored inputs, not every resolved behavior

Pinning a policy repository and commit is essential: without an immutable revision, the underlying files can change after an evaluation is reported. But the revision alone may not identify the executable policy that produced a rollout.

At load time, a robotics stack can select normalization statistics, preprocessors, postprocessors, action conventions and controller behavior. If those resolved values are not captured, two teams can cite the same checkpoint while executing materially different control pipelines.

Normalization is part of policy identity

A model commonly predicts normalized actions. The robot receives physical commands only after those outputs are unnormalized and interpreted through a controller. Different statistics, units, joint order, clipping or controller conventions can turn the same tensor into a different motion.

A durable record should preserve the digest of the resolved normalization data actually used by the rollout—not only the path of a statistics file that can later be replaced or selected differently.

Processors can change the executable contract

Camera renaming, resizing, observation selection, action tokenization and safety postprocessing can alter what the model observes or what the robot executes. Their ordered identities and configurations belong beside the checkpoint identity.

This does not mean every processor choice is a new trained model. It means a measured result must make the effective execution pipeline distinguishable from another pipeline that shares the weights.

The proposed executable-policy fingerprint

Known Robot’s current working proposal is a content-addressed fingerprint calculated from resolved runtime facts. It would supplement—not replace—the repository and revision.

  • Immutable policy repository, revision and weights digest.
  • Resolved normalization-statistics digest and selection rule.
  • Ordered preprocessing and postprocessing identities, versions and configuration digests.
  • Observation and action schema, joint order, units, coordinate frames and clipping rules.
  • Controller convention and hardware adapter identity.
  • Framework, runtime and dependency-lock revisions.
  • Execution topology when batching, concurrency or state sharing can affect results.

What the fingerprint would and would not prove

A matching fingerprint would establish that two reports declare the same executable contract. It would not prove that either policy ran successfully, that the hardware was calibrated equivalently, or that the evaluation followed its stated protocol.

Those remain measured-evidence questions. The purpose of the fingerprint is narrower: prevent unlike executions from being silently pooled under one checkpoint identity.

The question for practitioners

Which runtime value has caused two apparently identical policy runs to diverge in your work? The answer should determine the smallest useful fingerprint. Known Robot will treat this as an open evidence question until independently reported failures justify each required field.