Drift Dynamics Model

Why Linear Extrapolation Is Insufficient

The Behavioral Trajectory Engine (v0.7.0) projects drift using linear extrapolation: it computes a velocity from recent observations and extends the line forward. This works for short horizons and steady-state drift, but fails to capture three critical behaviors:

1. Drift acceleration — some agents drift faster the longer they run unchecked, particularly in high-stakes archetypes like security monitors and financial analysts where small deviations compound.

2. Self-correction — many agent configurations naturally oscillate: a customer-experience agent that drifts toward aggressive upselling may self-correct as negative feedback accumulates. Linear projection misses this entirely.

3. Intervention dynamics — when a throttle or tighten action fires, the resulting drift reduction is not instantaneous or permanent. It decays exponentially and eventually rebounds. Linear models cannot represent this.

The Drift Dynamics Model replaces linear extrapolation with parametric models that capture all three behaviors, pre-seeded with archetype-specific defaults and refined as observed data accumulates.

Parametric Model Structure

Each archetype has an ArchetypeDynamics instance containing three components:

Natural Transitions (DriftTransitionParams)

Parameters governing how drift evolves without intervention:

Parameter	Description	Range
continuation_rate	Multiplier on drift velocity (1.0 = constant)	0.0–2.0
acceleration_factor	Per-step acceleration (>0 speeds up, <0 slows)	-0.05–0.05
self_correction_probability	Chance of spontaneous drift reduction per step	0.0–1.0
self_correction_magnitude	Fractional reduction when self-correction fires	0.0–1.0

Intervention Effects (InterventionEffect)

Parameters for each of the four intervention types (advisory, throttle, escalate, tighten):

Parameter	Description	Range
decay_half_life	Steps until drift halves after intervention	1.0–50.0
effectiveness	Probability intervention reduces drift at all	0.0–1.0
rebound_rate	Speed of drift return after intervention wears off	0.0–1.0

Intervention projection works in three phases:

1. Decay phase (steps 1 to decay_half_life × 3): exponential decay of drift.

2. Rebound phase (after decay_half_life × 3): drift gradually returns at rebound_rate.

3. Failed intervention (with probability 1 - effectiveness): natural trajectory continues unchanged.

Causal Modifiers (dict[str, DriftTransitionParams])

Different drift causes produce different dynamics. A model_update cause tends to produce persistent, accelerating drift. A config_change cause often self-corrects as the system stabilizes. Five cause types are modeled:

• config_change — tends to self-correct quickly

• model_update — accelerates, low self-correction

• workload_shift — moderate, stable

• semantic_reframing — gradual acceleration

• organic — baseline natural drift

Model Maturity Levels

The model evolves through three maturity stages based on the number of observed drift episodes:

Level	Episodes	Behavior
default	< 50	Uses pre-seeded parametric defaults only
blended	50–200	Exponential moving average blends observations with defaults
observed	200+	Observed data dominates (blend weight approaches 1.0)

The blend weight formula is: blend = min(1.0, (episodes - 50) / 150.0)

At 50 episodes the blend weight is 0.0 (pure defaults). At 200 episodes it reaches 1.0 (pure observations). This ensures the model degrades gracefully when data is sparse while converging to empirical behavior as evidence accumulates.

Pre-Seeded Archetype Defaults

Archetype	Continuation Rate	Acceleration	Self-Correction Prob	Advisory Eff	Tighten Eff
financial-analyst	1.10	0.010	0.10	0.40	0.90
customer-experience	0.90	0.000	0.30	0.70	0.90
security-monitor	1.15	0.020	0.05	0.80	0.98
sales-agent	1.00	0.005	0.25	0.55	0.92
operations-coordinator	0.95	0.000	0.20	0.60	0.90
data-processor	1.05	0.005	0.15	0.45	0.92
content-creator	0.85	-0.005	0.35	0.65	0.88
research-analyst	0.90	0.000	0.30	0.60	0.90
executive-assistant	0.95	0.000	0.20	0.60	0.93
healthcare-agent	1.10	0.010	0.08	0.70	0.98

Key observations:

• High-stakes archetypes (security-monitor, healthcare-agent, financial-analyst) have low self-correction and high intervention effectiveness — they need governance to stay aligned.

• Self-correcting archetypes (content-creator, customer-experience, research-analyst) have higher self-correction probability and lower continuation rates — they naturally oscillate back.

• Advisory effectiveness varies widely — customer-experience agents respond well to advisory (0.70), while data-processors largely ignore it (0.45).

Inspecting and Overriding Parameters

Operators can inspect and override dynamics parameters programmatically:

from nomotic.drift_dynamics import DriftDynamicsModel

model = DriftDynamicsModel()

# Inspect current dynamics for an archetype
dynamics = model.get_dynamics("financial-analyst")
print(dynamics.natural_transition.self_correction_probability)  # 0.1
print(dynamics.intervention_effects["advisory"].effectiveness)  # 0.4

# Override parameters
dynamics.natural_transition.self_correction_probability = 0.2
dynamics.intervention_effects["advisory"].effectiveness = 0.6

# Project drift under different scenarios
baseline = model.project_drift(0.3, 0.02, horizon=20, archetype="financial-analyst")
with_throttle = model.project_drift(0.3, 0.02, horizon=20, archetype="financial-analyst", intervention="throttle")

# Check model maturity
print(model.maturity("financial-analyst"))  # "default", "blended", or "observed"

# Serialize for persistence
data = dynamics.to_dict()
restored = ArchetypeDynamics.from_dict(data)

The DriftDynamicsModel is thread-safe and can be shared across the control plane. It integrates with the Monte Carlo optimizer to evaluate intervention strategies across projected futures.

Integration with Policy Optimizer

The DriftDynamicsModel serves as the core simulation engine for the Monte Carlo Policy Optimizer (PolicyOptimizer). During optimization, the optimizer calls project_drift() hundreds of times per strategy evaluation — once per Monte Carlo rollout — using different intervention types and random seeds to build a distribution of outcomes.

How the Optimizer Uses project_drift()

1. Natural trajectory rollouts: For the no_op strategy, the optimizer projects drift forward without intervention to estimate violation costs if the system takes no action.

2. Intervention rollouts: For strategies that include interventions (advisory, throttle, escalate), the optimizer calls project_drift() with the intervention parameter set. The dynamics model's intervention effects — decay, effectiveness probability, and rebound — determine how much each intervention reduces drift and for how long.

3. Per-rollout randomness: Each rollout uses a fresh random.Random() instance, so the dynamics model's stochastic elements (self-correction probability, intervention effectiveness roll) produce different outcomes per rollout. The optimizer aggregates these into mean cost and variance estimates.

4. Archetype-specific dynamics: The optimizer passes the agent's archetype through to project_drift(), so all archetype-specific parameters (continuation rate, acceleration, self-correction, intervention effectiveness) are automatically applied. This means the optimizer's strategy selection is already archetype-aware without additional configuration.

Example: Optimizer → Dynamics Model Flow

from nomotic.drift_dynamics import DriftDynamicsModel
from nomotic.policy_optimizer import PolicyOptimizer, OptimizerConfig

dynamics = DriftDynamicsModel()
optimizer = PolicyOptimizer(
    config=OptimizerConfig(n_rollouts=200),
    dynamics_model=dynamics,
)

# The optimizer internally calls dynamics.project_drift() like:
# For "graduated" strategy with advisory at step 0:
#   projected = dynamics.project_drift(
#       current_drift=0.20, velocity=0.01, horizon=100,
#       archetype="financial-analyst", intervention="advisory",
#       cause_type="organic", _rng=random.Random(),
#   )
# Then at step 25, projects again with intervention="throttle", etc.

Model Maturity and Optimizer Quality

As the dynamics model accumulates episodes and transitions from default → blended → observed maturity, the optimizer's strategy selections become more accurate. Early in an agent's lifecycle (< 50 episodes), the optimizer relies on archetype defaults. After 200+ episodes, the optimizer benefits from empirically-tuned parameters, producing intervention policies that are calibrated to the specific agent's drift dynamics.

See Sequential Governance Optimization for the full optimizer architecture.