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

Previous article: Open-World Player Vehicle Driving: Local Avoidance and Immediate Risk

the driving-control-window article examined how the player obtains a driving-control window; the input-architecture article examined how input enters a vehicle; the command-contract article examined how input becomes a driving command; the control-source-handoff article examined how control sources hand off; the navigation-and-routes article examined how a goal becomes a route; the driving-policy article examined how policy changes route execution; and the local-avoidance article examined how a vehicle handles immediate local risk. The execution layer continues the descent: how an already formed driving intention enters the execution path and eventually affects the vehicle’s actual motion.

Introduction: How a Driving Intention Becomes Vehicle Motion

Assume that a vehicle has received a local instruction: continue along the current route, slow down at the next junction, and turn right. To the player, this is an ordinary driving action. To the runtime, it is still not a set of numbers that can be written directly into physics.

The runtime first evaluates the vehicle’s position and orientation relative to the target. It then combines current speed, vehicle type, road constraints, and avoidance results to produce the propulsion, braking, and steering requests for this frame. Once submitted, those requests are affected by tyre contact, friction, collision, slope, and external forces. The resulting velocity, orientation, and contact state become inputs to the next frame.

This article therefore focuses on the execution chain from intention to feedback rather than on one steering formula:

The executor sits in the middle of this chain. It does not redefine the route or replace the physics system’s motion solving. It converts already formed targets and constraints into requests that the current vehicle can interpret, then reports whether those requests were accepted, limited, delayed, or changed before the next runtime update.

That is the core of the executor–physics seam: upstream systems describe how the vehicle should approach a target; the physical world produces how the vehicle actually moves; the seam preserves the continuity between target, request, submission phase, and physical feedback.

I. From Local Decisions to Executable Input

From the Local-Avoidance Result to Executable Input

At the end of the local-avoidance article, the runtime may have reached a local decision: remain in the current lane, select a lateral candidate, reduce speed, wait for a conflict to clear, or abandon the current local target. None of these is yet a physics control value.

The responsibilities can be separated into four layers:

1. The route layer provides the road structure that should be traversed.
2. The local execution layer provides the current target point or target pose.
3. The policy and avoidance layers provide speed, distance, and risk constraints.
4. The executor interprets those semantics as inputs that the current vehicle can consume.

If the third layer directly emits “turn the front wheels by twelve degrees,” the upper system becomes coupled to one vehicle model. A more durable contract is to express “correct toward the target,” “continue advancing,” “limit approach speed,” or “do not accelerate while the conflict remains.” Cars, boats, and aircraft may consume these intentions through different movement models while preserving the same high-level meaning.

An Executor Is Not a Direct Steering Writer

In source-oriented analysis, vehicle tasks can often be separated into route ownership, target following, local avoidance, and final control submission. A public description should not equate one concrete class with the entire executor, because a single execution chain may contain task wrappers, parameter forwarding, local geometry, and control submission.

The responsibility can be abstracted into three layers.

This layer converts the local target into relative error: longitudinal distance, lateral offset, heading error, target speed, and acceptable stopping distance. It answers what state the vehicle has relative to the target, not how the physics system should be modified.

This layer uses error, policy constraints, and vehicle state to calculate acceleration, braking, steering, or attitude corrections. It handles dead zones, limits, sign changes, low-speed behaviour, and invalidated targets.

This layer submits control quantities to the movement interface appropriate for the current vehicle, then reads velocity, pose, contacts, collision state, and other feedback in a later phase. It does not redefine the mission target. It makes sure that upper-level semantics enter the physical world safely.

The three layers may be implemented by separate objects or coexist inside one task chain. The important invariant is ownership: route logic should not write wheel angles, physics should not declare mission completion, and the camera should not become the vehicle controller.

Kinematic Preview Is Not Physical Solving

An execution layer often needs to estimate where the vehicle will be after a short interval if it continues with the current direction and speed. This is a kinematic preview. It helps select a target point, decide a turn direction, estimate arrival time, and detect whether a local target has already been passed.

The preview uses current velocity, geometry, and control assumptions. Physical solving additionally depends on contacts, friction, suspension, terrain, slopes, external forces, and other bodies. A preview is therefore an expected motion, not a fact that physics has already accepted.

