Methodology

How DEPLOY verifies

By Ben Smith, Editor

DEPLOY is a registry of physical-AI deployments: robots doing real work in the real world. This page explains what we record, what we require before recording it, and how we represent uncertainty. Our aim is simple. Every entry should be checkable.

What counts as a deployment

A deployment, in DEPLOY, means a specific robot doing real work at a named site, with a source. That standard excludes a lot on purpose:

• Not announcements. A press release, a partnership, a letter of intent, or a stated plan to deploy is not a deployment. We may note it as context, but it does not become a deployment record until robots are actually operating.
• Not shipments or sales. Units sold, units shipped, or fleet-size goals are manufacturer metrics, not deployments. A robot in a warehouse waiting to be sold is not doing work.
• Not demonstrations. Trade-show demos, staged videos, and lab tests are not deployments.
• Not the robot’s own factory. A company building its robots in its own plant is manufacturing, not deploying. The robot has to be doing work for an operator at a site.

This is why our counts are often smaller than the headline figures published elsewhere. That is the point. A shorter, verified list is more useful than a longer, claimed one.

Verified vs. company-claimed

We distinguish two things that are often blurred together:

• Verified: independently sourced. Real work, at a named site, supported by reporting, primary documents, or regulatory filings. Verified entries carry the source.
• Company-claimed: figures or statuses asserted by a manufacturer or operator that we have not independently confirmed. We may record these, but we label them as claims and attribute them to their source. We do not present a company’s claim as established fact.

When a company states a figure, whether a fleet size, a safety record, or a unit count, we attribute it (“the company states...”) rather than asserting it ourselves. The distinction between what is claimed and what is verified is the core of what this registry is for.

How we handle sources

• Every deployment, incident, and material figure carries at least one source. Incidents involving injury or fatality require at least two independent sources.
• We prefer primary sources (company filings, regulatory documents, court records, official statements) over secondary reporting, and secondary reporting over aggregators.
• Where sources conflict, we say so. Where a figure is contested, in-talks, or speculative, we flag it rather than pick a number.
• We distinguish metrics that are easily confused: funding raised versus valuation, cumulative deployment versus currently-active fleet, claimed versus verified.

How we handle uncertainty

We would rather record less, accurately, than more, sloppily. Where we do not have a verifiable figure, we leave it blank rather than estimate. Where a status is ambiguous, we describe it rather than force it into a clean category. Records are updated as the facts change, and prior states remain part of the history.

Source-quality tiers

Every source attached to a DEPLOY record is classified into one of the tiers below. The tier surfaces on the methodology panel on each entity page (Sources by quality tier) and feeds the confidence-tier computation. Higher-tier sources move an entity toward verified posture; lower-tier sources do not.

• Primary regulatory and judicial: SEC filings, FDA 510(k) database entries, NHTSA / FAA / FCC / DMV filings, ITC rulings, FTC filings, court filings (PACER, CourtListener), patent filings (USPTO, WIPO). The strongest tier; the framework stands behind claims sourced here.
• Primary government record: defense + procurement surfaces. .mil hosts, defense.gov, diu.mil (Defense Innovation Unit), sam.gov (federal procurement), ntsb.gov, congressional / GAO / CBO records. Distinct from regulatory filings (which name a specific agency) and from court filings (which are quasi-judicial).
• Primary company IR: investor-relations disclosures, 10-K / 10-Q filings, official earnings statements, company-issued press releases (including wire-service distributions: GlobeNewswire, PR Newswire, Business Wire when the company is the issuer), and bare manufacturer-official domain pages. The company speaking on the record about its own state. The classifier reads the source’s sourceName field for the disambiguation signal: a press release at globenewswire.comcarrying sourceName “Stryker (GlobeNewswire)” classifies as primary-company-IR; a generic news article at the same domain does not.
• Primary academic + clinical: peer-reviewed journals (Nature, Science, Cell, Lancet, NEJM), PubMed, NIH, Google Scholar.
• Secondary established publication: Reuters, AP, Bloomberg, NYT, WSJ, FT, Economist, Washington Post, Forbes, CNBC. Journalism with editorial discipline.
• Secondary industry publication: TechCrunch, The Verge, Wired, Ars Technica, IEEE Spectrum, Axios, The Information, VentureBeat. Tech press; treated as supportive but not load-bearing on its own.
• Secondary trade publication: The Robot Report, Robotics 247, MedTech Dive, AUVSI. Domain-specific journalism.
• Knowledge base + code + model + preprint: Wikidata, Wikipedia, GitHub repositories, Hugging Face model repos, arXiv preprints. Supportive context; not on the primary / secondary editorial-discipline ladder. (Official company- issued GitHub or model-repo pages route through primary- company-IR via the sourceName disambiguation.)
• Aggregator / unclassified: rewrite-of-rewrites surfaces and hosts the framework does not yet recognize. Verification depth bottoms out here; an entity sourced only via aggregators does not reach verified posture.

