How DEPLOY separates operator from manufacturer

What we track

A deployment record carries up to four distinct corporate relationships. We track each one separately.

Manufacturer. The company that designed the platform and ships it as their product. Apptronik manufactures Apollo. Agility Robotics manufactures Digit. Figure AI manufactures Figure 02 and Figure 03. Tesla manufactures Optimus.

Contract manufacturer. The company that physically assembles the platform under contract from the manufacturer. Contract manufacturer is a separate fact from manufacturer; it does not change the brand identity of the product. Apollo's contract manufacturer is Jabil; Apollo's manufacturer is Apptronik.

Operator. The company that runs the robot in active operation. The operator is the entity whose workflow the robot serves; the operator decides where the robot operates, what tasks the robot performs, and what hours the robot works. GXO operates Agility Digit at GXO Flowery Branch. BMW operates Figure 02 at BMW Spartanburg. Tesla operates Optimus at Tesla factories. Bot Auto operates its own autonomous trucks on the Houston-Dallas corridor.

Customer. The company that pays the manufacturer or operator for the output the robot delivers. The customer is the billing relationship. In many deployments the operator and the customer are the same entity (GXO operates Digit and pays Agility under a Robots-as-a-Service contract; GXO is both). In some deployments they are different (a brokerage customer paying Bot Auto for freight delivery is the customer; Bot Auto is the operator).

Deploy-site is a fifth fact, separate from all four corporate relationships. Deploy-site is the physical location where the robot operates: BMW Spartanburg, GXO Flowery Branch, the Houston-Dallas freight corridor, a Tesla factory line. Deploy-site can be owned by the operator, by the customer, or by a third party.

The operator-vs-manufacturer distinction

A maker statement that a robot is deployed is a claim about manufacturer. The robot exists; the maker ships it. The maker statement does not on its own verify who runs the robot in active operation.

A customer-of-record statement that the robot is running on the customer's floor is a verification of operator state. The customer's workflow uses the robot; the customer's environment hosts the robot; the customer's output depends on the robot. This is the verification anchor for active operation.

The two collapse when the manufacturer is also the operator. Tesla manufactures Optimus and operates Optimus at Tesla factories. The customer of record is Tesla itself. We track this as a research-stage deployment (per /methodology/deployment-lifecycle) where the maker is the customer; the deployment record is editorially significant; the maturity stage is honest about what is happening.

The two are distinct when the manufacturer ships to a third- party operator. Apptronik manufactures Apollo and ships to Mercedes-Benz, GXO, and Jabil. Each of those three is an operator at their respective deploy-sites. Each is also a customer in the contractual sense. The operator state is verified at the customer of record; the manufacturer state is verified at Apptronik's surface.

Both-Nullable deployment customer XOR

The deployment record carries operator_id and customer_id as separate columns. Both can be filled. Both can be null. One can be filled while the other is null.

When operator and customer are the same entity, both columns carry the same company_id. The deployment record reads coherently: company X is the operator and the customer.

When the operator runs the deployment for an external paying customer, the two columns carry different company_ids. Bot Auto's commercial truckload booked through Ryan Transportation is the canonical worked example: operator_id is Bot Auto; the freight customer's company_id is the customer (the customer ships freight; Bot Auto runs the truck; Ryan Transportation is the brokerage intermediary).

When the manufacturer ships hardware to a customer who operates the platform themselves but does not pay an ongoing service fee, operator_id and customer_id carry the same company_id and the manufacturer relationship is tracked through the Model record's company_id. A research customer buying a Unitree G1 is operator-and-customer; Unitree is the manufacturer on the Model record.

When the operator-customer field on a deployment record cannot resolve at primary-source verification depth, the field stays null. We do not assume that a maker-asserted customer relationship is verified at the customer's surface; we wait for the customer to confirm. The Both-Nullable XOR surfaces the honest absence.

Worked examples

The Apollo chain is the canonical layered worked example. Apptronik manufactures Apollo. Apollo's contract manufacturer is Jabil; Apptronik publicly disclosed the production arrangement with Jabil. Apollo's contract manufacturer is not Foxconn. Foxconn's humanoid relationship is with NVIDIA at the brain-provider tier; that is a separate arrangement that does not put Foxconn in the Apollo chain.