When preview and physical results diverge, the runtime should read the physical state again and correct the next update. It should not forcibly pull the rigid body back onto the preview path. Otherwise the vehicle may tunnel through objects, snap during turns, lag behind its steering intent, or report task completion before the body has actually arrived.

The Phase Boundary of Control Submission

Vehicle execution normally does not allow every decision to complete at one update point. A stable phase chain can be abstracted as:

Task and local target → control calculation → pre-physics update → physics solve
→ transform and state readback → task, camera, and presentation feedback

The pre-physics phase prepares control quantities for the current frame. Physics processes contacts and constraints. The post-physics phase reconciles the result with vehicle state, task state, and presentation state. If a task announces “arrived” before the physical result exists, the vehicle may still be sliding while the mission has already ended.

This is the first rule of the physics seam: submitted control quantities and confirmed motion results belong to different phases.

The Automobile Executor: From Target Point to Wheel Motion

The shared automobile intention may include propulsion, braking, steering, and target maintenance. Its vehicle-specific interpretation involves wheelbase, steering geometry, traction, suspension, contact state, and braking distance. A local target can determine where the vehicle should approach; it must not assume that every automobile has the same wheel spacing, steering response, or stopping distance.

At low speed, heading correction may dominate. At high speed, preview distance, curvature, and speed reduction become more important. During reversing, the relation between target direction and vehicle heading changes. The executor therefore needs current speed, gear or movement mode, contact state, and recent feedback in addition to the target itself.

It should also retain the current target, the last valid control, and the reason a request was limited or rejected. This evidence allows upper layers to decide whether to continue, wait, select another local target, or request replanning.

Non-Automobile Vehicles: Shared Contract, Different Control Law

Boats may share target direction, propulsion intent, and stopping semantics without reusing a car’s tire-steering logic. Aircraft need attitude, thrust, and flight-envelope constraints. Helicopters additionally distinguish lift, hover, and horizontal translation. Rail vehicles have their lateral freedom constrained by the track relation.

The compatibility question is not whether all vehicles can call one driving function. It is:

• Which intentions have cross-vehicle meaning?
• Which parameters are meaningful only for one movement model?
• Which executor rejects inputs it cannot interpret?
• How does physical feedback return to the same task lifecycle?

Shared lifecycle and invocation seams can be useful, but they do not eliminate differences in motion semantics.

Physical Feedback Is Both an Execution Result and the Next Frame’s Input

Physics returns more than position and rotation. Speed change, collision contacts, suspension compression, buoyancy state, damage accumulation, and loss-of-control flags may all affect the next execution decision.

For example, a steering request may have been submitted while tire contact was insufficient to change direction. A brake request may have been submitted while a slope and current speed extended the stopping distance. A propulsion request may have been submitted while water resistance prevented the expected acceleration. The executor should report this feedback so the upper layer can keep the target, reduce speed, select another local point, or enter a recovery path.

Physics does not understand the mission objective, but its result determines whether the objective can continue. It is the downstream consumer of execution and the input to the next runtime decision.

Responsibility Boundaries Revealed by Source Reading

From the distribution of vehicle-intelligence entry points, vehicle-task families, and physics responsibilities, several stable conclusions can be abstracted:

• The vehicle side has a continuous runtime entry independent of the passenger character.
• Vehicle tasks share target, parameter, and lifecycle contracts.
• Route tasks maintain road traversal; local tasks convert the route into a current target.
• Final control submission sits at the seam between local execution and physics.
• Physics owns contacts, collision, transforms, and feedback; it does not own route or mission goals.

These conclusions are abstractions based on source structure, call relationships, and state distribution. They are not claims that one unique public implementation must have exactly these classes. Class names can be anonymized; responsibility boundaries cannot be blurred.

Failure Paths: An Executor Must Be Able to Reject

An executor is not an unconditional relay for control values. It may need to reject, clamp, or delay a request when the target is invalid, the vehicle is not ready, the physical body is not in the active world, the control source has changed, the input exceeds the vehicle’s capability, or the previous frame’s feedback indicates that continued execution would increase risk.

Rejection does not automatically mean mission failure. The runtime should distinguish:

• the current frame’s input being clamped;
• the target being temporarily unavailable;
• the executor not being ready;
• physical feedback interrupting execution;
• the task needing a new local target.

Only with these distinctions can the local-avoidance result, execution feedback, and later recovery logic form a continuous chain.

Scope of the Execution Layer

The execution layer passes an already formed target and command meaning into a type-specific executor. It establishes the seam between kinematic preview, control submission, and physical feedback. It does not redefine player input, maintain the global route, decide driving personality, or own complete damage, combat, and network authority.

The local-avoidance article answers how immediate risk changes a local choice. The execution layer answers how that local choice becomes movement the current vehicle can execute. The next article will continue with collision, damage, loss of control, and recovery. These topics form a continuous responsibility chain.

Conclusion: A Driving Command Becomes Motion at the Physics Seam

A driving command has no physical meaning until an executor interprets it for a specific movement model, submits it at the correct phase, and reads back what the physical world actually did. The credibility of vehicle control depends less on one steering formula than on whether target meaning, execution state, and physical feedback remain connected over time.

AI Collaboration Retrospective: Turning “How Does the Vehicle Move?” into Verifiable Seams

The useful role of AI in this part of the research is not to invent a universal vehicle controller. It is to compare source notes, identify where target ownership changes, separate preview from confirmed state, and produce a validation list for every seam. The human decision remains which relationships are supported by evidence and which are engineering abstractions.

II. Executors and Physics Phases

Why a Target Point Is Still Not a Control Quantity

A target point tells the vehicle where it should approach. It does not encode steering response, braking capability, traction, or movement mode. Treating a target coordinate as a control value collapses navigation, policy, execution, and physics into one layer.

The executor must preserve the distinction between target geometry and vehicle response. This is why the same target can produce different control results for a car, boat, aircraft, or rail vehicle.

From the Source Entry Point: An Automobile Task Is Not One Large Function

The source-oriented view suggests a chain of responsibilities rather than one monolithic driving function: a task owns intent, a follower evaluates local geometry, a controller derives control quantities, and a bridge submits them to the movement layer. The names may vary, but the phase and ownership boundaries are visible in the data that travels between them.

This decomposition also explains why a task can persist while the vehicle changes execution mode. The target and mission context need not be rebuilt merely because the current movement interface changes.

Why a Local Executor Needs Its Own Lifecycle

Local execution can begin, pause, resume, expire, or be replaced while the route and mission remain active. If it is treated as a stateless helper, the runtime cannot distinguish an old request from a current one or explain why a control value stopped being valid.

The local executor therefore needs at least an active state, a current target version, a last valid request, and an invalidation or completion reason.

Control Quantities Need Limits, Dead Zones, and State Gates

Raw control values are rarely safe to submit unchanged. Limits prevent a request from exceeding the current vehicle’s capability. Dead zones prevent small numerical noise from causing oscillation. State gates block inputs when the vehicle is inactive, transitioning, or physically unavailable.

These safeguards belong close to execution because they depend on the current movement model and runtime state. They do not replace policy; they protect the seam through which policy enters the vehicle.

Pre-Physics, Physics, and State Readback

The pre-physics phase resolves the current target, policy constraints, previous feedback, and movement mode into a request suitable for this frame. Within the execution layer, “Pre-Physics” is an abstraction for the stage immediately before physical integration; other engines may name or schedule it differently.

The physics phase applies contacts, constraints, forces, friction, suspension, buoyancy, and collision resolution. It may produce an outcome that differs from the request without indicating a bug in the executor.

The post-physics stage reads the actual transform, velocity, contacts, and failure state. It updates the vehicle runtime and supplies evidence for the next decision.

Rendering and camera systems consume reconciled state. They may smooth or present the result, but they do not become the authority for movement.

Why Transform Synchronization Is a Seam Problem

Transform synchronization is not merely copying a position. A vehicle’s pose, velocity, angular velocity, contact state, and control mode must remain coherent. If only the transform is copied, the next physical step may use stale velocity and produce a visible snap or energy discontinuity.

The synchronization boundary must therefore define which values are authoritative, when they are written, and how physical state is reconciled after the write.

Collision Lies Beyond This Scope, but It Changes Execution Feedback

