Robot Research Practice: Pin the Code Reference Read

A robot demonstration links to a research repository, but the article does not identify which code state the authors used. Opening the same branch later may show different files. A careful reviewer can retain the code reference actually read without claiming to reproduce the demonstration. The procedure below concerns source identity in an already authorized repository copy. It does not download a project, run robot software or report a benchmark result.

Keep the paper's reference and the inspected state

Begin with the exact reference supplied by the paper, project page or authors. Record whether it identifies a repository, branch, tag, commit or individual file. Preserve the original link before following it. A repository address with no revision information is an incomplete code-state description, even if it is a useful starting point for finding the project.

Separately record the state available in the local copy and when it was obtained. Do not claim that it is the newest upstream state without checking that question through an authorized process. A source record should show whether the reviewer inspected an author's explicit revision or merely the state that happened to be available locally.

Resolve a reference and verify the object being named

The git rev-parse manual describes verification and object-type checks using revision syntax. A qualified reviewer can use these facilities to establish whether an intended reference names an available commit-like object. Merely obtaining an identifier is not enough if the object is of a different kind or is unavailable in the inspected repository.

Record the full resolved identifier rather than relying only on a shortened display. Also retain the human-readable reference and repository identity. A branch name is useful context but can point elsewhere later. A retained commit identity makes the source state more precise without proving who ran it, whether the working files were modified or how an experiment was configured.

When the reference comes from an external document, do not assemble an unsafe shell command by pasting it into arbitrary command text. Use appropriate argument handling and the manual's applicable option boundaries. This is a read-only documentation task; resolving a reference does not require changing a branch or resetting a working directory.

Read the identified object in its own context

The git show documentation explains that output depends on object type and describes the information displayed for commits. Inspect the relevant commit and selected file content deliberately. The default presentation is not a guarantee that every file important to a demonstration has been reviewed.

Keep file paths with the revision used to read them. A path opened from a moving web branch and a file read from a retained commit might differ despite sharing a name. If a report cites a particular configuration or implementation detail, connect that observation to the actual file and revision rather than attributing it vaguely to the whole project.

Separate code identity from experimental evidence

A precise commit reference answers which committed state was inspected. It does not establish the installed dependencies, local changes, data selection, hardware configuration or execution settings behind a research claim. Those questions require their own records. A demonstration can remain insufficiently documented even after its public source reference has been made precise.

Do not replace missing experimental details with assumptions drawn from a current README. Instructions may describe a later workflow or multiple supported arrangements. Attribute the instructions to the identified source state and ask the authors which arrangement relates to the reported result when that distinction affects the interpretation.

Deliver a reference note that another reviewer can follow

Save the original citation, repository identity, resolved commit, inspected paths and unresolved questions together. Explain any difference between the author's reference and the locally inspected state. If a required object is absent, retain that limitation instead of silently selecting a different commit whose files look plausible.

Later clarification should add evidence to the note. Preserve the previous reference and explain why the interpretation changed. This makes it possible to distinguish a correction to the article's source citation from a new experiment or new software release. The record should not suggest that merely reading code validated the robot's behavior.

The original illustrations depict a reference workflow and its evidentiary boundary, without real commit identifiers or benchmark figures. See the new robot claim verification collection and article directory for related reading. When a web source also offers a permanent file link, compare its revision with the one in the note before citing it. Do not use a visually similar file from a different revision to illustrate the inspected state. If the authors later identify their experimental revision, record that clarification explicitly and explain whether it matches the previously inspected code reference. Retaining the exact code reference strengthens attribution while leaving performance claims to the evidence that actually supports them.