ion, steering limits, and road geometry.

interface VehicleState {
  velocity: number;
  acceleration: number;
  yawRate: number;
  lateralOffset: number;
}

interface RoadContext {
  curvature: number;
  frictionCoefficient: number;
  laneWidth: number;
}

class PhysicalFeasibilityEvaluator {
  private readonly MAX_LATERAL_ACCEL = 0.85; // g-force limit
  private readonly STEERING_RATE_LIMIT = 4.2; // rad/s

  evaluateFeasibility(
    proposedState: VehicleState,
    context: RoadContext
  ): number {
    const lateralAccel = proposedState.velocity * proposedState.yawRate;
    const frictionLimit = context.frictionCoefficient * 9.81;
    const curvatureLimit = Math.sqrt(frictionLimit / Math.max(context.curvature, 0.001));
    
    const accelRatio = Math.abs(lateralAccel) / Math.min(frictionLimit, curvatureLimit);
    const steeringRatio = Math.abs(proposedState.yawRate) / this.STEERING_RATE_LIMIT;
    const laneViolation = Math.abs(proposedState.lateralOffset) / (context.laneWidth / 2);
    
    // Returns 0.0 (infeasible) to 1.0 (fully feasible)
    return Math.max(0, 1 - Math.max(accelRatio, steeringRatio, laneViolation));
  }
}

2. Online Risk Predictor

Instead of relying on static collision rules, we train a lightweight predictor that estimates the probability of the ego vehicle failing to maintain safe separation. This predictor runs online and updates as the scenario evolves.

interface RiskFeatures {
  timeToCollision: number;
  relativeVelocity: number;
  perceptionLatencyMs: number;
  plannerConfidence: number;
}

class CollisionRiskEstimator {
  private weights: Float32Array;
  private bias: number;

  constructor() {
    this.weights = new Float32Array([0.4, 0.3, 0.2, 0.1]);
    this.bias = 0.05;
  }

  updateOnline(features: RiskFeatures, outcome: number): void {
    const input = new Float32Array([
      1 / Math.max(features.timeToCollision, 0.1),
      Math.abs(features.relativeVelocity),
      features.perceptionLatencyMs / 100,
      1 - features.plannerConfidence
    ]);

    const prediction = this.sigmoid(this.dot(input, this.weights) + this.bias);
    const error = outcome - prediction;
    
    // Lightweight gradient step for online adaptation
    for (let i = 0; i < this.weights.length; i++) {
      this.weights[i] += 0.01 * error * input[i];
    }
    this.bias += 0.01 * error;
  }

  predictRisk(features: RiskFeatures): number {
    const input = new Float32Array([
      1 / Math.max(features.timeToCollision, 0.1),
      Math.abs(features.relativeVelocity),
      features.perceptionLatencyMs / 100,
      1 - features.plannerConfidence
    ]);
    return this.sigmoid(this.dot(input, this.weights) + this.bias);
  }

  private sigmoid(x: number): number { return 1 / (1 + Math.exp(-x)); }
  private dot(a: Float32Array, b: Float32Array): number {
    let sum = 0;
    for (let i = 0; i < a.length; i++) sum += a[i] * b[i];
    return sum;
  }
}

3. Step-Level Feasibility-Aware Shielding

The shielding mechanism intercepts RL action proposals and projects them onto the feasible manifold before execution. This prevents the agent from exploring physically impossible regions while preserving gradient flow for learning.

interface RLAction {
  steering: number;
  throttle: number;
  brake: number;
}

class FeasibilityShield {
  constructor(
    private evaluator: PhysicalFeasibilityEvaluator,
    private threshold: number = 0.15
  ) {}

  shieldAction(
    proposedAction: RLAction,
    currentState: VehicleState,
    context: RoadContext
  ): RLAction {
    let safeAction = { ...proposedAction };
    let feasibility = this.evaluator.evaluateFeasibility(currentState, context);
    
    // Iterative projection if infeasible
    let iterations = 0;
    while (feasibility < this.threshold && iterations < 5) {
      safeAction.steering *= 0.8;
      safeAction.throttle *= 0.9;
      safeAction.brake = Math.min(safeAction.brake, 0.6);
      
      const simulatedState = this.simulateStep(currentState, safeAction);
      feasibility = this.evaluator.evaluateFeasibility(simulatedState, context);
      iterations++;
    }
    
    return safeAction;
  }

