Open-World Player Vehicle Driving P9: Collision, Damage, and Failure Recovery — How a Vehicle Remains Recoverable After Damage

Previous article: Open-World Player Vehicle Driving: Executors, Kinematics, and the Physics Seam — How Driving Commands Become Real Motion

The previous article followed a driving command into the physical world and returned the resulting motion to the next frame. This article follows the next problem: after a collision, weapon impact, burst tire, engine fault, or driver failure, how does the vehicle turn those results into persistent state and remain part of the open world without being immediately reset?

Introduction: a damaged vehicle cannot be represented by a collision fact alone

Consider a vehicle moving along a road. It slows at an intersection and then receives a side impact from another vehicle. It can still move, but its steering response has changed. A few seconds later, a tire fails and the vehicle begins to pull to one side. The driver continues to submit input; the executor can still submit requests, but it can no longer guarantee the original path. If the runtime records only a single collision event, the mission cannot know whether it should continue tracking the original target, limit speed, wait for stabilization, or enter recovery.

In an open world, collision is therefore not a transient event consumed only by the camera and sound system. It can change velocity, contact conditions, reachability, component state, control eligibility, and task semantics. Damage is not one health value either. Bodywork, engine, fuel tank, wheels, glass, lights, and aggregate health may be maintained by different logic owners. Their results can feed driving tasks, crime events, replication, passenger reactions, and recovery tasks.

The executor–physics seam answered how a request enters physics and how the physical result returns. This article handles the next layer:

The central claim is: vehicle damage does not mean that vehicle execution has ended, and loss of control does not mean that vehicle state has been cleared. The runtime must preserve the source of damage, component state, current motion result, and recovery eligibility so that later layers can distinguish temporary restriction, persistent failure, and non-recoverable termination.

1. Collision facts: from contact records to frame history

From contact results to collision history

One physics frame may produce several contacts: a vehicle touches a curb, a wheel crosses uneven ground, the body receives an impact from another vehicle, and the resulting force pushes it into a barrier. If every contact immediately triggers a complete gameplay path, the runtime can apply damage repeatedly, play duplicate effects, emit duplicate network events, and lose the ability to identify the dominant impact of the frame.

The traced collision paths suggest a set of records retained for an update interval and consumed through selection and aggregation. This article calls that responsibility frame-level collision history. It is not a single OnHit flag. It is a collection of contact facts from which later systems choose and aggregate.

A collision record generally needs to express:

• the other entity;
• impact magnitude or impulse;
• contact normal;
• hit position on both sides;
• component or material identity;
• whether the contact is new;
• whether another piece of logic has consumed it during the frame.

These fields answer different questions. Impulse helps determine whether the vehicle state should change. The normal describes impact direction. The hit position helps distinguish bodywork, glass, and wheel damage. Material and component data can feed sound, particles, broken glass, and component-specific damage.

Why recording must precede routing

Collision history separates “what physics observed” from “how gameplay interprets it.” The physics stage provides contact facts. The damage system applies immunity rules, source rules, and component state. The presentation layer selects a representative impact. The network layer decides whether a synchronization event is needed. The task layer consumes higher-level execution feedback.

The same collision may be visible to several systems, but those systems do not own the same state:

If a collision enters only the presentation layer, the player may see the body shake while the task still assumes full grip. If it enters only the damage layer, the executor may continue using pre-impact velocity and contact state. If every system re-queries physics independently, their interpretations can diverge. Frame history gives the update cycle one traceable set of shared facts.

The dominant impact is not necessarily the last impact

The last contact record in a frame is not necessarily the important one. A vehicle may first collide with a heavy truck, then brush a roadside object, leaving the last record as a minor contact. Damage and presentation need to select the dominant impact using impulse, mass, direction, and material rather than array order.

The presence of maximum-impulse or dominant-collision queries indicates that some consumers do not simply read the last record. Body damage may use the dominant impact; tire logic needs the local wheel record; glass needs component and material information; camera and sound may choose the strongest representative impact. The query does not hide collision history; it provides a stable selection policy for each consumer.

2. Component damage has different state owners

The outer entry point routes and checks permission

