Zero-Torque Counterfactual

The Zero-Torque Counterfactual (ZTCF) family: definition, interpretation, and numerical computation algorithm for the AffineDrift golf swing framework.
Author

Dieter Olson

Published

August 30, 2026

Not familiar with control theory or differential equations? Here is what the Zero-Torque Counterfactual means in everyday language.

The Model Branch

Imagine freezing the modeled swing at the top of the downswing and asking: "If the model's applied generalized control were set to zero here, where would the club go?"

The answer is a forward Zero-Torque Counterfactual (ZTCF): a model-conditioned intervention with declared generalized-control channels set to zero. Only the forces, constraints, contacts, and internal states explicitly retained by the record remain.

Software analogy: Copy one simulator state, change one named input vector to zero, and advance both branches under their declared protocols. This analogy concerns model bookkeeping, not what a golfer's muscles do.

Why Does This Matter?

Comparing two registered model branches yields a simulated trajectory difference. Whether that difference is used as a contribution measure or a causal estimand requires additional assumptions. It does not identify individual muscle forces, co-contraction, metabolic effort, or conscious intent.

ZTCF evaluates one declared intervention. Interpretation is conditional on the exact model and version, branch state, zeroed inputs, retained inventory, solver, frame, units, horizon, and uncertainty treatment.

A Thought Experiment, Not a Real Swing

ZTCF is a mathematical intervention, not a measurement of muscle state. A generalized torque can be zero under one coordinate convention even while internal muscle forces, co-contraction, or contact loads are nonzero and unidentified.

Impedance boundary: Stiffness and damping are retained only when the intervention record declares them as fixed plant parameters or internal states. The intervention does not establish that those quantities were identified from a golfer or can be maintained independently of activation.

NoteNovelty Status
  • Established (textbook): Lagrangian drift/input decomposition of control-affine systems; counterfactual simulation as a diagnostic technique in mechanics.
  • Project convention: Applying the ZTCF family to declared golf models and requiring a machine-readable intervention record before publishing a result.
  • Terminology: “Zero Torque Counterfactual (ZTCF)” is the authors’ label for this construction in the golf context; the underlying mathematics is standard rigid-body dynamics.
ImportantCanonical ZTCF Definitions (Glossary)

This article is the canonical reference for “ZTCF” across the AffineDrift site. All other articles should link here on first use. Four related objects are in circulation; the qualifier is required on first use:

  1. Pointwise ZTCF sample\(f(x(t))\), the zero-applied-control evaluation at one achieved state. It is an instantaneous vector, not a forecast. “Pointwise drift vector” is the preferred generic name; “pointwise ZTCF sample” is retained for compatibility with the WSCG archive and must carry the qualifier.

  2. Stitched pointwise ZTCF trace — the time-indexed collection \(\{f(x(t_k))\}\) evaluated along achieved states. Its samples do not form a dynamically integrated trajectory because each sample is reset to a different achieved state. It supports same-state attribution but cannot establish persistence after control removal.

  3. Forward ZTCF trajectory\(x^{\mathrm{ZTCF}}(t; x_0, t_0)\), the solution of \[\dot{x}^{\mathrm{ZTCF}}(t) = f\!\left(x^{\mathrm{ZTCF}}(t)\right), \qquad x^{\mathrm{ZTCF}}(t_0) = x_0, \qquad t \in [t_0, t_1].\] This is a dynamically integrated trajectory, not a pointwise sample.

  4. Branched ZTCF trajectory — the forward ZTCF trajectory (3) initialized from an achieved or simulated reference state \(x_0 = x^{\mathrm{reference}}(t_0)\), then compared with a separately integrated reference branch for \(t > t_0\). A publishable result requires the intervention record below; the construction name alone is not validation.

The drift vector field \(f:\mathcal{X}\rightarrow T\mathcal{X}\) is the state-dependent map underlying all four constructions. It is not a trajectory or a dataset. Pointwise and stitched results may support same-state attribution; only a forward or branched rollout can test whether an effect persists after the applied control is removed.