  private simulateStep(state: VehicleState, action: RLAction): VehicleState {
    return {
      velocity: state.velocity + (action.throttle - action.brake) * 0.1,
      acceleration: action.throttle - action.brake,
      yawRate: action.steering * 2.5,
      lateralOffset: state.lateralOffset + state.velocity * Math.sin(action.steering) * 0.1
    };
  }
}

4. Constrained Multi-Objective RL Loop

The final orchestrator combines the risk predictor and feasibility shield into a single training step. The reward function balances collision proximity against physical validity, using a penalty term for constraint violations.

class BoundaryScenarioGenerator {
  constructor(
    private riskEstimator: CollisionRiskEstimator,
    private shield: FeasibilityShield,
    private feasibilityEvaluator: PhysicalFeasibilityEvaluator
  ) {}

  async generateStep(
    state: VehicleState,
    context: RoadContext,
    rawAction: RLAction
  ): Promise<{ action: RLAction; reward: number; done: boolean }> {
    const safeAction = this.shield.shieldAction(rawAction, state, context);
    const feasibility = this.feasibilityEvaluator.evaluateFeasibility(state, context);
    
    const riskFeatures: RiskFeatures = {
      timeToCollision: 2.5,
      relativeVelocity: 15.0,
      perceptionLatencyMs: 120,
      plannerConfidence: 0.75
    };
    
    const riskScore = this.riskEstimator.predictRisk(riskFeatures);
    const feasibilityPenalty = feasibility < 0.3 ? -2.0 : 0.0;
    
    // Multi-objective reward: maximize risk, penalize infeasibility
    const reward = (riskScore * 1.5) + feasibilityPenalty;
    const done = riskScore > 0.85 || feasibility < 0.05;
    
    return { action: safeAction, reward, done };
  }
}

Architecture Rationale:

• Why constrained RL? Pure RL diverges into physically impossible trajectories when optimizing solely for collision. Constraints keep exploration in the valid manifold.
• Why step-level shielding? Hard clamping breaks gradient flow. Soft projection preserves learning signals while enforcing safety.
• Why online risk prediction? Static collision thresholds don't capture perception latency or planner uncertainty. Online adaptation matches real-world system behavior.
• Why RSS-derived scoring? RSS provides a mathematically rigorous baseline for safe distances that scales with velocity and road curvature, making it ideal for dynamic feasibility evaluation.

Pitfall Guide

1. Unconstrained Action Sampling

Explanation: Allowing the RL agent to sample actions from a uniform distribution without dynamic limits generates trajectories that exceed tire friction or steering geometry. These scenarios trigger failures but are physically impossible, wasting validation compute. Fix: Implement action space clipping based on real-time vehicle dynamics. Use velocity-dependent steering limits and friction ellipse constraints before the action reaches the simulator.

2. Ignoring Perception and Planning Latency

Explanation: Scenarios that assume instantaneous reaction times create artificial failures. Real autonomy stacks operate with 100-200ms sensor-to-actuator delays. Ignoring this gap produces edge cases that never manifest in production. Fix: Inject realistic latency buffers into the state observation pipeline. Model sensor noise, frame drops, and planner computation time as stochastic delays rather than deterministic values.

3. Static Feasibility Thresholds

Explanation: Using fixed thresholds for physical feasibility fails to account for road context. A maneuver that's feasible on dry asphalt becomes impossible on wet cobblestone. Static thresholds cause false positives in scenario validation. Fix: Scale feasibility bounds dynamically using road friction estimates, curvature, and weather conditions. Implement context-aware RSS scaling that adjusts safe distance margins based on surface conditions.

4. Reward Hacking and Loophole Exploitation