Collision belongs to the physical result rather than to route ownership or high-level policy. However, contact and collision outcomes change the feedback available to the executor: velocity may change, the target may become unreachable, and a recovery path may be required.

Damage accumulation, fault classification, and long-term recovery are deferred to the next article. The execution layer carries the immediate physical evidence across the seam.

Buoyancy and Special Movement Models

Special movement models make the shared-contract principle visible. A boat’s propulsion is interpreted through water resistance and buoyancy. An aircraft’s command is constrained by attitude and flight envelope. A helicopter must distinguish lift and hover. These systems can share target intent and lifecycle semantics while maintaining different physical adapters.

The executor must expose when a model cannot interpret an input instead of silently pretending that a car-style control was applied.

III. Vehicle Compatibility and the Physics Seam

Vehicle Compatibility: Shared Contract, Different Motion Semantics

Three Common Wrong Architectures

This bypasses contact resolution and makes the physical world a display layer. It also causes task completion, collision, and velocity state to disagree.

This produces a common API at the cost of incorrect movement semantics. Boats, aircraft, and rail vehicles need different control interpretation.

If collision and contact results only affect camera shake or effects, the next control decision continues from a fictional state. Feedback must return to execution and task evaluation.

Observability: The Execution Seam Must Be Inspectable

An execution seam should expose the current target version, interpreted error, requested control, accepted or rejected status, physical result, and failure reason. Without these observations, a vehicle that “does not move correctly” cannot be distinguished from an invalid target, an unavailable body, a rejected request, or a physical limitation.

Observability is not a replacement for implementation. It is the minimum evidence needed to test the boundary.

Engineering Verification for the Execution Layer

Target Continuity

The current target must remain identifiable across frames and must be invalidated when replaced.

Executor Isolation

Changing an automobile executor must not silently modify the boat or aircraft executor.

Physical Feedback Loop

The next request must be able to consume actual velocity, contacts, and failure state.

Phase Timing

Requests must be submitted before integration and confirmed after integration.

One update cycle can be split into four steps. First, frame N begins with the velocity and contact state left by the previous frame. Second, the executor combines that state with the current local target, creates a candidate request, and submits it before integration. Third, physics solves contacts, friction, external forces, and interactions with other bodies. Fourth, the runtime reads the new transform, linear velocity, angular velocity, and contact result as frame N’s actual feedback. Frame N+1 consumes that feedback rather than the preview from before submission.

The phrase “the same frame” is easy to misuse. The request is based on a snapshot frozen before integration; the feedback describes a result produced afterward. If task completion is written during the post-physics stage, or if a contact result is read before it exists, two time points become one state. The task may believe that a local target was reached while physics has not produced the corresponding pose, or the executor may continue using pre-collision velocity after the body has already hit an obstacle.

The executor should distinguish late feedback from missing feedback. Late feedback belongs to an earlier request and must not overwrite the current request. Missing feedback may mean that physics is not connected, the entity has temporarily left the physical world, or the update was skipped. Neither case should silently become zero velocity. A cycle identifier, request version, and feedback status let the upper layer wait, limit, recompute, or enter recovery explicitly.

Failure Rejection

Invalid or unsafe requests must be limited, delayed, or rejected with an observable reason.

The Physics Seam: From Physics Entry to State Confirmation

Entering the Physical World Is More Than Creating a Rigid Body

Before an entity can participate in physical integration, its collision representation, movement mode, ownership, and update registration must be valid. Creating a body without connecting it to the runtime’s phase and feedback chain produces an object that exists physically but cannot be driven coherently.

Removing a Body from Physics Also Affects the Task

When an entity leaves physical participation, the task cannot continue to assume that control requests will produce movement. The executor must expose an unavailable or suspended state, while the upper layer decides whether to wait, preserve the target, or enter a different representation.

Transform and Velocity Synchronization Must Be Grouped

Writing a transform without matching velocity changes the physical interpretation of the next frame. Writing velocity without a coherent pose creates an equally artificial result. These values should be reconciled as one state transition at the seam.

Why Collision History Cannot Belong Only to Presentation

Recent contacts can explain why a vehicle failed to turn, stopped earlier than expected, or entered a recovery path. If the history is retained only for effects, the execution layer loses evidence required for the next decision.

