A demonstration proves the vendor's day

THE OPERATOR'S MAP · Chapter: Twin & Machine · Episode 3 · 7 September 2026. The five chapters advance together each week — agent controls (Ship AI), the open-source stack (Sovereign Stack), governance (The AI Boardroom), evaluation (Beyond the Benchmark), physical AI (Twin & Machine). This chapter's earlier episodes are linked at the foot of the piece.

The Operator's Map is a weekly series for the people who have to run AI rather than admire it — five chapters, one per domain, all advancing together each week. This chapter teaches physical AI. Last week: what a digital twin actually certifies, and what the sim score cannot say. This week: what an operator owes a machine it did not build — how an acceptance test differs from a demonstration, and what belongs in one. Every technical idea gets restated in plain terms as we go.

Why this reaches your desk. A machine that moves mass in a building full of people carries its consequence in its actuators. A mobile manipulator in a warehouse aisle can put a loaded tote in motion at head height faster than the person beside it can step back; an automated driving system at freeway speed can carry a vehicle into a lane where people are working. Those are properties of the system class, stated as such, and no incident is alleged here. What decides whether that capacity is ever exercised in your building is not the vendor's demonstration. It is the one document that describes the machine on your floor, in your conditions, on your worst day — and the vendor never writes it. You do.

Terms that matter this episode

0 · Three records, read as an operator

0.1 On 26 August 2026 an autonomous-vehicle developer published a list of ten lessons from more than two hundred million miles without a driver. It is a self-disclosed record, on the company's own site, and two of the lessons are the whole of this chapter. Lesson five, verbatim: "Large-scale, closed-loop simulation is critical. It provides the most realistic assessment by mimicking real-world cause and effect." Lesson ten, verbatim: "True L4 maturity can only be safely achieved by a purpose-built system, validated on closed courses and hardened by the uncompromising experience of driving without a human in the car." The same post says, without hedging: "You can run billions of miles in simulation or with human supervision, but an AV system only truly matures when it is solely responsible for the driving task." The company's own safety hub records 220.6 million rider-only miles through March 2026.

0.2 Sit with what that vendor is saying about itself. Simulation is critical. Closed courses validate. Neither is the thing that matures the system. The thing that matures it is the road, with nobody in the seat. That is the most sophisticated maker of its class telling you, in its own words, where its own evidence stops.

0.3 On 4 August 2026 a humanoid-robot maker published its deployment process in three phases. Phase one, at the vendor's site: "we validate a first use case in a controlled environment at our own facility." Phase two, at yours: "bring Digit to your facility and stress-test the application in your actual environment." Phase three: "officially move Digit onto your production line, measuring uptime, throughput, reliability, and operational impact," leaving the customer with "90 days of operational data quantifying the robot's return on investment." The page also states that workcells containing the robot "have passed OSHA-recognized Nationally Recognized Test Lab (NRTL) field inspections."

0.4 That is a vendor publishing its own ladder, and the ladder is honest about its shape: phase one is the vendor's floor, phase two is yours. What the page does not publish is any pass mark. Uptime, throughput and reliability are measured; the number at which the customer may refuse is not stated. The document is a process. It is not yet a test.

0.5 On 17 June 2026 the first vendor filed Part 573 Safety Recall Report 26E035 with the National Highway Traffic Safety Administration, covering 3,871 units of its fifth-generation automated driving system. The defect, in the filing's words: "Under certain circumstances, the AV may enter and drive at speed in freeway construction zones due to inappropriately prioritizing the avoidance of other freeway hazards and/or failing to recognize the construction zone." The safety risk, in the filing's words: "Driving at speed in a freeway construction zone increases the potential for collisions." The chronology records one event on 11 April, five on 19 April, and seven on 18 May 2026, a Field Safety Committee that imposed freeway restrictions after each cluster, and a Safety Board decision to recall on 8 June. The remedy is software.

0.6 Read the three records together and the argument writes itself. A system validated on closed courses, hardened by hundreds of millions of miles, described by its maker as mature, still produced a defect its maker had to file with a regulator. The record names no injury and this chapter alleges none. What the record establishes is narrower and more useful: the vendor's evidence, however deep, described the vendor's envelope. The construction zone was outside it.

1 · The demonstration report, clause by clause

1.1 Site. A demonstration is run where the vendor chooses. That is not a criticism; it is the definition. The vendor's facility has the floor the vendor tuned for, the racking the vendor measured, the lighting the vendor's cameras were calibrated under, and the people who know where not to stand. Phase one of the published humanoid ladder says exactly this: "a controlled environment at our own facility."