Explanation: RL agents will optimize for the reward function, not the intended behavior. If the reward only penalizes collisions, the agent may learn to trigger emergency stops or exploit simulator artifacts rather than generating meaningful stress tests. Fix: Use multi-objective reward shaping with explicit penalties for non-physical behaviors. Add regularization terms for trajectory smoothness, traffic law compliance, and interaction realism.

5. Controller-Dependent Boundary Definition

Explanation: Tying feasibility boundaries to a specific planner's capabilities makes the scenario generator brittle. When the planner updates, the entire test suite becomes invalid or overly conservative. Fix: Decouple feasibility evaluation from the ego controller. Base boundaries on vehicle dynamics and road physics, not planner-specific constraints. This ensures scenarios remain valid across architecture updates.

6. Single-Agent Adversarial Focus

Explanation: Generating scenarios with only one adversarial agent ignores the complex multi-agent interactions that cause real-world failures. Traffic flow, pedestrian crossings, and cooperative maneuvers require multi-agent coordination. Fix: Implement cooperative-competitive multi-agent RL with traffic flow constraints. Use population-based training to maintain diversity in adversarial behaviors while preserving realistic traffic density.

7. Neglecting Scenario Replayability

Explanation: Stochastic RL training produces non-deterministic scenarios that cannot be reliably replayed for regression testing. Engineers cannot verify if a fix actually resolves the edge case. Fix: Seed the environment deterministically and log full state trajectories. Implement scenario serialization with exact initial conditions, random seeds, and action logs for deterministic replay.

Production Bundle

Action Checklist

• Initialize environment with vehicle dynamics model and road context parser
• Deploy RSS-derived feasibility evaluator with context-aware scaling
• Train online risk predictor on historical near-miss data before RL loop
• Implement step-level shielding with iterative projection fallback
• Configure multi-objective reward with feasibility penalty and smoothness regularization
• Run population-based training to maintain scenario diversity
• Serialize validated scenarios with deterministic seeds for regression testing
• Integrate adversarial fine-tuning pipeline to update planner weights

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Early prototype validation	Unconstrained adversarial	Fast iteration, identifies obvious planner gaps	Low compute, high false positive rate
Production regression testing	Boundary-driven constrained RL	Physically valid, transferable across planner versions	Medium compute, high signal-to-noise ratio
Safety certification audits	Isolated feasibility enforcement	Strict compliance with regulatory physical limits	Low scenario diversity, high validation cost
Multi-agent traffic simulation	Cooperative-competitive RL	Captures emergent failures from traffic flow	High compute, requires distributed training

Configuration Template

scenario_generator:
  framework: "boundary_driven_rl"
  seed: 42
  max_steps: 500
  
  feasibility:
    method: "rss_derived"
    friction_model: "dynamic"
    threshold: 0.15
    projection_iterations: 5
    
  risk_predictor:
    learning_rate: 0.01
    features: ["ttc", "rel_vel", "latency", "confidence"]
    update_frequency: "step"
    
  reward:
    risk_weight: 1.5
    feasibility_penalty: -2.0
    smoothness_weight: 0.3
    collision_threshold: 0.85
    
  shielding:
    enabled: true
    action_clipping: "velocity_dependent"
    fallback_strategy: "iterative_projection"
    
  output:
    serialize_trajectories: true
    deterministic_replay: true
    log_format: "parquet"

Quick Start Guide

1. Initialize the Simulation Environment: Load your vehicle dynamics model and road network. Configure the feasibility evaluator with baseline friction coefficients and lane geometry. Set the random seed for deterministic execution.
2. Deploy the Risk Predictor: Initialize the online risk estimator with pre-trained weights from historical near-miss data. Connect it to the perception latency simulator and planner confidence monitor.
3. Run the Constrained RL Loop: Execute the boundary scenario generator for 500-1000 steps per episode. Monitor the feasibility score and risk prediction in real-time. The shielding mechanism will automatically project infeasible actions.
4. Validate and Export: After training, replay generated scenarios deterministically. Export trajectories to Parquet format for integration into your regression testing pipeline. Use the output to fine-tune the autonomy stack and measure downstream crash rate reduction.