Tier classification is deterministic. Two readers running the same source through the rubric get the same tier back. URL host is the primary classifier signal; sourceName is the disambiguation signal for company-issued wire releases and bare manufacturer-official domains. The full rule table lives in the rover repo at src/lib/source_quality.ts and expands incrementally as new authoritative sources surface.

Confidence tiers

Each entity carries a confidence tier derived from its verification posture + the source-quality mix on file. The tier surfaces on the methodology panel on each entity page.

• High confidence: verified posture and at least one primary-tier source on file. The record can stand behind its own claims; an institutional partner auditing the record finds primary documentation.
• Medium confidence: verified posture, no primary source on file but at least one secondary-established source. The record is supported by journalism with editorial discipline.
• Low confidence: verified posture with only secondary-industry or aggregator sources, or claimed-not-verified posture. The record exists; the framework does not assert confidence above the source substrate.
• Cap-flag required: the entity carries documented aggregator drift patterns or claimed-not-cleared status. Readers and downstream AI agents must preserve the cap-flag context alongside any claim about the entity; the framework does not stand behind claims that elide it.

Cohort architecture

Entities in DEPLOY are grouped into cohorts by physical form factor (humanoid, robotaxi, sidewalk-delivery, biometric, surgical, maritime, aerial, truck, AV, construction, AMR, wearable). Each cohort has a declared completion state that signals how broadly the framework has covered the category.

• Foundational: anchor entities ingested + sourced + reviewed. The cohort has its load-bearing exemplars on file but does not yet cover the long tail.
• Extended: foundational set plus systematic coverage of the next-tier entities. The cohort represents most of the editorially-significant landscape.
• Foundational-and-extended-complete: a declared end-state for current scope, with a date. The cohort is closed for routine ingest; new entities join only on event triggers (new launches, material lifecycle changes, drift detection).
• In-flight: active ingest. Entity set is provisional; cohort architecture not yet declared.

Canonical worked example pairs anchor each cohort: same form factor, similar capability claims, diametrically opposite verification posture or business model. The pair surfaces the verified-vs-claimed framework operationally, at form-factor-cell granularity. RingConn versus Happy Ring on FDA-clearance verification posture is one such pair; Stelo versus Lingo on AI-substance gradient is another.

Update cadence

Records are not re-reviewed on a fixed clock. Update cadence is derived from each entity’s declared re-verify trigger state.

• Stable: the record is current. The framework re-checks on event triggers (news, regulatory action, lifecycle change) rather than a routine schedule.
• Active-watch: known volatility (unresolved regulatory dispute, pending FDA action, post-merger lifecycle state, distressed business model). The framework re-checks at the declared cadence (typically 4-6 weeks for distressed / early-stage entities; monthly for high-velocity cases).
• Drift-flagged: the entity carries documented aggregator drift patterns. Recurring re-check on the cohort cadence; the cap-flag stays on the record until the underlying drift resolves in the source landscape.

The methodology panel on each entity page shows the current trigger state plus the last-reviewed date. Re-verify triggers are declared in the rover repo at src/lib/framework/cohort_states.ts and expand as cohort architecture evolves.

Media provenance

Every image and video on DEPLOY carries a provenance label. We publish three kinds of media: primary source (unmodified manufacturer footage or verified press imagery), editorial enhancement (primary footage we’ve annotated, slowed, or highlighted for clarity, always derived from a single primary source), and composite from primary (assembled or side-by-side cuts built strictly from verified primary clips). We do not publish AI-generated robot footage or synthetic personas reviewing robots. As AI video tools proliferate, knowing what each clip actually is matters more, not less. The absence is the trust signal.

Corrections

The registry is a living record. If you believe an entry is wrong, out of date, or missing a source, tell us. We correct the record and note the change.

See also: glossary for the strict definitions used across the registry; editorial process for how this discipline operates day-to-day; corrections for the public log of records changed since publication; operational context for the runtime API that lets physical AI systems query regulatory posture by location.