Articles must qualify the construction on first use and either link to this definition or state the local convention explicitly.

1 Normative Intervention and Interpretation Contract

Every executable or quantitative ZTCF result must conform to affinedrift.ztcf-intervention/v1. The normative schema and golden fixture make the following fields reviewable:

Contract Area Required Declaration
Model authority Model ID and version, exact source revision, engine and engine version, and all parameters needed for replay
Branch state Coordinates, values, units, reference frame, and the provenance of the initial state
Intervention Physical level and exact channels set to zero; no implication that another torque, activation, or force was removed
Retained inventory Other controls, constraints, contacts, external loads, internal states, and parameter-freezing rule
Integration Start and end time, units, solver and version, steps or tolerances, and finite-horizon postconditions
Interpretation Simulated trajectory difference, contribution measure, causal estimand, physiological interpretation, and non-identifiability limits as separate fields
Failure invalid_contract, engine-unavailable, engine-unsupported, and numerical_failure are fail-closed states, not missing values that another result may fill

The registered fixture supports only the repository’s Python GolfModel.ztcf_trajectory/v1 algorithm for one declared planar model. It is a deterministic software regression, not a human or cross-engine validation. MATLAB, Simulink, MuJoCo, Pinocchio, and other engines have no parity claim under this contract unless a second supported adapter, exact model translation, golden fixture, metric, and tolerance are registered.

1.1 Interpretation Ladder

These outputs must not be collapsed into one claim:

  1. A simulated trajectory difference compares two numerical branches.
  2. A contribution measure adds a declared projection, norm, event, or work functional.
  3. A causal estimand additionally requires a defensible intervention, exchangeability or structural assumptions, and treatment of model discrepancy.
  4. A physiological interpretation requires measurements and an identifiable mapping from generalized inputs to muscle, tissue, neural, or effort quantities.

The first item does not imply the next three. Each result must state its non-identifiability boundary even when numerical replay succeeds.

2 Motivation

Golf-swing models combine inertial, gravitational, elastic, damping, contact, and declared input terms. Inverse dynamics estimates net generalized quantities under a model and measurement pipeline; it does not uniquely allocate them to individual muscles, tissues, co-contraction, or intent.

The drift–input decomposition of the control-affine system \(\dot{x} = f(x) + G(x)u\) provides the formal separation between passive dynamics \(f(x)\) and input-driven dynamics \(G(x)u\). However, this separation is instantaneous: it classifies the current velocity of the state, not the trajectory over time. The golf swing is not an instant; it is a history-dependent ballistic process in which momentum generated during the backswing shapes forces throughout the downswing.

To convert the instantaneous decomposition into a trajectory-level diagnostic, we integrate the drift-only equations forward from a chosen initial state. The resulting trajectory is the forward Zero-Torque Counterfactual (ZTCF) trajectory.

3 Formal Definition

3.1 Control-Affine Setting

Following Part I of this series, the golfer–club–shaft system is governed by the nonlinear control-affine equations of motion:

\[\dot{x} = f(x) + G(x)\,u, \qquad x(t_0) = x_0,\]

where:

  • \(x(t) = [q(t),\,\dot{q}(t),\,\eta(t),\,\dot{\eta}(t)]^T\) is the state vector (rigid-body generalized coordinates \(q\), their velocities \(\dot{q}\), flexible shaft modal coordinates \(\eta\), and their velocities \(\dot{\eta}\)),
  • \(f(x)\) is the drift vector field — the autonomous, torque-free evolution of the system,
  • \(G(x)\) is the input matrix — how applied joint torques enter the equations,
  • \(u(t)\) is the declared vector of applied generalized torques, not an identified vector of muscle forces or activations,
  • \(t_0\) is the initial time at which the counterfactual branches.

The drift field \(f(x)\) contains exactly the autonomous effects assigned to it by the declared effective plant. Depending on the record, those may include inertial coupling, Coriolis and centrifugal terms, gravity, elastic or damping forces, contact, and exogenous loads. Calling the field passive does not make its inventory universal or physiologically identified.