The responsibility distribution around vehicle damage can be abstracted as an outer damage entry point. It receives a confirmed hit or collision result, applies damage multipliers, source rules, authority checks, player rules, and special-vehicle conditions, then distributes the result to narrower state owners.

It should not be read as “all damage logic lives in one function.” It serves as a routing and admission-control boundary:

1. normalize the damage source and damage type;
2. check whether the vehicle can accept this category of damage;
3. save a composite pre-damage snapshot;
4. route to body, engine, fuel, glass, wheel, and aggregate-health paths;
5. aggregate changes and update attribution, statistics, and synchronization records.

The composite snapshot matters. Aggregate vehicle state may include overall health, engine state, fuel state, body health, tires, and suspension. One hit may change only some of these values. Comparing before and after routing is what reveals whether the event changed vehicle execution in a meaningful way.

Body state owns structural damage

Body damage is not merely a floating-point value going down. It may lead to a detached door, raised hood, loose bumper, detached miscellaneous part, broken panel, or aggregate destruction path.

These paths are usually constrained by damage type, hit position, current body health, vehicle class, destructibility, the last break time, and special gameplay state. A break also needs cooldown or timing protection so that a high-frequency collision does not detach the same structure repeatedly in one update interval.

The body state owner therefore maintains:

• structural health;
• breakable-component state;
• deformation and collision-presentation state;
• detachment timing;
• escalation after structural health reaches its terminal threshold.

Engine, fuel, and fire are independent failure channels

Engine and fuel state cannot be replaced by aggregate health. Engine damage may depend on hit location, damage type, current speed, overturned state, weapon rules, and special reduction conditions. The fuel tank has its own leak, fire, and near-terminal states.

Fuel fire also needs attribution. Later systems may need to know which entity or damage type caused the transition. If fuel damage is flattened into aggregate health, the runtime cannot express “the body is intact but leaking,” “the engine has failed while the body can still move,” or “the vehicle is burning but has not entered explosion yet.”

That distinction lets driving and recovery tasks choose different responses:

• body damage with normal power: preserve the route but lower risk tolerance;
• engine restriction: reduce propulsion and wait or seek a safe position;
• fuel leak: preserve motion while maintaining a persistent hazard;
• fire: notify passengers, tasks, and presentation;
• aggregate health at terminal state: enter destruction or non-continuable execution.

Wheels and suspension own persistent mobility state

Wheel damage must remain separate from the short burst-tire reaction. The damage layer needs at least the affected wheel index, whether the tire remains usable, contact ability, suspension condition, and the continuing effect on lateral stability, propulsion, and braking. If repair is supported, it also needs to record whether the state is repairable and whether a simplified damage summary must survive at distance.

The burst-tire reaction is only a short accident action created after the wheel state is established. Its end releases steering and braking actions; it does not restore the tire. Later execution must still limit steering, propulsion, and braking according to the persistent wheel and suspension state. “The burst reaction ended” and “full mobility has returned” are different moments.

Glass, lights, and aggregate health have different consumers

Glass and light damage should not directly own aggregate vehicle health. They may change light presentation, warning states, broken windows, police presentation, or synchronized visuals without removing driving capability.

Aggregate health is closer to a lifecycle boundary. It may trigger passenger events, crime attribution, destruction, or chain explosions. Putting broken glass, a detached door, and aggregate health zero into one variable makes the result uninterpretable and leaves recovery with no answer to what can still be recovered.

Body, engine, and fuel state may propose escalation or termination. A single aggregate lifecycle owner should confirm destruction or entity termination so that several component paths do not fire the same terminal transition repeatedly.

3. How damage changes capability and execution eligibility

Damage, control source, and execution eligibility are different states

The preceding articles separated seat relations, input sources, driving commands, and control-source handoff. The executor–physics article added acceptance, clamping, delay, and rejection. This article adds another distinction: a vehicle may be damaged without changing its control source, and an executor may temporarily reject a request without making the task fail.

Keep the following states separate:

For the rest of the article, an incident runtime can be described through five state categories:

State	Question answered	Main source or interpreter
Collision fact	What happened this frame?	Physics and collision history provide facts
Damage state	Which components changed persistently?	Vehicle damage layer owns persistent state
Execution capability	What can the vehicle do now?	Damage and physics provide facts; the type-specific executor interprets them
Control source	Who may still submit commands?	Control-source arbitration confirms it
Task goal	What is the vehicle still trying to complete?	Vehicle and higher-level tasks maintain it

Recovery reads these five categories but does not own them. It organizes the next request from the current snapshot and rechecks conditions after a request expires, times out, or physics reconnects.

A collision may change damage and execution eligibility without directly changing the command source. The player may remain in control while steering, propulsion, or braking capacity changes. An AI driver may remain active while its route task chooses a safer local target. Control changes only after a task or dedicated handoff layer confirms the transition.

Restricted execution: reduced capability can still be valid execution

On low-grip ground, an executor may accept steering while limiting propulsion. In shallow water, a boat may accept heading changes without reaching its target speed. Near a flight-envelope boundary, an aircraft may continue tracking a target while delaying attitude changes. A rail vehicle may reject lateral input while preserving braking and track-constrained propulsion.

These are cases where the request remains meaningful but current capability is insufficient. The upper layer needs a reason for restriction, not a context-free failure boolean. Otherwise the route task will continually rebuild its target, the control source will assume that the vehicle has stopped responding, and recovery may seize execution even though continuation remains possible.

Loss of control has its own persistent lifecycle

Loss of control usually combines changes in velocity, attitude, contact, capability, and task target. A vehicle hit from the side may yaw briefly and recover through tire contact. A failed tire may produce continuous pull and require restricted driving. An engine may fail while inertia allows the vehicle to coast to safety. An overturned vehicle or incapacitated driver may require a stronger follow-up task.

At minimum, the loss-of-control state should preserve:

• trigger source;
• start time and duration;
• current linear and angular velocity;
• contact and overturned state;
• damaged components;
• whether the original goal remains valid;
• whether the current source continues submitting;
• recovery and termination conditions.

Recovery consumes this state instead of guessing why the vehicle stopped. It can stabilize attitude, hold braking, reduce propulsion, wait for physics reconnection, or transfer the vehicle to a controlled crash, parking, or exit path.

4. Failure reactions: burst tires, driver failure, and special motion states

A burst tire creates a short request from a persistent damage state

The burst-tire path shows a clear division of responsibility. After a tire is confirmed unusable, the runtime produces a short, interpretable steering and instability reaction, then exits that reaction and lets a higher layer decide what follows.

The reaction typically validates the wheel index and checks whether the wheel is in ground contact. It determines the steering direction from the damaged side, then combines speed, vehicle mass, and tuning parameters to calculate intensity. During the active phase, it may request steering toward the damaged side, cancel propulsion, limit service braking, enable the handbrake, and, where needed, request a torque around the vehicle forward axis.

This is a bounded short-term reaction, not a permanent driving mode. It has its own lifetime, does not own route following, does not decide task failure, and ends on time, speed, attitude, or another explicit condition. After it ends, the vehicle returns to higher-level task selection while the persistent tire state remains.

Driver failure requires vehicle-side routing

When the driver becomes unable to act, the vehicle may still be moving quickly, airborne, overturned, or close to an obstacle. Setting all velocity and control to zero would break physical continuity and skip the different follow-up paths required by a car, aircraft, airship, or other vehicle.

The traced driver-failure paths suggest different post-failure tasks for cars and aircraft. The complete range of every vehicle branch still requires additional call-site verification. A car may enter hold, braking, randomized, or exit behavior. An aircraft may enter a crash task in the air and an exit path after landing. A special flying vehicle may preserve motion until it approaches the ground rather than stopping abruptly.

These tasks handle short vehicle-side post-failure processing. They do not replace the driver-failure event with a presentation wrapper. They report driver failure, preserve current damage and motion conditions, and request a bounded post-failure path. Releasing the old source, installing a new source, and confirming submission authority remain responsibilities of the handoff layer. Executors and the physics bridge consume the resulting requests.