The Actual Conflict Between Pre-Physics Control and Post-Physics Confirmation

The executor submits an expectation before physics and receives an outcome after physics. A robust runtime does not resolve this conflict by forcing the outcome to match the expectation. It records the difference, updates state, and lets the next frame correct the request.

A Speed Limit Is Not Decided by the Executor Alone

The executor can enforce movement-model limits, but desired speed may also be constrained by route geometry, policy, local risk, traffic context, and physical feedback. The execution layer consumes these constraints; it does not own every reason behind them.

Executor Completion Requires Evidence

Completion should be supported by target distance, speed, heading, contact, and stable state evidence. A request being submitted is not proof that the vehicle completed the intended motion.

Empty Execution and the Null Adapter

An empty or null adapter can preserve the lifecycle when a physical implementation is unavailable. It allows upper layers to continue developing against the same seam while reporting that no physical motion was accepted. This is safer than pretending that a missing adapter succeeded.

What to Preserve When Migrating to a Target Engine

The migration priority is not copying source class names. Preserve the phases, target ownership, control submission boundary, physical feedback contract, invalidation semantics, and observability. The target engine may use different modules and scheduling primitives, but it must retain the distinction between intention, execution, and physical confirmation.

Failure Verification and Migration Boundaries

Final Abstraction

The execution layer can be represented as:

The value of this chain is not its names. It is the fact that each stage has a defined owner and a defined failure boundary.

IV. Failure, Feedback, and Observability

A Control Request Is Not Formed in One Calculation

A request may be assembled from target geometry, current speed, policy limits, avoidance results, vehicle mode, and last-frame feedback. Treating it as one pure calculation hides the points at which state can become stale or invalidated.

Expanded, this request is closer to a short-lived lifecycle record than to three floating-point values. It should distinguish the source of the request, the identity and version of the current local target, the way the executor interpreted that target, the vehicle’s eligibility to submit to physics, the accepted or rejected result, and the reason the request ended. These fields prevent different layers from interpreting the same zero value as different facts. Zero propulsion may be an intentional stop, or it may mean that physics is not ready. Zero steering may mean that the target is aligned, or that the target version has expired.

The request is created during a computation period, validated against current source and target versions, interpreted by the vehicle-specific executor, and submitted at the correct phase. After physics, it receives a result or is marked unconfirmed. Before the next period, the runtime decides whether it can be continued. A change in target version, source version, vehicle mode, or physics participation invalidates the old request and requires interpretation again.

This lifecycle explains several source-reading failures that otherwise look unrelated: a task completes too early, steering jumps for one frame, or a vehicle continues receiving input after leaving physics. The visible symptom is a wrong control value; the deeper problem is that a request outlived its validity window or was built from a mixed snapshot. The useful evidence is when the request was created, submitted, confirmed, and cleared.

Zero Control and Control Failure Are Different

Zero throttle or zero steering may be a valid command. A failed control update means the request was not accepted, could not be interpreted, or was blocked by state. The executor must preserve this distinction so the upper layer does not mistake an intentional idle state for an unavailable vehicle.

The runtime must distinguish target replacement, control-source replacement, and physical representation replacement. A route may select a new local target while the same executor remains active. The player or AI may become the new command source while the route remains valid. A vehicle may leave a simplified representation and re-enter real physics while both target and source are preserved. These transitions must not be represented by one generic vehicle reset: target replacement must not clear driver identity, source replacement must not delete the route, and physics replacement must not be mistaken for task completion.

An execution result should be more expressive than success or failure. At minimum, it can be accepted, limited, delayed, or rejected. Accepted means that the request entered the current physical submission. Limited means that the target remained valid but the current state allowed only part of the request. Delayed means that the request may become eligible in a later cycle. Rejected means that the request is incompatible with the target version, permissions, vehicle mode, or physical state. These results cannot be compressed into one Boolean without losing the recovery decision.

Steering, Propulsion, and Braking Are Not Three Independent Knobs

At speed, steering affects curvature and stability; braking changes stopping distance and available grip; propulsion changes velocity and the time available for correction. The executor must resolve their interaction rather than treating them as unrelated scalar writes.

From Automobile Task to Final Control Submission

