Toolkit · Technology

The Autonomous Vehicle Deployment, Crash Investigation, and Robotics Compliance Toolkit

49 U.S.C. § 30118

Type: Toolkit
Jurisdiction: National
Date: 2024-07-21
Topic: Technology

A working toolkit for automated vehicle and robotics matters. Tool 1 is a preservation letter naming every log type that will otherwise age out. Tool 2 is an operational design domain definition template and Tool 3 a discovery request set with protective order terms. Tool 4 outlines a safety case and Tool 5 a first responder interaction protocol. Tool 6 is a crash intake sheet, Tool 7 an expert scope memorandum, and Tool 8 a recall decision memorandum. Tool 9 collects the statutes, regulations, and decisions that govern the field.

The Autonomous Vehicle Deployment, Crash Investigation, and Robotics Compliance Toolkit

Technology > Autonomous Vehicles and Robotics | Published 21 July 2024 - Updated 14 June 2026 | UpLaw - uplaw.us

⚠️ Tool 1 is time-critical. Perception logs and third-party video have the shortest retention in the case. Send it in days.

TOOL 1 — PRESERVATION LETTER

[Date] — SENT BY EMAIL AND CERTIFIED MAIL

[Manufacturer — General Counsel] · [Fleet operator] · [Remote assistance provider] · [Sensor / mapping vendors]

Re: Litigation hold — incident of [date, time], [location] — vehicle [VIN / fleet ID] — claimant [name]

This firm represents [claimant] in connection with the incident described above. Litigation is anticipated. You are directed to preserve, and to suspend any automatic deletion or overwriting of, the following, in native format, together with documentation sufficient to interpret each:

Event data recorder output for the subject vehicle, as described in 49 C.F.R. Part 563

Perception system logs — all object detections, classifications, confidence values, and track histories, frame by frame, for the trip and not less than five minutes preceding the event

Planning and prediction logs — the trajectory selected, all candidate trajectories evaluated, predicted paths of other road users, and the basis for the selection

Control and actuation logs — steering, throttle, and brake commands issued and executed

All raw and processed sensor data — camera, radar, lidar, ultrasonic, and inertial — from every sensor and every angle

Automation state history — whether the system was engaged, engagement and disengagement events with timestamps, and any takeover request issued

Driver monitoring data — gaze, head position, hand position, and the complete alert and escalation history for the trip

Localization and map data — the map version in use and the vehicle's computed position throughout

Software and firmware version history, including any update deployed in the thirty days before or after the event

Operational design domain definition in effect at the time, and any domain-exit detection events

Remote assistance session records, including audio, video, and operator commands

Maintenance, repair, and sensor calibration records for the vehicle

Simulation, test, and validation records for scenarios materially similar to this event

Fleet-wide incident and disengagement records involving the same failure mode

Internal communications concerning this incident or the failure mode

Marketing, sales, training, and owner materials describing the system's capabilities

The vehicle itself must be preserved in its post-incident condition and must not be repaired, recalibrated, or returned to service without notice and an opportunity to inspect.

⚠️ If any of the above is held by a third party, you are directed to notify them of this hold and to confirm to us that you have done so.

Please confirm in writing within seven days that this hold is in place and identify the custodian of each category.

[Signature]

📌 The distinction between this and "please preserve the black box data" is the entire case. Items 2, 3, 7, and 14 are the ones that will not otherwise survive.

TOOL 2 — OPERATIONAL DESIGN DOMAIN DEFINITION

Operational Design Domain — [System name], version [x.y], effective [date]

1. Geographic scope. [Specific mapped areas, by boundary description. Attach the map.] Jurisdictions: [state and locality list, with the authorization on file for each.]

2. Roadway types. [Included: e.g., divided highways with controlled access; surface streets with posted limits at or below __ mph. Excluded: e.g., unpaved roads, private property, construction zones without mapped updates.]

3. Speed range. [Minimum and maximum operating speeds.]

4. Environmental conditions. [Precipitation limits; visibility minimums; wind limits; ambient temperature range; road surface conditions.] Excluded: [snow accumulation, standing water above __, fog below __ visibility.]

5. Lighting. [Daylight only / day and night with specified illumination assumptions.]

6. Traffic conditions. [Density assumptions; excluded scenarios such as emergency scenes, active police direction, or unmapped detours.]

7. Other road users. [Assumptions about pedestrians, cyclists, micromobility, and animals, and the detection performance basis for each.]

8. Domain exit detection. [How the system determines it has left or is about to leave the domain, and the latency of that determination.]

9. Fallback behavior. [The minimal risk condition and how it is achieved; for conditional automation, the takeover request timing and its human factors basis.]

10. Change control. Any expansion requires [validation steps] and approval by [role]. Version history attached.