Post-failure processing needs an exit: a new source is confirmed, the vehicle enters stable parking or crash handling, the entity leaves the physical world, or an observation timeout reaches termination. Without an exit, the failure reaction competes indefinitely with later control sources.

Failure type	Trigger	Allowed actions while active	Normal exit	Failure exit
Burst tire	Wheel state confirms unusable	Short steering, deceleration, body stabilization	Time, speed, or attitude condition	Persistent restriction or safe parking
Driver failure	Original driver cannot submit	Request post-failure handling for current motion	New source, parking, or crash task confirmed	Timeout, entity exit, termination
Overturned or airborne	Contact, attitude, or flight condition is invalid	Observe and stabilize by vehicle type	Executable attitude regained	Crash, exit, or non-recoverable state
Physics wait	Collision representation is temporarily unavailable	Preserve goal summary; submit no invalid physics request	PhysicalReady restored	Streaming unload, timeout, entity removal

The boundary is deliberate: this article defines failure-state lifetime and recovery inputs; handoff confirms source changes; the executor consumes temporary requests and returns actual results.

Cars, aircraft, boats, and rail vehicles cannot share one recovery law

Car recovery is organized around contact, velocity, heading, and tire state. Aircraft recovery needs attitude, lift, speed, and flight-envelope conditions. Boats need buoyancy, water contact, and propulsion establishment time. Rail vehicles remain constrained by the track.

They can share lifecycle semantics—request valid, execution restricted, waiting, recovery, success, failure—but their control laws and reachability tests belong to type-specific interpreters. A universal “flip upright and accelerate” function would apply car assumptions to aircraft, boats, and rail vehicles.

5. Physical admission and recovery conditions

The previous executor–physics article established that requests must be submitted during a valid physical phase. This article keeps only three recovery-related conclusions. PhysicalReady is the public name used here for the condition that physical representation and environmental collision are both available for execution; it does not claim that the source contains an identically named field.

When environmental collision geometry is not ready, the vehicle must wait. It must not be misclassified as damaged or as having completed its task. After physics reconnects, the runtime must recheck the damage summary, control source, goal version, and current motion snapshot before allowing new execution.

Admission is not a health check

Damage admission asks whether this source and damage type may modify persistent state. Physical readiness asks whether the vehicle can safely submit and receive physical execution. They can fail independently. A healthy vehicle outside loaded collision can be not-ready; a damaged vehicle with valid physics can remain executable with reduced capability.

Recovery is a contract, not a teleport

Recovery may request stabilization, a clear temporary reaction, a new local target, or re-entry into physics. It should not silently restore pre-impact transform or health. A successful recovery means that the current state is once again interpretable and executable, not that the vehicle has been reset.

6. Source abstraction and engineering boundaries

The following model is an architectural abstraction derived from field writes, call relationships, update phases, and lifecycle ownership. It is not a literal reproduction of source names:

The public conclusion is which layer owns persistent state, which entry point only routes, and which result returns to tasks and executors. Network authority is retained here only as a damage-admission and state-consumption condition. Replication, entity reconstruction, and replay recovery belong to the later network article; a non-authoritative local node must not submit persistent damage.

Ownership of failure reactions

Failure reactions can be grouped by lifetime:

• External task reactions: tactical or scripted tasks request them; this article treats them as outside sources of damage or loss of control.
• Direct control reactions: such as short steering and braking after a burst tire.
• Post-failure control: such as holding a vehicle, entering a crash path, or exiting after driver failure.

All three can change motion, but they do not share a lifetime. External task reactions are supervised by higher-level tasks. Direct reactions have explicit short exits. Post-failure handling preserves vehicle conditions and requests a safe, recovery, or terminal path. Control-source arbitration still owns the source transition.

The seam with the executor article

The executor article outputs execution results: accepted, clamped, delayed, rejected, or divergent from preview. This article consumes those results and classifies them as temporary restriction, component damage, persistent loss of control, physics wait, or recovery requirement.

The two articles must not cross-own one another:

• the executor article does not decide whether the vehicle is damaged;
• this article does not recreate control generation or physics solving;
• the executor article provides physical facts and execution eligibility;
• this article maintains persistent damage, failure, recovery, and termination semantics.

