Automation should expose uncertainty
Version 1.0 can inventory configuration files, dependency declarations, repository identity, common framework and architecture markers, robot names, dataset references, shapes, sensors, and control frequency. It writes what it finds into a portable manifest.
It deliberately uses null values and explicit findings when evidence is missing. Guessing a gripper, framework version, calibration, or success rate would make a clean-looking record less trustworthy than an incomplete one.
The hardest evidence is experiential
A repository scan cannot prove that a policy ran, that an adapter preserves action semantics, or that a reported result followed a particular reset and success protocol. Compatibility and evaluations therefore require evidence supplied by a practitioner; the tool never converts textual similarity into a verified claim.
Repository conventions are inconsistent
The first implementation recognizes several common JSON keys, README markers, dependency files, and Git metadata. That catches straightforward LeRobot-style layouts, but custom Hydra trees and Python-constructed configurations may remain opaque because the inspector never imports or executes target code.
- Safe inspection takes priority over maximal inference.
- Stable finding codes make failures usable in CI and bug reports.
- Ten representative layouts protect the current detection contract; real-world reports will determine the next adapters.
The useful output is the missing list
The validator is valuable before it can fill every field. A maintainer can run it, commit the draft, and resolve a finite list of absent claims. Another team can inspect the same record before buying hardware or beginning integration.