Apollo's operators-and-customers are Mercedes-Benz at Mercedes-Benz facilities, GXO at GXO facilities, and Jabil at Jabil facilities. Jabil holds two distinct roles in the Apollo graph: contract manufacturer for production (Apollo is built at Jabil) and operator-and-customer for the Jabil- internal enterprise pilot (Apollo runs in Jabil facilities for Jabil's own workflow). We track both roles separately on the same Jabil company record.

Agility Digit at GXO Flowery Branch is the simpler worked example. Agility Robotics is the manufacturer. GXO is the operator-and-customer at the GXO Flowery Branch deploy-site. The 100,000-tote milestone is verified by the customer of record (GXO). The operator state is verified at the customer surface; the manufacturer state is verified at Agility's surface.

Figure 02 at BMW Spartanburg is the same pattern at a different scale. Figure AI is the manufacturer. BMW is the operator-and-customer at the BMW Spartanburg deploy-site. The 30,000-vehicles-built milestone is verified by the customer of record (BMW); the chassis assembly work is accepted into BMW's normal quality-control process.

Bot Auto's Houston-to-Dallas commercial truckload is the worked example where operator and customer are distinct entities. Bot Auto is the operator and the manufacturer. The freight customer is the customer. Ryan Transportation is the brokerage that booked the load. Three separate corporate relationships are tracked separately on the deployment record.

Tesla Optimus at Tesla factories is the worked example where manufacturer and operator collapse. Tesla manufactures Optimus and operates Optimus at Tesla manufacturing lines. The customer of record is Tesla itself. Per the maker- facility-is-research discipline, the deployment is recorded at research maturity stage; deployment in the maker's own facility is not commercial deployment.

Source discipline

The manufacturer state is verified at the maker's product surface, the maker's SEC filings if the maker is public, and the contract manufacturer's disclosed production relationship if one exists.

The contract manufacturer is verified when the contract manufacturer or the maker publicly discloses the production relationship. Trade-press speculation about which contract manufacturer is producing what is not verified; we wait for the maker or the contract manufacturer to confirm. Apollo's contract manufacturer is Jabil because Apptronik disclosed the relationship with Jabil; trade-press assertions of Foxconn as Apollo's contract manufacturer do not survive primary-source verification.

The operator state is verified at the customer of record. The customer's own surface confirms operator state: the customer's press release, the customer's earnings call, the customer's investor disclosure, an on-site journalist report at the customer facility. The maker's announcement that a robot is deployed at a customer site is not verification of operator state on its own; we wait for the customer to confirm.

The customer state is verified at the billing relationship. For a Robots-as-a-Service contract, the customer's contract announcement plus the maker's contract announcement corroborate. For a hardware purchase, the customer's purchase order plus the maker's shipment confirmation corroborate.

Cap-flag application

A deployment record with a maker-asserted operator but no customer confirmation is cap-flagged at announced-not- confirmed. The maker statement is preserved as claim; the operator state stays cap-flagged until the customer confirms.

A deployment record with a manufacturer but no verified contract manufacturer is recorded with contract_manufacturer null. We do not assume a contract manufacturer relationship without primary-source disclosure; the field stays null rather than carrying a speculative entry.

A deployment record where operator and customer are different entities but the customer relationship is not fully disclosed (the operator confirms the deployment; the customer is referenced generically as "a Fortune 500 customer" without naming) is cap-flagged at customer- undisclosed. The operator state is verified; the customer state stays at honest-absence.

The framework applies to us

If we conflate the manufacturer with the contract manufacturer on a deployment record, we correct it. The Apollo equals Jabil contract-manufacturer assertion is the recursive worked example: the manufacturer is Apptronik; the contract manufacturer is Jabil; the trade-press conflation with Foxconn is not the verified state.

If we record an operator state on a maker assertion that does not survive customer-of-record verification, we re- anchor the deployment to the verified state and cap-flag the operator field until the customer confirms.

If a deployment ends and the operator does not announce the end, we record the deployment as ended at honest-absence on the end-cause field; the operator state moves to ended on the verified end date if one exists.

The correction is logged at /corrections. The original anchor is preserved in the source history.

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 operator-state changes, /methodology/people-state for the people graph that surfaces leadership at each company in the chain, /methodology/form-factor-taxonomy for the regulatory regime that governs each deployment.

The applied work: registry.deploy.report/deployments for the deployment records with manufacturer + operator + customer + contract_manufacturer + deploy-site per record.