The next article will address parallel control between driving, interior interaction, aiming, and combat. Combat can change damage and control, but it must not compress recovery state into a single “vehicle stopped” flag.

7. Recovery contracts, diagnostics, and goal continuity

Recovery is often summarized as “handle the vehicle after the accident.” In runtime terms, it is a set of state judgments that must remain observable. Without diagnostics, the system can report only that the vehicle did not move; it cannot say whether damage, source authority, physical eligibility, route goal, or recovery conditions blocked the next step.

Diagnostics should follow state ownership

A recovery diagnostic should answer at least:

• which layer maintains current damage;
• where the last valid collision came from;
• who the current source is and whether it may submit;
• why the executor rejected a request;
• whether the physical entity is in a valid update phase;
• whether the current task goal remains reachable;
• how long recovery has been active;
• who triggers the next state check.

These values need not be shown to the player, but tools, logs, or test assertions must be able to read them. Otherwise “the vehicle stopped” can only be inferred from the screen, and driver failure, engine failure, collision wait, route invalidation, and entity removal become indistinguishable.

Logs and persistent state answer different questions

A log can record that a collision occurred, a burst reaction began, or environmental collision data became unavailable. The log is not the vehicle’s current state. Recovery must read persistent state and the current snapshot rather than replaying events to guess whether the vehicle is still burning or whether control has returned.

Events answer time questions: when a state began, what triggered it, and which transition failed. State answers current questions: whether the vehicle is restricted, which component is unusable, which source is valid, and whether submission is allowed. Both are needed for long-running worlds and re-entry after streaming.

Failure causes must remain distinguishable

“Recovery failed” may mean an unreachable target, physics not ready, an invalid control source, irreversible damage, unsupported recovery for this vehicle type, a completed task, or an entity that has left the world. Each cause requires a different response: replan, wait, hand off, terminate, release relationships, or clean references. Compressing all of them into one failure value invites infinite retries and requests against terminated entities.

Tests must cover paths that can continue

Tests should verify more than eventual explosion or stopping. They should cover a minor collision that preserves the goal, a burst reaction that ends without losing the source, an engine failure that still permits coasting, a temporary collision-data gap that does not let the vehicle pass through the world, successful AI recovery after a player exits, and repair that prevents an old loss-of-control request from overriding a new source.

The difficult cases in an open-world vehicle runtime are the non-terminal ones. A vehicle is often restricted, waiting, observing, recovering, or continuing—not simply normal or destroyed. Recovery quality depends on preserving these intermediate states and delivering them to the correct consumers.

Damage must inform goals without owning them

A common mistake is allowing the damage layer to decide the task’s next goal. A collision cancels navigation, an engine warning immediately forces parking, or driver failure clears every task parameter. Visible feedback may result, but component state, vehicle capability, and task goal have been collapsed into one state machine.

After a minor collision, the original goal may remain valid. What changes is the speed, tolerance, and safety margin required to reach it. The task can retain the goal, the local follower can recalculate, policy can reduce propulsion or increase observation time, and the executor can limit requests according to grip. The damage layer reports capability and risk; it does not delete the route.

Some damage does invalidate a goal. Aggregate destruction, driver failure, persistent fire, or a crash path may require a safe area, evacuation, or termination. The goal may be canceled, suspended, or replaced, but the goal owner or handoff layer must perform that transition. The same engine failure can mean slow coasting in free driving, evacuation in an escort task, or a tactical change during pursuit.

Goal impact therefore needs at least three meanings: continue, degrade, and terminate. A vehicle that cannot accelerate immediately may still arrive. A temporary lack of physics representation is not task completion. Observation is not source release. Explicit intermediate states let tasks, traffic, and presentation share one persistent vehicle.

How upper layers consume recovery results

Recovery should not expose every damage field to every caller, nor return only a success flag. It should expose stable capability and state results: what the vehicle can do, what it cannot do, and when it should be checked again.

