Methodology

How DEPLOY uses form_factor as a regulatory-regime descriptor

form_factor describes the physical machine and the operating or regulatory regime it lives under. Not the product. Not the use case. Twelve enum values map to twelve regulatory regimes.

What form_factor is

form_factor is the field on a Model record that names the physical shape of the machine and the regulatory regime that governs its operation. The two are coupled: a humanoid robot operates under OSHA when deployed in a workplace; an autonomous vehicle operates under NHTSA plus state-level DMV authority; a surgical robot operates under FDA clearance scope; a sidewalk delivery robot operates under municipal-level sidewalk-robot ordinances; a maritime drone operates under USCG plus IMO conventions.

The regime determines what verification anchors apply, what incident records surface, what clearance milestones gate commercial deployment, and what the cap-flag thresholds look like. form_factor is the load-bearing classification for every downstream verification question on the platform.

What form_factor is not

form_factor is not a product taxonomy. A maker may ship multiple products under one form_factor; a maker may ship products that span multiple form_factors. The field describes the regime each product operates under, not the company's product strategy.

form_factor is not a use case. A Coco sidewalk bot delivering food and a Starship sidewalk bot delivering parcels share form_factor sidewalk because both operate under municipal-level sidewalk-robot ordinances and the same public-right-of-way framework. A Nuro vehicle delivering food shares neither of their form_factors. Nuro is av because the operating regime is DMV plus NHTSA, not municipal sidewalk ordinance, regardless of what the vehicle is carrying.

form_factor is not a humanoid-or-not classification. A humanoid maker that ships a biometric wearable as a companion device ships two records: one humanoid, one wearable. Each carries its own regime, its own clearance milestones, its own incident framework. The maker shows up on both Model lists because the products show up on both form_factor lists.

The form_factor enum

The enum is intentionally narrow and aligned to regulatory regimes:

humanoid: bipedal or upper-body humanoid machines operating under OSHA in workplaces, with consumer-promised entries operating under emerging consumer-safety regimes per jurisdiction.

av: passenger or freight vehicles operating under NHTSA plus state-level DMV authority on public roads.

surgical: surgical robots operating under FDA clearance scope plus equivalent in jurisdictions outside the US.

drone: airborne uncrewed platforms operating under FAA plus DoD authority in the US, with equivalent jurisdictions elsewhere.

sidewalk: sidewalk-going delivery and service robots operating under municipal-level robot ordinances and public-right-of-way frameworks.

maritime: surface and subsea uncrewed platforms operating under USCG plus IMO conventions for commercial; under DoD for defense.

agriculture: large-format agricultural autonomy operating in private agricultural settings under OEM-customer regimes plus EPA where pesticide handling enters scope.

industrial: industrial autonomy including AMRs, construction, and large-format manufacturing operating under OSHA plus customer-procurement regimes.

wearable: head-mounted, wrist-worn, or apparel-integrated AI devices operating under FCC plus consumer-electronics frameworks, with health features operating under FDA where they cross the clearance threshold.

biometric: ring, watch, patch, and CGM-class wearable biometric devices where the biometric capability is the primary feature, operating under FDA clearance for the clinical capabilities.

service: in-store or in-restaurant service robots operating under OSHA plus venue-specific safety frameworks.

defense_ugv: defense ground vehicles operating under DoD procurement plus operational-test regimes.

other: a residual catchall. Records carrying other are reviewed for re-classification on a recurring cycle; other is not a long-term state.

Worked examples

Apptronik Apollo is humanoid. Apollo operates under OSHA in customer workplaces (Mercedes-Benz, GXO, Jabil). Apollo's contract manufacturer is Jabil; not Foxconn. Foxconn's humanoid relationship is with NVIDIA at the brain-provider tier, a separate arrangement. The contract-manufacturer identification is part of the Model record; it does not change the form_factor.

Tesla Robotaxi is av. The vehicle operates under NHTSA plus state-level DMV authority. Tesla Optimus is humanoid. The two products are different records under different regimes. Tesla Optimus does not become av because Tesla also operates av products; the form_factor is per-product, not per-company.

Intuitive Surgical da Vinci is surgical. The platform operates under FDA clearance scope per cleared procedure. The 11,395 installed-base count anchors production stage (see /methodology/deployment-lifecycle) within the surgical form_factor.

Saronic is maritime. Saronic surface vessels operate under USCG plus DoD framework. Anduril Dive-LD plus Ghost Shark are also maritime; HII REMUS is maritime under the legacy-prime regime. The maritime form_factor accommodates the new-defense-versus-legacy-prime architectural distinction without splitting the enum.