⚠️ Write this as though a plaintiff's expert will read it aloud to a jury, because one will. A domain defined so broadly that the system routinely encounters conditions it cannot handle is a design argument the plaintiff does not have to construct.

TOOL 3 — DISCOVERY REQUEST SET

Documents

☐ The operational design domain definition in effect, and every prior and subsequent version ☐ The complete safety case — hazard analysis, validation plan and results, residual risk acceptance, and sign-offs ☐ All simulation and test records for scenarios materially similar to the incident ☐ Perception system performance data by condition — lighting, weather, object type, and object appearance ☐ All internal analyses of the failure mode at issue, whether or not prepared for litigation ☐ Fleet-wide disengagement and incident data for the same failure mode, for [period] ☐ Every early warning report submitted under 49 C.F.R. Part 579 for the platform ☐ All defect determinations and reports under 49 U.S.C. § 30118 and 49 C.F.R. Part 573 ☐ All submissions to and correspondence with regulators concerning the platform, including under 49 U.S.C. § 30166 ☐ Any exemption application and grant under 49 U.S.C. § 30113 and 49 C.F.R. Part 555 ☐ Certification documentation under 49 U.S.C. § 30115 against 49 C.F.R. Part 571 ☐ Software release notes and change logs for versions deployed in [period] ☐ Update governance procedures and the deployment record for the subject vehicle ☐ Marketing, sales training, and owner materials describing system capability ☐ Remote assistance operator training materials and performance standards ☐ Maintenance and calibration procedures, and the subject vehicle's records

Protective order terms to negotiate

☐ Attorneys-eyes-only tier for source code, model architecture, and training methodology ☐ Secure review facility, logged access, printout limits, and a designated reviewer list ☐ Native-format production with interpretation documentation for every log type ☐ Right to re-run identified simulation scenarios under supervision ☐ Prohibition on use outside this litigation, with a return-or-destroy obligation ☐ Procedure for challenging designations, with the burden on the designating party ☐ Carve-out permitting disclosure to regulators where a safety obligation requires it

⚠️ Insist on interpretation documentation in the order itself. Data produced without it is data withheld, and litigating that after production is far harder than providing for it in advance.

TOOL 4 — SAFETY CASE OUTLINE

Safety Case — [System], version [x.y]

1. Scope. The system, the vehicle platform, and the operational design domain to which this case applies.

2. Safety goals. What the system is designed to achieve, stated measurably.

3. Hazard identification. Systematic enumeration of hazards, by subsystem and by scenario, with the method used.

4. Risk assessment. Severity, exposure, and controllability for each hazard.

5. Controls. The design, procedural, and operational controls addressing each hazard, traced to the hazard list.

6. Verification. How each control was verified — analysis, simulation, closed course, or on-road — with results.

7. Validation. Evidence that the system as a whole achieves the safety goals within the domain, with the coverage rationale for the scenario set.

8. Domain exit and fallback. Detection method, latency, and the minimal risk condition; for conditional automation, the takeover request timing and its human factors basis.

9. Perception performance across conditions, including object type, appearance, mobility devices, lighting, and weather. Performance variation is a safety finding, not a footnote.

10. Cybersecurity. Threat model, controls, and the treatment of a security compromise as a safety hazard.

11. Field monitoring. How incidents, disengagements, and near misses are captured, classified, and escalated.

12. Update governance. Identification, prioritization, validation, staged deployment, and rollback for safety-relevant changes.

13. Residual risk. What remains, why it is acceptable, and who accepted it — by name and role.

14. Change control. Version history, and the approval required for domain expansion.

⚠️ Every line of this document is discoverable. Write it accurately and without overclaiming. A safety case that promises more than the system delivers is the plaintiff's best exhibit; one that honestly documents residual risk and the reasoning behind it is a defense.

TOOL 5 — LAW ENFORCEMENT AND EMERGENCY RESPONDER PROTOCOL

[Operator] — First Responder Interaction Guide — [vehicle type], [jurisdiction]

Identifying the vehicle. [Markings, fleet number location, and how to tell an automated vehicle from a conventional one.]

Contacting us. 24-hour number: [number]. A live remote operator answers. Provide the fleet number and location.

Stopping the vehicle. [How the vehicle responds to emergency lights and sirens; how to signal it to pull over; how remote assistance can bring it to a stop.]

Manual override. [Location of the emergency stop control; how to place the vehicle in a safe state; whether it can be driven manually and how.]

High-voltage and battery safety. [Cut-off location, hazard markings, and post-collision precautions.]

Occupants. [How to open doors, including in a power-loss condition; how to communicate with occupants through the vehicle.]

Towing and recovery. [Approved methods; what must not be done; who to call before moving the vehicle.]