1.2 Payload and task. The demonstration carries the tote the vendor packed, at the mass the vendor chose, in the orientation the vendor placed it. Your totes are heavier on Mondays, wet in monsoon season, and stacked by whoever was on shift.

1.3 Scenario selection. The demonstration shows the runs that worked. Nothing dishonest is happening. A demonstration is a showing, and a showing selects. The runs that did not work were the vendor's development data, not your evidence.

1.4 Pass mark. There is none. A demonstration ends when the audience is satisfied. No number was written before it began at which the vendor would have said "we failed."

1.5 Validation data. The demonstration reports what the machine reports about itself: its own success count, its own cycle time, its own log. There is no independent measurement on the other side of the comparison, because a demonstration is not a comparison.

1.6 Envelope. Unstated. The demonstration does not tell you which conditions it covered, because a demonstration is not a claim about conditions. It is a claim about a day. The vendor's day.

1.7 That is what a demonstration proves. A demonstration proves the vendor's day; a test proves your floor. Every demo is run on the vendor's terms, in the vendor's envelope. The operator's acceptance test is the only artifact that describes the machine in your building, on your worst day.

2 · The acceptance-test specification, clause by clause

2.1 Site. Your floor. Your aisle widths, measured. Your floor flatness, measured. Your lighting at the hour the night shift runs, measured, because a camera that reads a pallet edge at noon may not read it at 03:00 under a failed fluorescent tube. Your people, in their actual high-visibility vests, moving at their actual pace.

2.2 Payload and task. Your heaviest tote and your lightest, your worst-packed and your wettest, in the orientations your line actually produces. If the vendor's demonstration carried fifteen kilograms and your line carries twenty-two, the demonstration was of a different machine.

2.3 Scenario selection. Named in advance, by you, including the ones the vendor would not have chosen to show: the cross-aisle with the blind corner, the dock door that opens into direct sun, the person who steps out from behind a rack, the emergency stop pressed mid-lift with a loaded tote at height.

2.4 Pass mark. Written before the machine arrives. A tolerance for every measured quantity. A number at which you refuse delivery, agreed in the contract, not negotiated on the day.

2.5 Validation data. Measured by you, or by an instrument you control, not by the machine's own log. A stopwatch on cycle time. A force gauge at the gripper. A person with a clipboard counting stops that the log did not record.

2.6 Envelope. Written, at the end, as a statement: what was tested, in what conditions, to what tolerance, and what was not. The last clause is the one that matters. It is the fence from last week's chapter, applied to a machine instead of a model.

2.7 Re-run. A share of the tests repeated on your floor after the machine is installed, even if the vendor ran the full set at its own facility first. A cadence for repeating them for as long as the machine runs.

2.8 Set the two documents side by side and the pattern is exact. Every clause the demonstration leaves to the vendor is a clause the acceptance test returns to you. The demonstration is not a weaker acceptance test. It is a different document, answering a different question, and the question it answers is not the one you need answered before the machine moves mass in your building.

3 · What the standards actually say, and the word they do not use

3.1 The current industrial-robot standard is ISO 10218, revised in 2025 in two parts. Part 1 covers the robot as partly completed machinery; the issuing body's page lists it as edition 3, published February 2025, 95 pages. Part 2 covers robot applications and cells; its page lists edition 2, February 2025, 223 pages, and describes the scope in one sentence: "It addresses the integration, commissioning, operation, maintenance, and decommissioning of robots within industrial settings." The body of both parts is paywalled, and this chapter quotes only what the issuing body publishes on the open page.

3.2 Here is the finding that shapes everything below. The phrase acceptance test appears in none of the fetched primary robot standards. Not on either ISO 10218 page, not in the mobile-robot standard's release, not in the committee draft for humanoids. The standards say commissioning, verification, validation. Commissioning is a phase. Verification and validation are duties, and in the 2025 edition they are the maker's duties: a comparative analysis of the 2011 and 2025 editions, published as a preprint in February 2026 and cited here by class because it is not a standards body, describes the manufacturer's obligation to verify and validate design elements against the requirements clauses and an annex mapping each requirement to its verification method. That mapping is what the vendor owes. It is not an acceptance test, because it was written against the standard, not against your floor.