Tasks may not need tire health to change from 0.32 to 0.18 or the full impulse history. They need to know whether the vehicle can maintain a lane, use propulsion, steer, brake, continue navigation, or whether a persistent hazard exists. Component owners keep raw values; the runtime interprets them into type-aware capabilities.

Recovery requests should carry source, vehicle mode, goal version, request time, expected result, and allowed failure paths. A seat switch, target change, or transition into a distant representation can invalidate the old request. Recovery may ask for stabilization, clearing a temporary reaction, or re-establishing physics, but it cannot bypass current task permission or overwrite a new control source.

Recovery completion should be confirmed rather than inferred from a timer. Check speed, attitude, contact, damage capability, physical representation, current command, and goal state. A stopped vehicle is not necessarily safe; movement is not proof of control; registration of a physical object is not proof of valid collision. Success means that temporary reactions are released, old requests are cleared, the current source is valid, the executor accepts a new request, feedback returns, and the goal remains interpretable.

8. Incident chains and state lifecycles

One incident usually contains several timelines. Physical contact occurs in one update phase, component damage may be confirmed later, presentation may be delayed to the next frame, and the task must wait for stable results before changing its goal. A single “collision occurred” event cannot explain why the vehicle has yawed while the task continues, or why physics is waiting while the damage state is unchanged.

Four timelines

The physics timeline records contact, impulse, velocity, angular velocity, wheel-ground relation, and collision history. It reports physical fact but does not declare task failure.

The damage timeline turns accepted records into persistent body, wheel, engine, fuel, glass, or aggregate changes. It may include thresholds and accumulation across frames.

The control timeline records who may submit and whether the executor accepts, clamps, delays, or rejects the request. Damage and control are not synchronized automatically: a minor collision can change damage while control remains normal; a failed tire can leave the source intact but reduce steering capability; driver failure requires handoff confirmation.

The task timeline decides whether the goal remains valid, whether to observe, choose a safe position, change a local target, or terminate. It must not rebuild the complete route from one contact record or treat one executor rejection as permanent failure.

Facts, changes, and presentation are separate

Contact history is fact. A component becoming unusable is state change. Sparks, broken glass, and camera shake are presentation triggers. They are related but cannot be represented by one event type.

Not every contact causes damage. Tire-ground contact is a physical fact; a puncture is persistent state; a burst sound is presentation. A more stable order is to record fact, confirm state change, then trigger deduplicated presentation. Presentation may discard minor contacts while damage retains critical state.

Attribution is traceable responsibility, not write ownership. An entity may be credited with damage without receiving permission to write the engine or change the control source. A player-caused collision may not cross a failure threshold; a scripted explosion may have no attacker; environmental fire may alter fuel without becoming a driving command.

Presentation also needs deduplication and priority. One incident may produce impact sound, body shake, sparks, glass, tire noise, and camera feedback. The presentation layer can select one representative response using impulse, hit position, material, and recent-trigger time. Deduplication does not remove physics facts; it only changes how presentation samples them.

Persistent damage has a lifecycle

Once established, engine restriction, fuel leak, tire failure, and structural damage continue to affect later frames. Their lifecycle requires establishment, maintenance, escalation, repair, and termination.

Establishment turns a candidate collision or damage record into persistent state using thresholds, location, vehicle type, and current rules. It records source, time, component, severity, and possible reactions.

Maintenance changes capability rather than disabling everything. Engine restriction can lower propulsion, tire failure can reduce lateral stability, fire can raise hazard, and body damage can change collision risk. Capability feedback should carry reason and scope.

Escalation needs explicit triggers such as duration, speed, repeated impacts, temperature, or a component combination. Car fire, flooding, aircraft stall, and rail derailment have different type-specific conditions; shared lifecycle language should not erase those differences.

Repair is a new state change. It must state which components recover, which attribution remains, which tasks continue, and whether physics or execution needs reinitialization. Health returning to a nominal value is not the same as regaining interpretable execution eligibility.

Termination cleans commands, attachments, presentation, task references, synchronization state, and world registration. Destroying a visual object while keeping a task reference leaves the next frame able to submit to a vehicle that no longer exists.

Damage admission and recovery confirmation