Data. [Who to contact for incident data; the operator's law enforcement request policy and the process for a lawful demand.]

Crash reporting. [Our obligations under [state] law, our reporting contact, and how we coordinate with the investigating agency.]

📌 Deliver this in person to local agencies before launch, not as a filing. The relationship built before the first incident is worth more than the document.

TOOL 6 — CRASH INTAKE SHEET

☐ Date / time: _______ Location: __________ Weather / lighting: __________ ☐ Vehicle: VIN _______ Fleet ID: _______ Operator: __________ Manufacturer: __________ ☐ Level of automation: ☐ 2 ☐ 3 ☐ 4 — Source of this determination: __________ ☐ System engaged at the time? ☐ yes ☐ no ☐ unknown — Basis: __________ ☐ Human aboard? ☐ none ☐ safety operator ☐ passenger(s) ☐ owner-driver ☐ Takeover requested? ☐ yes — time before event: ______ ☐ no ☐ unknown ☐ Inside the operational design domain? ☐ yes ☐ no ☐ unknown — Domain version: _______ ☐ Software version: _______ Update within 30 days? ☐ before ☐ after ☐ no ☐ Remote assistance involved? ☐ yes — session ID: _______ ☐ no ☐ Other parties: ☐ vehicle ☐ pedestrian ☐ cyclist ☐ fixed object ☐ other: _______ ☐ Injuries: __________ Fatality? ☐ yes ☐ no ☐ Police report number: _______ Agency: __________ ☐ State deployment crash report filed? ☐ yes — date: _______ ☐ not required ☐ Preservation letter sent: _______ Recipients: __________ ☐ Vehicle preserved / repaired? ☐ preserved ☐ ⚠️ repaired — note date and by whom: _______ ☐ Third-party video identified? ☐ traffic ☐ business ☐ other vehicles ☐ none — requested: _______ ☐ Recall history checked: _______ Early warning reports reviewed: _______ ☐ Similar state incident reports found: __________ ☐ Potential defendants: ☐ manufacturer ☐ software developer ☐ sensor vendor ☐ map vendor ☐ fleet operator ☐ remote supervisor ☐ maintenance provider ☐ human occupant ☐ other driver ☐ Experts needed: ☐ perception ☐ control software ☐ human factors ☐ reconstruction ☐ regulatory ☐ damages ☐ Insurance identified: ☐ personal auto ☐ commercial fleet ☐ product liability ☐ cyber ☐ excess — limits: _______

TOOL 7 — EXPERT SCOPE MEMORANDUM

Privileged and Confidential — Attorney Work Product

Expert Scope — [matter], [expert name], [discipline]

1. Question presented. [One sentence. What is this expert being asked to determine?]

2. Materials provided. [List by category, with production numbers. Note anything requested and not produced.]

3. Specific tasks. ☐ Perception expert: determine when the object was first detectable by each sensor modality; when it was detected; how it was classified and with what confidence; whether classification changed; and whether detection performance was consistent with the manufacturer's own stated performance. ☐ Control software expert: determine what trajectory was selected, what alternatives were evaluated, what the fallback logic was, and whether the system detected or should have detected a domain exit. ☐ Human factors expert: determine whether the takeover request provided adequate time, whether the driver monitoring system was adequate to establish availability, and what the alert history shows about attention. ☐ Reconstruction expert: integrate the log data with physical evidence; determine speeds, positions, and whether the collision was avoidable at each candidate intervention point. ☐ Regulatory expert: determine applicable standards, certification status, and defect reporting compliance.

4. Alternative design opinions sought. [Identify candidates: narrower operational design domain; different sensor modality or placement; more conservative fallback; different classification threshold; earlier takeover request; enforced driver attention.] ⚠️ The narrower-domain opinion is frequently the strongest and the most defensible.

5. Reliability foundation. [How the methodology will be established — peer-reviewed basis, error rate, standards, and whether it was developed independently of litigation.]

6. Deliverables and schedule. [Preliminary assessment, report, deposition availability.]

TOOL 8 — RECALL DECISION MEMORANDUM

[Manufacturer] — Safety Defect Evaluation — [issue], [date]

1. Issue. [Describe the observed behavior or condition, and how it was identified — field report, fleet pattern, internal testing, supplier notice.]

2. Affected population. [Vehicles, software versions, and configurations. Quantify.]

3. Field evidence. [Incident count, severity distribution, rate per exposure, and trend.]

4. Root cause. [Established, suspected, or unknown, with the analysis supporting it.]

5. Safety analysis. [Does this present an unreasonable risk to safety? Address severity, exposure, and the realistic worst case, not only the observed cases.]

6. Determination. ☐ Safety-related defect under 49 U.S.C. § 30118 ☐ Noncompliance with 49 C.F.R. Part 571 ☐ Neither — with the reasoning for whichever conclusion is reached.

7. Reporting. [If a defect or noncompliance: the 49 C.F.R. Part 573 report date, and the notification plan under 49 U.S.C. § 30119.]

8. Remedy. [Software update, hardware replacement, or operational restriction, under 49 U.S.C. § 30120. Include the validation performed on the remedy itself.]

9. Interim measures. [Domain restriction, feature disablement, or fleet grounding pending remedy.]

10. Early warning reporting. [Treatment under 49 C.F.R. Part 579.]

11. Approval. [Names, roles, and date.]

⚠️ Document the decision either way. A documented decision not to recall, with reasoning, is defensible. An undocumented one looks like a decision to conceal, and penalties run under 49 U.S.C. § 30165 with criminal exposure at 49 U.S.C. § 30170.

TOOL 9 — AUTHORITY TABLE

Federal vehicle safety framework

Authority	What it governs
49 U.S.C. § 30101	Purpose and policy
49 U.S.C. § 30102	Definitions, including motor vehicle and equipment
49 U.S.C. § 30103	⚠️ Relationship to other laws — preemption and the savings clause
49 U.S.C. § 30111	Authority to prescribe safety standards
49 U.S.C. § 30112	Prohibition on non-compliant vehicles
49 U.S.C. § 30113	General exemptions
49 U.S.C. § 30114	Special exemptions
49 U.S.C. § 30115	Certification of compliance — self-certification
49 U.S.C. § 30116	Defects found before sale
49 U.S.C. § 30118	Notification of defects and noncompliance
49 U.S.C. § 30119	Notification procedures
49 U.S.C. § 30120	Remedies
49 U.S.C. § 30162	Petitions for standards and enforcement
49 U.S.C. § 30165	Civil penalties
49 U.S.C. § 30166	Inspections, investigations, and records
49 U.S.C. § 30170	Criminal penalties
49 U.S.C. § 32304	Labeling
49 U.S.C. § 31136	Commercial motor vehicle regulations

Regulations

Authority	What it governs
49 C.F.R. Part 571	Federal motor vehicle safety standards
49 C.F.R. Part 555	Temporary exemptions
49 C.F.R. Part 563	Event data recorders
49 C.F.R. Part 573	Defect and noncompliance reports
49 C.F.R. Part 579	Early warning reporting
49 C.F.R. Part 591	Importation
49 C.F.R. Part 595	Make-inoperative exemptions
49 C.F.R. Part 382	Commercial driver testing
14 C.F.R. Part 107	Small unmanned aircraft systems
49 U.S.C. § 40103	Sovereignty over navigable airspace

Preemption and product liability

Authority	What it governs
Geier v. American Honda Motor Co.	Implied preemption where the standard preserved manufacturer choice
Williamson v. Mazda Motor of America, Inc.	No preemption where the option was not a significant objective
Freightliner Corp. v. Myrick	Absence of a standard does not preempt
Sprietsma v. Mercury Marine	A decision not to regulate does not preempt
Wyeth v. Levine	Impossibility preemption
Cipollone v. Liggett Group, Inc.	Parsing an express preemption clause
Medtronic, Inc. v. Lohr	Express preemption under a device regime
Riegel v. Medtronic, Inc.	Preemption after premarket approval — ⚠️ the analogy fails for self-certified vehicles

Consumer protection and product safety

Authority	What it governs
15 U.S.C. § 45	Unfair or deceptive acts or practices
15 U.S.C. § 52	False advertising
15 U.S.C. § 2051	Consumer product safety findings and purposes
15 U.S.C. § 2064	Substantial product hazards
15 U.S.C. § 2072	Private suits for damages

Closing note

☐ Tool 1 is the one with a deadline. Send it in days, and name items 2, 3, 7, and 14. ☐ Tool 2 will be read aloud to a jury. Write it that way. ☐ Tool 4 is either the defense or the plaintiff's best exhibit, depending entirely on whether it overclaims. ☐ Tool 8's discipline — documenting the decision either way — is what separates a defensible judgment from a concealment narrative.

The Autonomous Vehicle Deployment, Crash Investigation, and Robotics Compliance Toolkit

TOOL 1 — PRESERVATION LETTER

TOOL 2 — OPERATIONAL DESIGN DOMAIN DEFINITION

TOOL 3 — DISCOVERY REQUEST SET

TOOL 4 — SAFETY CASE OUTLINE

TOOL 5 — LAW ENFORCEMENT AND EMERGENCY RESPONDER PROTOCOL

TOOL 6 — CRASH INTAKE SHEET

TOOL 7 — EXPERT SCOPE MEMORANDUM

TOOL 8 — RECALL DECISION MEMORANDUM

TOOL 9 — AUTHORITY TABLE

Closing note

Related Documents