3.3 The industry association that maintains the United States adoption published a standards update on 4 September 2026. Its central line: "organizations should evaluate the entire robot application — not simply the robot arm." It continues: "The standards require an assessment when a robot system is integrated into a particular application." And it names the layer that belongs to you: ANSI/A3 R15.06-2025 "incorporates the 2025 ISO 10218 Parts 1 and 2," and the United States series "also includes Part 3, which addresses user requirements such as interactions with integrators, management of change, training and risk-assessment considerations." The same post describes all of these as "voluntary industry consensus standards."

3.4 The association's FAQ on the 2025 revision, dated 20 March 2025, carries the sentence that comes closest to this chapter's thesis in any primary: the terms collaborative robot and collaborative operation are gone from the standard, and "'Collaborative application' is used instead, as only the actual use of the robot can be designed, tested, and confirmed as a collaborative application." Read that as an operator. The standard itself refuses to call a robot collaborative. Only the application, in its actual use, can be tested and confirmed. A demonstration is not the actual use.

3.5 For mobile robots the picture is thinner. ANSI/A3 R15.08-2, released 10 October 2023, "specifies requirements for integrating, configuring, and customizing an IMR or fleet of IMRs into a site." The release says the committee "will next develop R15.08 Part 3, which will provide safety requirements for users." As of the fetch on 7 September 2026, no Part 3 is listed on the association's site. The user duties for a mobile robot are a promise, not a page.

3.6 For humanoids and other self-balancing machines there is a committee draft, ISO/CD 25785-1, at stage 30.60 on 7 September 2026, which is the close of the committee comment period. Its abstract defines the class: "'actively controlled stability' refers to a robot that requires an active control in order to remain balanced and could become unstable in the absence of power." It also says Part 2, on integration, is "to be developed separately." There is nothing to certify a humanoid to today. Any claim that one is certified is, by class, a claim against a document that does not yet exist.

3.7 The regulator's page is older than all of it. The Occupational Safety and Health Administration's robotics standards page opens: "There are currently no specific OSHA standards for the robotics industry." The consensus standards it lists are prefaced "These are NOT OSHA regulations," and the robot standard it names is "R15.06 (ANSI/RIA R15.06-2012)," described as "the U.S. National Adoption of the ISO 10218-1,2:2011." The 2025 edition is not on the page.

3.8 For autonomy on roads, UL 4600, the Standard for Evaluation of Autonomous Products, third edition dated 17 March 2023, covers "safety case construction, risk analysis, testing procedures, tool qualification, autonomy validation, and data integrity." That is safety-case vocabulary, and it is voluntary. The federal regulator's own notice in the Federal Register on 31 July 2026 states: "On March 10, 2026, NHTSA announced the commencement of a rulemaking process to establish performance requirements for ADS, which is expected to culminate in establishment of one or more FMVSS." Expected to. There is no United States performance standard for an automated driving system in force today; the same day's exemption grant for one developer permits "not more than 2,500 exempted vehicles" per twelve-month period for two years under conditions, which is the shape regulation takes when the standard does not yet exist.

3.9 Put the whole shelf together. The maker's duties are written, voluntary and paywalled. The integrator's duties are written and voluntary. The user's duties are a Part 3 that exists for arms and is promised for mobile robots. The regulator cites the 2011 edition. The humanoid standard is a draft. The road standard is a rulemaking that has commenced. And in none of these does the phrase acceptance test appear. Out of scope is not out of risk. The scope of every one of those documents ends before your floor, and your floor is where the mass moves.

4 · The analog: what a test entry contains when a regulator writes the list

4.1 There is one public instrument that does not stop at the phase. It does not say "commission the device." It says what each test must contain, field by field, and it has said so for two decades. It is 14 CFR Part 60, the rule under which the Federal Aviation Administration qualifies flight simulators, and this chapter used it last week for a different purpose. Title 14 of the Code of Federal Regulations was current as of 3 September 2026 when this was written, a date anyone can re-check at the eCFR currency record.

4.2 Appendix F defines the document at the center of it. A Qualification Test Guide is "the primary reference document used for evaluating an aircraft FSTD. It contains test results, statements of compliance and capability, the configuration of the aircraft simulated, and other information for the evaluator to assess the FSTD against the applicable regulatory criteria." It defines an objective test as "a quantitative measurement and evaluation of FSTD performance," a subjective test as "a qualitative assessment of the performance and operation of the FSTD," and validation data as "objective data used to determine if the FSTD performance is within the tolerances prescribed in the QPS."

4.3 Then Appendix A, paragraph 2.e(10), lists what the guide must contain for each objective test. Verbatim, in the regulation's own lettering:

"(a) Name of the test. (b) Objective of the test. (c) Initial conditions. (d) Manual test procedures. (e) Automatic test procedures (if applicable). (f) Method for evaluating FFS objective test results. (g) List of all relevant parameters driven or constrained during the automatically conducted test(s). (h) List of all relevant parameters driven or constrained during the manually conducted test(s). (i) Tolerances for relevant parameters. (j) Source of Validation Data (document and page number). (k) Copy of the Validation Data (if located in a separate binder, a cross reference for the identification and page number for pertinent data location must be provided). (l) Simulator Objective Test Results as obtained by the sponsor. Each test result must reflect the date completed and must be clearly labeled as a product of the device being tested."

4.4 Twelve fields. Read them against the two documents above. Initial conditions is clause 2.1. Tolerances is clause 2.4. Source of validation data, down to document and page number, is clause 2.5. And the final field, results "clearly labeled as a product of the device being tested," is the rule that stops a result obtained on a different machine, or a different day, from standing in for this one.

4.5 The same appendix, paragraph 2.h, settles where the tests are run. "The sponsor may elect to complete the QTG objective and subjective tests at the manufacturer's facility or at the sponsor's training facility." And then: "If the tests are conducted at the manufacturer's facility, the sponsor must repeat at least one-third of the tests at the sponsor's training facility in order to substantiate FFS performance. The QTG must be clearly annotated to indicate when and where each test was accomplished." The vendor's floor is permitted. It is not sufficient. A third of the evidence must be re-made on yours, and the record must say which third.

4.6 And section 60.19 settles the cadence. No sponsor may use the device for training unless it "accomplishes all appropriate objective tests each year as specified in the applicable QPS" and "completes a functional preflight check within the preceding 24 hours." Every year, the full objective set. Every day, a functional check. Acceptance is not a gate you pass once. It is a schedule.

4.7 None of this is transferable as a tolerance table. A flight simulator models a type-certificated airframe with a flight-test comparator; a warehouse robot has neither, and nothing in Part 60 tells you how many newtons a gripper may apply to a tote. What transfers is the list. Twelve fields, a re-run share, a cadence. All three are documents, all three are free, and a vendor's ability to fill them in is the single most informative thing you will learn before the machine arrives.

5 · The worked artifact: the acceptance-test specification you hand the vendor

5.1 This is the document to take to work. It is one test entry, modeled field for field on the twelve in Part 60, with three additions the robot case needs and the regulation did not: an on-site re-run share, a re-run cadence, and an envelope statement. It is filled in for one application class, a mobile manipulator picking totes from racking in a warehouse aisle shared with people, and it names no vendor. Change the numbers to yours; keep the fields.

5.2 How to read a completed entry. Three rules.

1. An empty field 6 means there is no test. A run with no tolerance is a demonstration wearing a test's clothes. If the vendor's proposal arrives with fields 1 through 5 filled and field 6 blank, you have been sent a demonstration report.
2. Field 12's second list is the product. An entry whose envelope statement names nothing that was not tested has not been scoped. It has been advertised. Everything the machine will meet on your floor that is not in the first list is, by the entry's own admission, unmeasured.
3. Field 5 must not point at the machine. A stopping time read from the machine's own log is the machine reporting on itself. The regulation's word is validation data, and its definition is data used to determine whether the device is within tolerance, which cannot be the device's own claim.

5.3 Notice what the entry did not do. It did not dispute the vendor's demonstration. It did not ask for a better one. It described the machine in this building, on the night shift, with the wet floor and the person who steps out. That is the only document in the whole exchange that does.

6 · Two anchors outside the United States, dated as verified

6.1 India. There is no Indian instrument in force that names an acceptance test, or any test, for a robot moving among people, and this chapter says so rather than implying one. What exists is procurement and program fact. The Press Information Bureau's release of 25 March 2026, reporting a Lok Sabha answer of the same date, records that the IndiaAI Mission was launched "with outlay of Rs. 10,372 crore" and that "more than 38 thousand GPUs for common compute facility have been onboarded through the AI compute portal." That is compute for training, not a duty on the floor. Where the machine's cameras process personal data, which a machine navigating a floor full of people does by construction, the Digital Personal Data Protection Rules, 2025 apply. The Bureau's explainer of 17 November 2025 records that the Rules were notified on 14 November 2025 with "an eighteen-month period for phased compliance," and that Significant Data Fiduciaries "must conduct independent audits and carry out impact assessments" and "must also follow stricter checks while using new or sensitive technologies." A robot on your floor is a new technology processing personal data. The audit clock is the only Indian clock that touches it, and it does not mention the robot. One further Indian instrument reads as an acceptance standard rather than a demonstration standard, though it binds only securities intermediaries: SEBI's Regulation 16C, in force since 10 February 2025, makes any regulated person using AI tools, "either designed by it or procured from third-party technology service providers," "solely responsible" for, among other things, "the output arising from the usage of such tools and techniques it relies upon or deals with." It binds liability for the output, not a test of it. The operator owns the result whether or not the operator ever measured the machine, which is the strongest reason to measure it. All three pages were read on 7 September 2026.