The automobile task provides intent and context. Local geometry produces relative error. Control generation applies limits and state gates. The movement bridge submits the result and receives physical evidence. The task should not bypass this chain to write directly to the body.

The units and reference frames at this seam are equally important. Routes and local targets may be expressed in world or road coordinates, while the executor may require forward error, lateral error, and relative heading in vehicle-local coordinates. Physics may return world velocity, body-local velocity, or contact-point velocity. For example, after the vehicle rotates, “right” in world coordinates is not necessarily the same as positive steering in the vehicle’s local frame. Without an explicit reference frame, the controller may look correct on a straight road and gradually reverse its interpretation after a turn.

For that reason, a request should carry the meaning of its values, not only their numeric representation. Is desired speed a scalar along the route tangent or the vehicle’s forward speed? Is steering a steering-wheel ratio, a curvature target, or a lateral-acceleration request? Is braking a desired deceleration or an already converted actuator value? Upper layers should use stable semantics; the executor performs unit and reference-frame conversion and lets physical feedback confirm the result.

Exposing every low-level control quantity to tasks would leak ownership in both directions. If a task begins to manage tire angle, drive force, and suspension compression, it has become an executor. If the executor reads task stages and chooses destinations, it has become the task owner. The seam exists so each value can be traced to a semantic source and to a physical consequence.

Why a Physical Preview Must Not Be Written as a Deterministic Fact

Preview is valuable because it is cheap and repeatable enough for decision-making. It remains an estimate. Collision, friction, slope, and other bodies can change the result. A runtime that treats preview as truth will fight physics instead of using physics as feedback.

The Minimum Feedback Contract for Physical Anomalies

At minimum, the executor should be able to report whether a request was accepted, limited, delayed, rejected, physically blocked, or completed with a divergent result. This compact contract supports recovery without exposing every solver detail to the task layer.

Compatibility Checks for Four Vehicle Families

Automobiles need wheel and contact interpretation. Boats need buoyancy and water resistance. Aircraft need attitude and thrust interpretation. Rail vehicles need track constraints. All four can share lifecycle and target semantics while keeping movement-specific control laws separate.

Compatibility is not one universal Drive function. It is a stable upper-level vocabulary combined with vehicle-specific state spaces. Shared semantics may include target direction, distance, desired speed, stop intent, validity, and feedback status. The interpretation is different: an automobile maps these ideas to tires and transmission, a boat to propulsion, rudder response, buoyancy, and water resistance, an aircraft to attitude, thrust, and flight envelope, and a rail vehicle to traction and braking along a track topology.

Each vehicle family also needs explicit rejection semantics. A rail vehicle cannot accept an unconstrained lateral command; a submerged vehicle cannot treat land contact as a valid water-movement condition; a fixed-wing aircraft cannot accept an arbitrary in-place turn. Rejection is not silent failure. It tells the upper layer whether to wait, change the target, reduce the request, or select another task. This lets a new vehicle add its interpretation and feedback without rewriting every route and task layer.

The same forward intent may become wheel force in a car, propeller output in a boat, a combination of thrust and attitude in an aircraft, or longitudinal traction in a train. A matrix that lists only input names is incomplete; it must also state which constraints and physical state make that input meaningful.

Debugging Order for an Executor

Check the target version first, then the interpreted error, then the generated request, then the submission status, then the physical result, and finally the task reaction. This order follows the seam from upper meaning to lower evidence and prevents debugging presentation symptoms before execution state.

Public Scope

The execution layer explains the execution seam between a formed driving command and real movement. It does not claim to reproduce one unique source implementation, and it does not replace the detailed treatment of damage, combat, network authority, or replay.

V. Continuity of Execution State

The Executor Is Working Even When the Vehicle Is Stationary

A stationary vehicle may be holding position, waiting for a conflict, braking, lacking contact, or rejecting an invalid request. “No displacement” is therefore not enough to conclude that execution is inactive. The reason for the stationary state is part of the feedback contract.

Slope, Low Grip, and External Forces Change Feedback, Not the Target

The target may remain valid while the vehicle’s ability to reach it changes. A slope, low-friction surface, wind, water resistance, or collision can alter the physical response. The executor reports the result; upper layers decide whether to preserve or replace the target.

Clearing a Control Request Is Also Part of the Seam