3.2 The ZTCF Trajectory

Let \(x(t)\) denote the actual trajectory of the system under some torque input \(u(t)\) on the interval \(t \in [t_0, t_f]\), with initial condition \(x(t_0) = x_0\).

We define the forward Zero-Torque Counterfactual trajectory, denoted \(x^{\mathrm{ZTCF}}(t)\), as a solution of the declared drift-only initial value problem:

\[\boxed{\dot{x}^{\mathrm{ZTCF}}(t) = f\!\left(x^{\mathrm{ZTCF}}(t)\right), \qquad x^{\mathrm{ZTCF}}(t_0) = x_0.}\]

By construction:

  1. The branch state, coordinates, units, and frame are recorded explicitly.
  2. Parameters, constraints, contacts, loads, and internal states follow the retained-inventory record.
  3. The named generalized-torque channels are held at zero over the declared finite horizon.

Existence and uniqueness require the usual initial-value regularity over the declared horizon. A singular constraint solve, undefined contact transition, nonfinite state, unavailable engine, or unsupported algorithm is a failure state; it is not replaced by an inferred trajectory.

3.3 The Torque-Driven Deviation

Along the actual trajectory, the state derivative contains both drift and input contributions:

\[\dot{x}(t) = f\!\left(x(t)\right) + G\!\left(x(t)\right)\,u(t).\]

Along the ZTCF trajectory, the derivative contains only the drift:

\[\dot{x}^{\mathrm{ZTCF}}(t) = f\!\left(x^{\mathrm{ZTCF}}(t)\right).\]

Within the fixed declared plant, setting \(u=0\) removes the term \(G(x)u\). The two branches then visit different states, so their difference is a model-conditioned simulated trajectory difference. It is not automatically an additive torque contribution, a causal estimand for a real golfer, or a physiological interpretation.

4 Geometric Interpretation

When the initial-value problem is well posed, a forward ZTCF is an integral curve of the declared drift vector field \(f\) through \(x_0\) at time \(t_0\).

The registered model may retain:

  • Inertia — the momentum of all rigid segments, accumulated through the backswing and early downswing,
  • Centrifugal and Coriolis forces — arising from the high-speed rotation of the arm-club chain,
  • Elastic shaft recoil — the restoring force of the bent shaft as it tries to return to its neutral shape,
  • Passive joint damping — any modeled energy dissipation in the joints.

What is absent from the forward ZTCF is the declared applied generalized-control input. Passive tissue, joint, shaft, contact, damping, and structural forces remain if they are included in \(f\). The difference between \(x(t)\) and \(x^{\mathrm{ZTCF}}(t)\) captures the cumulative modeled consequence of removing that input; it does not uniquely recover muscle forces. Broadly:

  • Close branches show a small difference in the declared metric and horizon; they do not prove that control, muscle activity, or effort was small.
  • Divergent branches can reflect the intervention, nonlinear state evolution, parameter or initial-state error, omitted loads, contact changes, or numerical error.

5 Relationship to the Drift–Input Decomposition

The drift–input decomposition used throughout this series is the algebraic identity:

\[\dot{x} = \underbrace{f(x)}_{\text{declared drift}} + \underbrace{G(x)\,u}_{\text{applied input}}.\]

This identity is instantaneous: it classifies the current velocity vector at a single point in time. A forward ZTCF extends the instantaneous evaluation into the temporal domain by integrating the declared drift field.

At the torque-force level, the decomposition reads:

\[\tau_{\mathrm{total}}(t) = \tau_{\mathrm{drift}}\!\left(x(t)\right) + \tau_{\mathrm{input}}(t),\]

where the drift torque \(\tau_{\mathrm{drift}}\) is the generalized force associated with the declared drift acceleration \(a_{\mathrm{drift}}(x)\) along the achieved trajectory, and \(\tau_{\mathrm{input}}\) is the modeled applied-input remainder. Neither term uniquely identifies muscular effort. A forward ZTCF provides a trajectory-level realization of the declared drift field from the same initial state.

