Research analysis
The METR and Anthropic report: what Physical AI builders can learn
The primary report, its limits, and our interpretation of what evidence-led evaluation means for robot builders.
Read the assessment behind the headline
Stork's November 6 newsletter uses the headline “Anthropic hides METR data on ASI timelines.” The underlying primary source is METR's November 5 assessment of AI research and development acceleration at Anthropic. Those are different frames: the report evaluates an acceleration question, rather than establishing a date for artificial superintelligence.
METR reports a central estimate of roughly twice the rate of progress, alongside substantial uncertainty. It discloses access restrictions, Anthropic's redaction rights, and limits on the public evidence. It also says it considered deliberate deception by Anthropic extremely unlikely. Reading those statements together is more informative than carrying the headline's implication into a robotics article.
What this means for a robotics team
The connection to Physical AI is our interpretation, not a finding in the METR report. Strong claims need inspectable evidence and a clear account of what the evaluator could not see. A robot team faces that problem whenever a polished demonstration is treated as proof of dependable autonomy.
A task description, a model's published explanation, a controller log, and a video can disagree. The responsible response is to investigate the disagreement and preserve uncertainty. Choosing the most flattering signal produces a story, but leaves the next engineer without a reliable account of the run.
Keep capability measures tied to their task
METR's time-horizon measure concerns the difficulty of tasks expressed in human completion time. It is not the number of hours a model can safely operate a robot. Transferring a software benchmark directly into a claim about manipulation or autonomous physical operation would skip the evidence needed for that new setting.
For a robot task, define your own measurable finish and operating conditions. Was the object placed? Was human help needed? Were all attempts counted? Did the scene change between trials? An honest account of a narrow result is more useful to a prospective collaborator than an ambitious capability label with no acceptance criteria.
Publish the access boundary
A public integration report should explain where its evidence came from. Did the observer see the input request, a controller acknowledgement, measured robot state, or only a browser rendering? Did the team inspect the original recording? Were parts withheld for privacy? What would have changed the conclusion?
You can disclose a boundary without publishing secrets. For example: camera images were retained locally. A public report includes a selected screenshot. Credentials and private prompts were excluded. This helps readers judge the result while keeping the information boundary deliberate.
Use failures to qualify the claim
Our archived BluPe warm-up test illustrates the approach. The capture receipt and screenshot support a claim about recorded evidence, while the displayed execution receipt shows no accepted trajectory packets. That is a useful integration finding, but it cannot be presented as a successful manipulation trial.
The same discipline applies to a stop request or an apparent boundary violation. Record what was requested, which interface responded, what was measured afterward, and where observation ended. The word confirmed should refer to an actual observation or receipt with a stated scope.
The article we want to write after a test
A strong Physical AI report lets a reader reconstruct the task, evaluate the evidence, and understand the remaining uncertainty. It includes unsuccessful attempts and separates the behavior of the model from the behavior of the physical system. It states whether the environment was simulation or hardware and names the versions that matter.
That is the practical lesson we take from the transparency discussion. It does not establish a forecast about ASI, a judgment that every redaction is improper, or a safety certification for ClawMetry. It gives us a better standard for the integration stories we publish: clear observations, qualified conclusions, and evidence a reader can assess.
Sources and evidence
External sources support the attributed background. Integration accounts describe historical project evidence. Guidance and proposed tests are identified in the article.