6.2 The Gulf. For the financial-sector reader, the Central Bank of the UAE's Model Management Standards, listed in force on the regulator's rulebook and read there on 7 September 2026, put "Artificial Intelligence" among the model types in scope, state that their practices must be implemented by any bank in the UAE that employs models for decision-making, and set the bar as a minimum rather than a showing: "Both Part I and Part II constitute the minimum requirements to be met by a model and its management process so that the model can be used effectively for decision-making." That is the strongest Gulf instrument for a model, and it says nothing about a machine on a floor. The instrument that does is Dubai's. Dubai has written the operator's re-run into law, and it is the clearest instance of this chapter's argument in any instrument fetched. Law No. (9) of 2023, issued 6 April 2023 and in force ninety days after gazette publication, requires in Article 6 that "No Autonomous Vehicle may travel on a Road unless it is licensed by the RTA," requires in Article 7 that "Technical inspections must be conducted on Autonomous Vehicles," and states in Article 14 that "An Operator will be liable for compensating for any damage to property or harm to individuals caused by the Autonomous Vehicle." Then the implementing bylaw, Administrative Resolution No. (939) of 2025, issued 10 November 2025 and in force on publication, lists in Article 3 what a vehicle must carry to be licensed. Item 1 is a certificate from the country of manufacture demonstrating "that it has undergone all required safety tests and has satisfied the standards of those tests." Item 2 is "a certificate issued by the manufacturer confirming that the Autonomous Vehicle, in its category and class, has undergone test runs on public Roads in the country of manufacture or any other country." Both are the vendor's day. Item 4 is the operator's floor: "proof that the Autonomous Vehicle has undergone operational test runs in the Emirate, demonstrating the Vehicle's performance under the prevailing climatic conditions, providing the RTA with the resulting test data, and confirming that all observations recorded during those test runs have been addressed." The maker's tests are required and insufficient. The re-run in the Emirate's own heat, with the data handed over and the observations closed, is a separate item on the same list. That is field 10 of the worked artifact, written by a regulator. Both instruments were read at the Dubai legislation portal on 7 September 2026.

7 · The strongest objection

7.1 The sharpest pushback is that the vendor already ran this test, better than you can, on more units, over more hours, and that an operator with a stopwatch and a wet mop is replicating a fraction of a validation program worth more than the operator's whole site. The published records support the objection. Two hundred million miles. Ninety days of operational data. A field inspection by a nationally recognized test laboratory. Against that, forty runs in aisle B-14 look like theater.

7.2 Here is why the objection does not dispose of the argument, and the vendor's own record is the answer. The two hundred million miles were the vendor's envelope, and the defect filed on 17 June 2026 was outside it. Not because the program was weak. Because an envelope has an outside, by definition, and the outside is where your building is. Forty runs in aisle B-14 are not a fraction of the vendor's program. They are the only forty runs in existence that were in aisle B-14.

7.3 And the objection concedes the point about documents. If the vendor has run this test better than you can, the vendor can fill in fields 6, 7 and 12 for your site before delivery. Ask. The vendor that can is doing the thing this chapter asks for, and the argument does not apply to it. The vendor that cannot has told you which document it has been sending you.

8 · What would falsify this

8.1 It is a claim about the prevailing pattern, not every vendor. A vendor whose delivery package already contains, for the customer's site, named tests with tolerances written before delivery, validation data sourced outside the machine's own log, a re-run share on the customer's floor, and an envelope statement listing what was not tested, is doing what this chapter asks for. One public, checkable counterexample would confine the argument to the rest of the field. None was found in this chapter's search, and absence of publication is not absence.

8.2 No published incident is attributed to the absence of an acceptance test. The recall record establishes a defect outside a validation envelope. It does not establish that an operator's test would have caught it, and this chapter does not claim so.

8.3 A standards body could publish the user's Part 3 for mobile robots, or the humanoid draft could reach publication with a commissioning test list. Either would make the artifact above the cheapest way to have been early rather than the only way to have been covered.