Damage admission depends on source, type, relationship, script context, and authority. Physical collision can be real while the damage layer rejects its persistent effect. Conditions may include network ownership, global immunity, damage type, relationship filters, script context, and special states such as overturned, stunt, towing, distant representation, or physics wait.

Rejected damage should preserve a reason: invulnerability, invalid source, non-authoritative entity, filtered type, or missing physical state. Those reasons drive different follow-up behavior. Local authority must not commit persistent damage; physics wait should preserve eligibility as unconfirmed rather than mark the vehicle “undamaged.”

The outer damage route should save a composite snapshot before dispatch, compare after dispatch, and create attribution, feedback, and escalation from the difference. This prevents a single explosion or multi-component hit from firing destruction, passenger, crime, network, and statistics events repeatedly.

A complete incident timeline

Imagine a vehicle following a local target through a city intersection. The executor reads velocity and contact state, submits a request, and the vehicle receives a side impact. Physics records impulse, normal, hit position, and the other entity; attitude changes.

Next, collision history is consumed. Presentation selects an impact, the damage route checks immunity and source, body state records deformation, the task receives execution deviation, and the executor reads new velocity and angular velocity after physics.

The vehicle still has control authority, a route, and a local target, but the old speed request no longer fits. The executor limits propulsion and recalculates local direction. The runtime does not enter recovery because tire contact can still return the vehicle to the route.

If the tire then fails, wheel state becomes unusable. The burst reaction applies bounded steering and braking, and the executor reports that lane keeping is unreliable. When the reaction ends, the task chooses between low-speed continuation, a safe position, or recovery.

If the vehicle leaves the region with complete collision geometry, physics enters a waiting state. The vehicle is not damaged and the task is not complete; execution is temporarily unqualified. When collision data is ready, the entity regains physical eligibility and the executor resumes from a new transform and velocity snapshot.

No single system owns the entire incident. Collision history provides fact, damage owns components, the executor interprets capability, the task owns the goal, and physical admission decides whether submission is valid. Recovery organizes these results into the next step; it does not teleport the vehicle to its pre-impact state.

Scenario	Vehicle fact	Recovery must confirm
Minor collision	Velocity reduced; route remains reachable	Preserve goal and limit or recalculate control
Low-grip yaw	Tires usable but lateral response reduced	Observe without immediately failing the task
Burst tire	Component failed; short reaction ended	Continue at low speed or enter safe parking
Engine damage	Propulsion reduced; inertia remains	Preserve goal or seek a safe position
Fuel fire	Persistent hazard	Notify passenger, task, and presentation systems
Driver death	Old source is invalid	Hold, crash, park, or exit
Collision resource unavailable	Physics temporarily unavailable	Wait or keep distant state; do not mark damage
Physical entity removed	No further submission possible	Clear old requests; rebuild or terminate

9. Failure semantics across vehicle types

The same upper-level capability does not imply the same motion result for every vehicle. “Reduced propulsion” for a car can mean engine, tire, or drivetrain loss; for a boat it can involve buoyancy, water contact, or propeller state; for an aircraft it can require preserving attitude, speed, and altitude instead of setting propulsion to zero.

Share lifecycle, not failure actions

Vehicle types can share candidate damage, confirmation, restricted capability, persistent risk, recovery attempt, success, and failure. The type-specific interpretation must own the actual recovery action. A car can brake and regain tire contact; a boat can wait for buoyancy and water speed; an aircraft can manage attitude and flight envelope; a helicopter must distinguish rotor, lift, and attitude; a train cannot recover through lateral steering.

Do not turn the damage entry into a vehicle-type branch forest

The outer entry should confirm source, permission, and persistent owners, then route component or capability changes to the type-specific state layer. The outer layer asks whether damage is valid, who receives attribution, whether it must be recorded, and whether aggregate lifecycle changes. The type layer interprets tires, propellers, wings, rotors, track constraints, or buoyancy.

This division also improves testing. Shared lifecycle tests can verify that damage remains observable, recovery has an exit, and physics wait is not misreported as damage. Cars, boats, aircraft, and rail vehicles then receive separate tests for their own motion constraints instead of one massive conditional table.