When a target expires or a control source changes, the previous request must be cleared or superseded explicitly. Leaving a stale throttle, brake, or steering value active can make the vehicle continue acting after the task has changed.

Replacing a Target Is Not the Same as Replacing Control

A route may select a new local target while the same control source and executor remain active. Conversely, the player or AI may change control source while the route remains. These are separate transitions and should not be represented by one generic reset.

Conclusion: The Physics Seam Determines Whether Driving Feels Credible

Lights, sound, camera motion, and effects may consume executor and physics state. They should not write back into movement authority. Presentation can expose accepted commands, slip, impact, or failure, but it does not decide whether the vehicle reached its target.

Real and Simplified Physics Can Share the Same Seam

A low-detail or remote representation can use simplified motion while preserving the same target, request, feedback, and invalidation contract. This allows the representation to change without forcing tasks to know which physical fidelity is currently active.

A Complete Timeline of One Failed Execution

The target is valid and a turn request is generated. The executor accepts the request, but the vehicle reaches a low-grip surface before the next confirmation. The body understeers, contact feedback reports insufficient lateral response, and the next frame reduces speed rather than snapping the pose. The local task then decides whether to continue, choose another point, or request recovery.

The important fact is that failure occurs after submission, not before it. The runtime must retain the sequence of request, physical outcome, feedback, and correction.

The Test Matrix Must Cover Request and Result Disagreement

Tests should include accepted requests with divergent physical outcomes, rejected requests with valid targets, target replacement during execution, body removal, low-grip contact, and zero-control states. A test suite that checks only whether a request was generated cannot verify the physics seam.

Failure verification also needs more than a success/failure flag. The executor should distinguish an invalid target, an unavailable physical body, an expired request, a movement limitation, an external interruption, and an explicit cancellation. The executor can report that a request was not accepted, that movement capacity was insufficient, or that feedback diverged from expectation. It should not decide by itself whether the mission failed, the route should be rebuilt, or the vehicle has entered a damage state. The upper layer needs the reason in order to choose a retry, a wait, a new local target, or a recovery task.

This distinction matters when reading source code. A false return value does not automatically mean that the vehicle task failed. It may mean that the current phase is not applicable, the body is not ready, another source has replaced the request, or the executor intentionally rejected an unsafe input. Trace how the result is consumed, whether it carries a termination reason, whether the next cycle retries it, and whether the previous state is preserved.

An observability chain should reconstruct one complete execution period rather than merely store the vehicle’s final position. It should be possible to identify the target and its version, the snapshot that was read, the candidate request, the limits applied by the executor, whether submission occurred, the physical result, and the upper-layer reaction. Cycle-level records confirm phase and version continuity; event-level records capture target replacement, source handoff, physics entry, collision interruption, and rejection. Detailed context can be retained only when the result diverges or recovery begins.

This evidence also separates “a call occurred” from “the vehicle was affected.” A task may generate a target that the current executor never consumes. A physics bridge may update a transform without returning it to task state. A control bridge may be called while an invalid version prevents any value from being submitted. Only tracing the request and feedback together proves that the responsibility boundary is real.

The test set should therefore include more than straight driving and normal stopping: replace the target during calculation, delay physics entry for several cycles, push the body after submission, release the source immediately after acceptance, keep zero speed while the task remains active, return a late request after a vehicle-mode change, and re-enter real physics from a remote representation. All of these cases ask whether the runtime can acknowledge that the current request is no longer applicable. Explicit invalidation is not a failure of the runtime; it is a condition required for continuity.

The execution seam can also be understood as coordination between different update frequencies. Routes and tasks do not need to rebuild their targets at every physics substep. Policy and avoidance may update on their own cycles, while physics continuously produces contact and velocity results. The executor must know which upper-layer result is still valid, which feedback belongs to the next formal computation, and which late request must be discarded. It must neither treat a slow target as fresh every frame nor write fast physical feedback directly into task ownership.

Once those frequency relationships are explicit, steering response, post-impact correction, and vehicle-specific latency stop being isolated feel parameters. They become consequences of facts crossing the runtime at different phases. The physics seam preserves temporal continuity between semantics, submission, and feedback.