NoteWorked Illustrative Example

The values below are hypothetical and chosen only to illustrate the decomposition method.

Consider a snapshot during mid-downswing. Inverse dynamics applied to the actual trajectory yields a lead-shoulder torque magnitude of \(\tau_{\mathrm{total}} = 100\,\mathrm{Nm}\). Evaluating the passive drift terms at the actual state gives \(\tau_{\mathrm{drift}} = 85\,\mathrm{Nm}\). The input torque is therefore:

\[\tau_{\mathrm{input}} = 100 - 85 = 15\,\mathrm{Nm}.\]

Under the illustrative model inventory, drift terms account for 85% of the generalized load at this instant. This does not establish a fraction of muscle force or biological effort. In the takeaway the modeled ratio could be reversed: for example, 60 Nm applied input against 10 Nm drift. The evolution of this declared mechanical decomposition is invisible in raw inverse dynamics but explicit in the drift–input analysis centered on the ZTCF.

6 Relationship to DCR and Reachability

DCR compares declared drift and bounded input-effect magnitudes in one projection and metric. It does not establish that a forward ZTCF approaches an achieved trajectory, that the ZTCF is an attractor, or that other finite-horizon outcomes are unreachable. Those questions require the admissible control set, horizon, task metric, uncertainty, and event definition documented in the corrected Drift-Control Ratio article. A ZTCF branch remains one model-conditioned intervention at every DCR value.

7 Numerical Algorithm

This section describes the generic integration pattern. The only governed executable result published here is the Python golden fixture linked in Section 1. No current MATLAB or Simulink model/version/input record or cross-engine parity artifact is registered, so results attributed to those engines are unavailable under this contract.

7.1 Notation and Discretization

Let the continuous-time state be

\[x(t) = [q(t),\,\dot{q}(t),\,\eta(t),\,\dot{\eta}(t)]^T,\]

and let the simulation produce samples at discrete times

\[t_k = t_0 + k\,\Delta t, \qquad k = 0,\dots,N.\]

Let:

  • \(x_k\) denote the simulated state at time \(t_k\),
  • \(u_k\) denote the applied torque input at \(t_k\),
  • \(f(x_k)\) denote the drift acceleration vector at \(x_k\),
  • \(x^{\mathrm{ZTCF}}_k\) denote the ZTCF state at time \(t_k\).

7.2 Branch-Switch Pattern

A branch-switch implementation must capture the complete declared state, set only the registered input channels to zero, apply the retained contact/load/ constraint protocol, and integrate with the registered solver to the registered horizon. Describing a switch block is not evidence that an engine implements that contract. Engine-unavailable and engine-unsupported requests fail closed.

7.3 Discrete-Time Integration

For a general-purpose discrete implementation, the ZTCF trajectory can be approximated by integrating the drift field:

\[x^{\mathrm{ZTCF}}_{k+1} = x^{\mathrm{ZTCF}}_k + \Delta t\,f\!\left(x^{\mathrm{ZTCF}}_k\right) + \mathcal{O}(\Delta t^2),\]

with the initial condition \(x^{\mathrm{ZTCF}}_0 = x(t_0)\).

In practice, higher-order integration should be used. The drift ODE is nonlinear and can be stiff during the high-acceleration phase of the late downswing. Recommended solvers:

  • Adaptive solvers may be used only with recorded implementation/version, tolerances, event behavior, and convergence evidence.
  • Fixed-step solvers require their method, step count or size, endpoint rule, and refinement check.

7.4 Consistency Verification

Once the ZTCF is computed, numerical implementation correctness can be verified using the identity:

\[\tau_{\mathrm{total}}(t_0) - \tau_{\mathrm{ZTCF}}(t_0) = \tau_{\mathrm{input}}(t_0),\]

