At 7:42 a.m. on a dry Tuesday in Ann Arbor, a driver using Tesla Full Self-Driving reported a hard stop with no visible obstacle ahead. The vehicle slowed sharply, the following traffic did not, and the driver had to take control. That is the basic shape of many FSD phantom braking cases: the car responds to something its sensors or software interpreted as a threat, but the human operator cannot find a physical reason for the maneuver.
This is not a claim that every sudden slowdown is a software defect. Shadows, cresting roads, construction equipment, emergency vehicles, confusing lane geometry, or a real object outside the driver's view can produce a legitimate alert. The useful question is narrower: what happened, what should the system have done, and what evidence separates a bad perception event from an ordinary collision?
What phantom braking actually means
Phantom braking is an unexpected deceleration or stop triggered by an advanced driver-assistance system when the driver perceives no immediate hazard. In Tesla vehicles, drivers commonly discuss the behavior in connection with Autopilot or FSD, but similar false-positive braking behavior can occur in other camera- and radar-based systems. FSD remains a driver-assistance feature, not a legally autonomous chauffeur. The driver must monitor the road and remain ready to steer or brake.
Technically, the failure can occur at several layers. Perception may classify a bridge shadow, billboard, truck reflection, or lane marking as an obstacle. Prediction may assign an unreasonable path to a nearby vehicle. Planning may choose a defensive trajectory with excessive braking. Controls may then execute that trajectory correctly even though the upstream decision was wrong. A brake pedal does not tell you which layer failed; video, timing, vehicle data, and road context do.
Severity matters. I use a simple one-to-five scale: one is an uncomfortable lift or mild brake application, three is a forceful slowdown that changes traffic risk, and five is a near-crash, impact, or loss of control. That scale is more useful than describing every event as “terrifying.”
How to document FSD phantom braking cases
The first priority is safety. Take control, leave the system disengaged, and move to a safe location before collecting evidence. Do not attempt to recreate a dangerous event in traffic. Once stopped, record the time, road direction, approximate speed, weather, lighting, traffic density, lane markings, and anything near the vehicle that could have triggered perception.
Save the dashcam clip before it is overwritten. Note whether the car issued a forward-collision warning, displayed a red obstacle graphic, sounded a chime, or disengaged FSD. A passenger can write observations while the driver focuses on the road, but do not use a phone while driving. A second camera showing the following traffic or the road surface can be valuable, provided it was captured safely.
For FSD phantom braking cases involving property damage, preserve more than the video. Keep repair estimates, towing invoices, photographs of tire marks and bumper damage, police or incident reports, and the vehicle's software version. Record the exact vehicle model and whether Autopilot, FSD Supervised, Traffic-Aware Cruise Control, or manual driving was active. Insurance adjusters need a timeline, not a theory about neural networks.
What an insurance claim usually covers
A sudden stop without contact generally does not create a physical-damage claim. There is no repair bill to reimburse, although the event should still be logged if it created a serious safety risk. If the vehicle brakes unexpectedly and another car hits it, the result becomes a conventional collision claim. Collision coverage typically pays for damage to the insured vehicle after the deductible, subject to the policy's terms. Liability coverage addresses damage or injuries the insured driver is legally responsible for causing.
Suppose a $1,800 bumper repair follows a rear-end impact and the policy has a $500 collision deductible. A covered claim could leave approximately $1,300 payable before other policy considerations. If the driver carries only liability coverage, their own vehicle damage is usually not covered by that policy. Medical payments or personal injury protection depend on the state and policy structure, while uninsured or underinsured motorist coverage can matter when the other driver lacks adequate insurance.
Do not describe the event as “the car caused the crash” unless the evidence supports that conclusion. Tell the insurer exactly what occurred: the system applied unexpected braking, another vehicle struck the rear, and the available recordings show the sequence. Fault allocation varies by facts and jurisdiction.
The evidence gap between a bug and a claim
FSD phantom braking cases are difficult because the vehicle's internal logs are not always available in a form an ordinary driver can inspect. A clip can show the brake lights and road scene, but it may not show whether the system detected a real object, how much deceleration occurred, or whether the driver had already touched the brake pedal.
Build a small evidence packet with five items: the original video file, a written timeline, vehicle and software details, photographs of the scene and damage, and contact information for witnesses. Keep original files unedited and create a separate copy for annotations. If a manufacturer support ticket exists, save its number and every response. Avoid posting license plates, faces, or private crash information publicly before the claim is resolved.
For engineers, reproducibility is the missing piece. Record the same route under similar light and weather, but only when doing so is legal and safe. A single event is an anecdote. Repeated behavior at the same road geometry across multiple drives is stronger evidence, though it still does not prove the internal root cause.
Reducing risk after a sudden stop
After one severe event, disable the relevant assistance feature until you understand the trigger. That is not an admission of fault; it is a risk-control decision. Increase following distance, especially in heavy traffic, and keep your eyes moving between the road, mirrors, and instrument display. A vehicle behind you cannot react to a false positive as quickly as your own car can.
Check for an available software update, but do not assume an update fixes the behavior simply because release notes mention braking, perception, or “improved driving.” Change one variable at a time when evaluating system behavior. If tire pressure, windshield cleanliness, camera calibration, or weather changed between drives, record that too. A dirty camera or damaged windshield can create problems that look like software hallucinations.
Drivers should also review coverage before an incident occurs. Know the collision deductible, rental reimbursement limit, roadside assistance terms, and whether a lender requires particular coverage. Comparing quotes from insurers such as GEICO, Progressive, State Farm, or regional carriers can reveal meaningful differences in deductibles and claims service, not just premium price.
A practical severity and reporting checklist
For each event, answer these questions in order:
- Did the driver or system detect a visible hazard?
- Was there measurable braking, and did another vehicle make contact?
- What warning, display message, or chime appeared?
- Which assistance mode was active, and what software version was installed?
- Was anyone injured, and is there property damage?
- Were police, the manufacturer, or the insurer notified?
- What severity rating from one to five fits the event?
The goal is not to win an argument online. It is to create a record that another person can audit. FSD phantom braking cases become useful engineering data when the timestamp, road context, system state, and outcome are all preserved. They become useful insurance evidence when the same packet clearly documents damage, expenses, and the sequence of impact.
Your car talks. I check his homework. Until the data explains the stop, treat an unexplained hard brake as a safety incident, not a quirky feature.