SECTION 01
Verification is a relationship between a claim and evidence.
A specification on a manufacturer product page can be accurately transcribed, reviewed and linked to its source. That makes the data provenance stronger. It does not turn the OpenRGD team into the laboratory that measured the value.
The distinction sounds obvious, but data products often erase it. Once a number is normalized into a database, the source context disappears and consumers begin to treat every field as equally authoritative.
SECTION 02
OpenRGD stores evidence at claim level.
The robot evidence model separates the property being asserted from the raw value, normalized representation, units, conditions, evidence type, verification state, source URL and verification timestamp. It can also state explicitly whether the claim has been independently tested.
This lets a robot profile contain claims with different evidence quality without forcing the whole entity into one simplistic verified or unverified bucket.
- MANUFACTURER_STATED identifies a claim sourced from the manufacturer.
- REVIEWED_SOURCE_CLAIM records that the supporting source has been reviewed.
- independently_tested remains a separate boolean and can stay false.
- verified_at records review timing without implying perpetual validity.
SECTION 03
Unitree G1 is a useful example.
The current OpenRGD G1 profile links official product and developer sources, including official repositories and model assets. That allows the site to present a source-backed developer profile and distinguish product facts from OpenRGD interpretation.
The same page deliberately avoids claiming that every commercial G1 variant has identical development access. G1 and G1 EDU differences matter, and the existence of an official repository does not prove that every unit or package exposes the same capabilities.
Source-backed does not mean variant-agnostic, independently benchmarked or physically commissioned.
SECTION 04
Evidence also has a time dimension.
Robot specifications, repositories and product variants change. A provenance record therefore needs a review timestamp and, where useful, validity boundaries. The goal is not to freeze a claim forever but to make freshness inspectable.
This is particularly important for developer assets. A repository path that existed when a profile was reviewed may later move, deprecate or change scope. Provenance makes that maintenance problem visible.
SECTION 05
Consumers should be able to choose their own evidence threshold.
A comparison page may be comfortable displaying reviewed manufacturer dimensions. A safety-sensitive workflow may require independent validation. A research crawler may want both but rank them differently. Keeping evidence types explicit lets each consumer decide instead of inheriting one opaque confidence score.
The practical rule is simple: OpenRGD should make claims easier to inspect, not easier to overstate.
SOURCES & PRIMARY CONTEXT