where \(\tau_{\mathrm{ZTCF}}\) records the full drift (configuration- and velocity-dependent) at the branch instant, so subtracting it from the total leaves the input. This is not the ZVCF: the configuration-only (zero-velocity) slice is \(\tau_{\mathrm{ZVCF}} = \tau_{\mathrm{drift}} - \tau_{\mathrm{vel.drift}}\) and contains no input term. Equating \(\tau_{\mathrm{total}} - \tau_{\mathrm{ZTCF}}\) with \(\tau_{\mathrm{ZVCF}}\) is a category error (input \(\neq\) configuration drift); their difference is the velocity-dependent drift \(\tau_{\mathrm{vel.drift}}\), which dominates in the late downswing.

WarningApproximation Note

This same-state identity is exact only at \(t=t_0\) under the declared affine model and force convention. After branching, the two trajectories generally occupy different states, so subtracting forces evaluated along them is not the same algebraic decomposition. Any claimed approximation interval requires a registered metric, tolerance, and convergence result.

7.5 Practical Considerations

Consistent parameter sets. All inverse-dynamics evaluations and drift field computations must use the exact same inertia, stiffness, and damping parameters to ensure numerical consistency. The recovered input \(\tau_{\mathrm{total}} - \tau_{\mathrm{ZTCF}}\) should match the directly applied \(\tau_{\mathrm{input}}\), and the configuration slice \(\tau_{\mathrm{ZVCF}}\) should match \(\tau_{\mathrm{drift}} - \tau_{\mathrm{vel.drift}}\).

Solver declaration. A comparison must declare both solvers, versions, tolerances or step sizes, endpoint behavior, and numerical sensitivity. Using the same solver can reduce one source of discrepancy but does not validate the model or intervention.

Filtering. When applied to motion-capture data, velocities and accelerations should be computed from smoothed position data (e.g., Savitzky–Golay filter) before evaluating the drift field, to prevent amplification of measurement noise.

8 Scope and Limitations

8.1 What the ZTCF Answers

The ZTCF answers a precisely defined question within the mechanical model:

“Under this exact model record and retained-inventory protocol, what branch is computed when these declared applied generalized-torque channels are set to zero from \(t_0\) to \(t_1\)?”

It does not claim that such a motion could be physically achieved by a real golfer, that the nervous system selects zero torque, or that the numerical branch isolates a unique biological cause. It is a model-conditioned intervention on named inputs.

8.2 Key Limitations

WarningZTCF Cannot Be Directly Measured From Real Swing Data

The ZTCF trajectory is not directly observable from real golf swing data. Three identifiability challenges apply:

  1. Generalized torque is not muscle state. Net generalized torque, individual muscle forces, activation, co-contraction, impedance, and metabolic effort are different quantities. Zeroing one modeled torque vector identifies none of the others.

  2. Requires a complete dynamic model. To evaluate \(f(x)\) at the measured state, one needs the full inertia matrix \(M(q)\), the Coriolis/centrifugal matrix \(C(q,\dot{q})\), gravity \(g(q)\), and shaft elasticity parameters. Each parameter introduces model uncertainty that propagates directly into the ZTCF estimate.

  3. Initial condition and model sensitivity. A nonlinear rollout can amplify initial-state, parameter, contact, and solver differences. Reliability is case-specific; no universal short-horizon duration is asserted without a registered sensitivity result.

ZTCF software should first pass manufactured or golden-fixture checks, then model and measurement uncertainty must be evaluated separately. Passing a software fixture is not validation against real swing data.

This is not a no-muscle simulation. It is a declared generalized-input intervention whose physiological interpretation remains unavailable without an identified musculoskeletal model and supporting measurements.

8.3 Available Numerical Evidence

The registered Python golden fixture verifies deterministic replay of one 10-millisecond, three-link planar rollout against an exact model/version/input record. Cross-engine parity, spatial contact, time-varying impedance, human model adequacy, causal identification, and physiological validation are unavailable. A future result must add its own conforming intervention record rather than inheriting the fixture’s authority.

9 See Also