8.4 The numbers in the worked entry are illustrative. Aisle width, lux, tote mass, stopping distance and the one-second ceiling are stated so the form is not blank. They are not a recommendation for any site, and a reader who copies them without measuring their own floor has filled in a demonstration report.

The close

A demonstration proves the vendor's day. Every one of them is run on the vendor's terms, in the vendor's envelope, and the most rigorous vendor in the class has told you in its own words that the envelope has an outside. An acceptance test proves your floor, and it is the only artifact in the whole exchange that describes the machine in your building, on your worst day, with your numbers written down before it arrived. The standards do not use the phrase. The regulator cites an edition four years old. The Gulf wrote the re-run into law and India wrote an auditor onto the camera. In between, the list of thirteen fields is free, and whether the vendor can fill it in for your site is the first result.

Only the tested control counts. Here, that is an acceptance test you specified.

What to ask your team

1. For the last machine we accepted: where is the document with our aisle widths, our lighting and our payloads in it, and which of the runs in it were ordered by us rather than shown to us?
2. For every measured quantity in that document, what was the number at which we would have refused delivery, and was it written before the machine arrived?
3. Which of our results were read from the machine's own log, and which from an instrument we control?
4. What share of the vendor's test set did we repeat on our own floor, and what is the cadence for repeating it on the next software release?
5. Where is the sentence that lists what we did not test, and whose name is under it?

The series

This is Episode 3 of The Operator's Map — a weekly series in five chapters, advancing together: Ship AI teaches agent controls, Sovereign Stack the open-source stack, The AI Boardroom governance, Beyond the Benchmark evaluation, Twin & Machine physical AI. Where this chapter's argument meets the validation-envelope record of a public incident, the deep companion is the special edition on the simulation that was accurate everywhere except the one place it mattered. Next week, this chapter teaches why the test environment is where the incident happens: weaker controls because controls get in the way, and real credentials because synthetic ones do not reproduce the bug. Subscribe to follow the map as it fills in.

Only the tested control counts.

Sources

Every source below is a standards body, a regulator, a government publisher, or a vendor's self-disclosed record named by record. No press coverage, analyst note or demonstration video is cited for any claim. Every URL was fetched and confirmed on 7 September 2026; the two that refused an automated client on that date are listed under the cuts, with what replaced them.

Cut in verification, and why

• The NHTSA press release of 30 July 2026 and its named consortium for AV performance standards. The regulator's press host refused an automated client on 7 September 2026. The claim that no United States ADS performance standard is in force was re-sourced to the Federal Register notice of 31 July 2026, which states the rulemaking has commenced. The consortium, its funding and the "first since 2017" line were cut, because none of the three appears in the fetched primary.
• A per-vehicle deployment claim about driverless trucks, dated 26 August 2026. Self-disclosed and quotable, and it carried no published test evidence to set against the claim. Cut as not load-bearing; naming a vendor for a capability claim alone adds a name without adding an argument.
• A humanoid maker's data-platform announcement of 25 August 2026. Nothing in it concerns acceptance, safety or certification. Cut.
• ISO 13482, IEC 61508 and UL 3300. Issuing-body pages returned errors or were not reached on the run date. Cut entirely; no claim rests on a standard the reader cannot open.
• A national laboratory's legged-robot test method, reported 20 August 2026. Reached only through secondary coverage. Cut; it would have been the one primary that names test methods for a legged machine, and it is worth a future pass at the issuing body.
• Any quotation from the body of ISO 10218-1 or -2. Paywalled. Only the issuing body's open scope text is quoted, and the verification-and-validation mapping is described by class through the preprint rather than quoted from the standard.
• The UAE federal AI strategy page and the Saudi data and AI authority's home page. Both refused or returned an interstitial to an automated client on 7 September 2026. The Gulf anchor was re-sourced to the Dubai legislation portal, which answered, and which turned out to carry the stronger instrument for this chapter's argument.
• The IndiaAI compute portal's own status page. The portal renders as a script application with no readable figures to an automated client. The GPU count was re-sourced to the Press Information Bureau release reporting the Lok Sabha answer of 25 March 2026.
• Any Indian robot-safety instrument. None was found in force. The chapter says so on the page rather than substituting a general AI instrument that does not touch the machine.
• A worked entry drawn from a real deployment. No operator's acceptance test could be read at a primary. The entry in section 5 is constructed and system-class, names no vendor or site, and is labeled as such where it appears and again in section 8.4.