Distant damage must remain interpretable

Distant representation cannot retain every contact normal and frame-level collision record, but it must preserve damage information that affects later behavior. Re-entry should recover aggregate health, critical components, persistent hazards, terminal state, and whether physical representation must be established again.

High-frequency contact facts may be discarded at distance. “Left front tire failed,” “fuel is still burning,” and “vehicle cannot continue” are low-frequency state summaries and must remain owned by the vehicle entity. When real physics returns, new contact facts can be generated from current transform and the damage summary.

If distant representation keeps appearance but drops damage semantics, the vehicle returns as a visually similar but logically different entity. That breaks visual continuity, tasks, attribution, and control. The summary does not replicate full simulation; it preserves identity across representation levels.

10. A source-reading method: trace one incident to recovery

Searching only for “what is called after collision” is insufficient. Begin with an observable behavior: a vehicle yaws after impact, a tire fails, the engine catches fire, the driver becomes invalid, or collision geometry temporarily disappears. Follow this chain:

For each entry, record five questions: where input comes from, who owns the current phase, which state changes, what result returns to the next layer, and who continues after failure. A function writing body health does not decide task failure. A task entering loss-of-control does not own physical collision. A physical object waiting for streaming does not mean the vehicle is damaged.

Separate three kinds of evidence. Direct evidence includes field writes, calls, conditions, and update phases. Responsibility evidence comes from shared lifecycle and feedback patterns across several paths. Migration inference is the structure proposed to reproduce the mechanism in a target engine. Keep them separate so that an engineering abstraction is not rewritten as source fact.

The final validation is not “can the vehicle still move?” It is whether collision was recorded, damage entered the correct owner, capability reached the executor, control source remained continuous, physical admission stayed valid, and recovery has an explicit success or termination condition.

Conclusion: a damaged vehicle is still the same persistent vehicle

The player does not see the collision-history array, body-health field, fuel-fire attribution, physical-admission state, or recovery-request version. The player experiences whether impact produces a reasonable velocity change, whether a burst tire creates bounded pull, whether a damaged engine still permits coasting or a safe position, whether an unavailable physics representation avoids passing through the world, and whether recovery continues the identity of the same vehicle.

Those experiences come from one continuous relationship: collision produces fact; damage owns components; the executor interprets capability; the task decides whether the goal continues; recovery organizes condition checks and asks arbitration and execution to confirm submission. No layer may disguise its local result as the complete vehicle state.

Recovery does not return the vehicle to its pre-incident state. It gives the vehicle an interpretable next step under its current damage, physics, and control-source conditions.

The most valuable conclusion from source reading is not a damage multiplier or a failure parameter. It is continuity of state ownership: the outer entry receives and routes, the damage layer owns persistent components, physics owns contact facts, the executor reports capability, and task/recovery layers select the next path.

As long as that boundary remains intact, the vehicle can remain traceable across normal driving, local collision, persistent damage, loss-of-control observation, recovery, and termination. “The vehicle did not disappear” does not mean that it remained intact. It means that its state changes continued to be owned, interpreted, and consumed by the runtime.

AI collaboration review: turning incident results into a verifiable state chain

AI collaboration in this article was used to organize vehicle-damage notes, collision history, failure tasks, and physical-layer records into the chain “collision fact → persistent damage → execution capability → control source → task goal → recovery state.” This helped expose differences in the same word across systems: “failure” may mean executor rejection, component unavailability, source invalidation, or task termination.

The most common AI error is to merge adjacent responsibilities: treating a burst-tire reaction as damage-owned physics control, treating driver failure as automatic source takeover, treating physics wait as vehicle damage, or expanding a distant summary into a complete network protocol. Manual review therefore checks the writer of each field, each caller, each update phase, and each exit condition, while keeping source fact, architectural abstraction, and migration inference separate.

Open questions remain: the complete range of post-failure task branches across vehicle types, the exact trigger and timeout rules for collision waits, the persistence granularity of distant damage summaries, and whether special physical reactions bypass the common execution chain. These require more call sites, runtime logs, and prototype tests. They should not be written as certain facts in the current article.