The following collision and recovery article inherits this interface. It receives more than an isolated “collision occurred” flag: it receives a record containing request version, physics phase, contact result, and execution divergence. With that context, the next layer can distinguish ordinary limitation, temporary interruption, and persistent loss of control that requires recovery.

A Source-Reading Method for the Execution Layer

Reading an executor should not begin by searching for a class whose name resembles “controller.” A more reliable path starts with an observable behavior: a vehicle approaches a target, slows before an obstacle, is pushed off course, or re-enters the physical world from a remote representation. Record the state before and after the behavior, then follow target selection, local geometry, request construction, physical submission, and feedback readback. The result is a mechanism chain rather than a list of isolated types.

For each entry point, record five questions: where the input comes from, which update phase owns the entry, what state it modifies, what result it gives to the next layer, and who continues after failure. A function that computes relative heading should not be described as completing the drive. A function that submits a value to the physics bridge should not be described as choosing the destination. Responsibility must be demonstrated by data flow and timing together.

Three kinds of evidence should remain separate. Direct evidence includes calls, parameter reads, field writes, and phase registration that can be located in code. Responsibility evidence comes from several entry points sharing a lifecycle and feedback pattern, allowing a common contract to be abstracted. Migration inference is a target-engine design proposal and must not be rewritten as a fact about the source implementation. Mixing these categories makes prose sound certain while hiding which statements are observations and which are engineering choices.

The seam also requires a reverse check: who is deliberately absent? A route task not reading tire contact is not incomplete; it receives movement evidence indirectly through local targets and execution feedback. A physics system not knowing the mission stage is not missing a feature; it owns physical results. A camera not correcting vehicle heading is not a limitation; it consumes the result and presents it. These absences prevent ownership from leaking across the seam.

This method explains why the article must discuss both kinematic preview and physical feedback. Preview is a cheap interpretation of intent that can be used between complex routes and local targets. Physics supplies constraints that cannot be skipped and determines whether the vehicle actually followed the preview. Neither replaces the other. The seam between them is the runtime core of a driving command becoming motion.

When migrating to another engine, the most valuable artifact is not the complete shape of a source class. It is the traceable chain: targets have versions, requests have sources, submission has a phase, physical outcomes have confirmation, failures have reasons, and the next frame has a correction path. A different scheduler, container, or physics API can preserve this chain; a single synchronous function cannot preserve the later handoff, streaming, collision, and recovery states.

Start from the vehicle intelligence or task entry point, follow target and control data through local execution, identify the phase at which movement is submitted, and then trace physical state back to the next task update. Record responsibilities, timing, state transitions, and invalidation reasons before assigning names to abstractions.

VI. From the Execution and Physics Seam to the Next Article

From the Execution and Physics Seam to the Next Article

The execution layer stops at immediate physical feedback. The next article continues with persistent collision state, damage, loss of control, and recovery. The handoff is the feedback record: the execution layer reports what happened; the next article decides how the vehicle’s damaged or failed state persists.

Versions Protect the Seam, Not Merely the Data Format

A request version protects against stale control being applied after a target, source, or physical state has changed. Versioning is therefore a lifecycle guard at the seam, not just a serialization detail.

Acceptance Criteria for the Execution Layer

The execution layer should make target ownership explicit, distinguish prediction from confirmation, support type-specific interpretation, report rejection and physical divergence, respect phase timing, and clear stale requests. These criteria describe a verifiable runtime boundary rather than a particular class hierarchy.

Core Lessons

First, a target is not a control quantity. Second, an executor interprets intent for a movement model rather than replacing policy. Third, physical results must return to the next decision. Fourth, shared vehicle compatibility belongs in lifecycle and contracts, not in a universal control law. Fifth, rejection and empty execution are valid runtime states.

Conclusion: The Physics Seam Determines Whether Driving Feels Credible

Driving feels credible when the command, the predicted motion, the physical result, and the next correction remain part of one continuous state chain. The vehicle does not need to obey every request literally; it needs to respond consistently to accepted, limited, delayed, and rejected requests.

The local-avoidance article determines how immediate risk changes local choice. The execution layer determines how that choice becomes movement. The next article will determine how collision and failure persist afterward. Across these layers, the key question remains the same: who owns the state, who may modify it, and what evidence proves that the modification occurred?