Starship Technologies is sidewalk. Starship's commercial delivery operations across multi-country deployments operate under municipal-level sidewalk-robot ordinances per jurisdiction. Cartken Courier is sidewalk on the same regime; the platform's commercial model (hardware-sale to Melco) does not change the form_factor.

John Deere autonomous tractors are agriculture. The autonomy operates in private agricultural fields under OEM-customer regimes plus EPA where pesticide handling enters scope. XAG agricultural drones are drone, not agriculture, because the regime is FAA, not the private agricultural OEM-customer framework.

Meta Ray-Ban is wearable. The device operates under FCC plus consumer-electronics frameworks. Health features that cross the FDA clearance threshold move into FDA scope; the form_factor stays wearable because the primary feature is not the biometric capability.

Oura Ring is biometric. The biometric capability is the primary feature; the device operates under FDA clearance for the clinical capabilities (per Oura's clearance history) plus FCC plus consumer-electronics frameworks for the non-clinical surface. Apple Watch is biometric on the same discipline despite being marketed broadly; the biometric capabilities (ECG, blood-oxygen, AFib detection) are the primary feature class that drives the regulatory regime.

Anduril Roadrunner is defense_ugv when deployed as a ground-vehicle defense platform under DoD procurement plus operational-test regimes. The defense_ugv enum was added per Agent B's recent schema migration to surface ground defense autonomy as a distinct regime from drone (airborne defense), maritime (surface and subsea defense), and av (civilian ground vehicles).

Intersection with maturity stage

form_factor and maturity stage move independently. A humanoid can be at research, pilot, commercial, or production stage. A surgical robot can be at research, pilot, commercial, or production stage. The maturity-stage definitions per /methodology/deployment-lifecycle are exact:

Research means lab-only sales, study, or development. Pilot means limited trials with a customer of record. Commercial means real economic work where the customer pays for output. Production means mass-produced at volume.

The regulatory regime named by form_factor stays the same as a product moves through maturity stages. The regime determines what clearance milestones gate each transition. Pilot-to-commercial in surgical requires FDA clearance scope for the deployed procedure; pilot-to-commercial in av requires the relevant state-level commercial authorization; pilot-to-commercial in sidewalk requires the relevant municipal-level ordinance authorization.

Source discipline

The regulator named by form_factor is the source of record for regime-specific verification. FDA databases anchor surgical and biometric clearance. NHTSA Part 573 plus state DMV permit records anchor av. FAA Part 135 plus Part 137 plus waiver authorizations anchor drone. USCG plus IMO conventions anchor maritime. DoD procurement records and OTA plus IDIQ contract announcements anchor defense_ugv.

Tier-1 news is acceptable when it confirms the regime-source record. A Reuters article reporting an FDA clearance is acceptable because the FDA record exists separately. A trade-press article asserting a clearance without the FDA record is treated as claim.

Operator-disclosed material is verified at maker-disclosed tier within form_factor. The maker's product page asserting an operating regime is corroborating but does not anchor the regulatory state on its own; the regulator's record is the verified anchor.

Cap-flag application

A product whose regime is contested across regulators is cap-flagged. Cross-jurisdictional regulatory disagreement surfaces explicitly in the Model record.

A product whose form_factor is provisionally assigned other is cap-flagged until a permanent regime is named. Other is not a long-term state.

A maker that ships across multiple form_factors is recorded across multiple Model entries, one per product. The Company record carries the maker's full portfolio; the form_factor field stays per-product.

The framework applies to us

If we ship a Model record with the wrong form_factor, we correct it. The Apollo classification correction discipline applies recursively: if we conflate a humanoid product with an industrial product because both ship to factory floors, we re-anchor to the regulatory regime each product actually operates under.

Cross-form-factor product portfolios surface honestly. We do not collapse a maker's diverse product line into one form_factor for catalog convenience. The cost is a Model record per product. The benefit is verification posture per regime.

The correction is logged at /corrections. The original anchor is preserved.

Where to go next

The methodology canon: /methodology/what-verified-means for the core verified-vs-claimed framework, /methodology/deployment-lifecycle for the maturity-stage definitions that intersect with each form_factor, /methodology/people-state for people graph methodology, /methodology/patent for the patent graph methodology.

The applied work: registry.deploy.report/models for the Model records with form_factor per entity, and the per-form_factor category surfaces (humanoids, surgical, robotaxis, drones, and the broader cohort).

Continue reading