Learn AI.
Build AI Systems · ORIGINAL LEARN AI LESSON

Stop when the controller leaves its limits.

Inspect runtime rejection, delayed observations and bounded fallback without equating a stopped task with success.

By the end: Separate operating contracts, fallback dynamics, actual violations and task completion from an accumulated reward.

01 · TRY

Start with something concrete.

Removing a cart’s push does not instantly remove its momentum. A controller that stops issuing task commands still needs an explicit fallback behavior.

Try the interactive model ↓
02 · PREDICT
Before you experiment

A missing action triggers a zero-force fallback while the drag-free cart is moving. What happens next?

A missing action triggers a zero-force fallback while the drag-free cart is moving. What happens next?
03 · EXPERIMENT

Change one thing. Watch what follows.

  1. Inspect a normal completion and an oversized-action rejection.
  2. Compare braking with zero-force coasting.
  3. Introduce delayed observations while the cart is already moving.
  4. Reject an outside-region target without awarding success.
  5. Disable runtime checks while retaining the external trajectory evaluator.
  6. Explain why a shorter failed run can have a less negative reward.

Loading this browser experiment…

04 · UNDERSTAND

Give the controller a declared operating region

An action can look useful for a target and still violate a constraint. The lab’s contract declares a position interval, a speed limit, a force limit and a maximum observation age. These are separate from the controller’s objective. An outside-region target is an invalid task for this contract, even if the cart could physically travel there.

The controller proposes; the runtime checks; the actuator applies; the independent evaluator records what happened. Keeping those stages visible makes it possible to diagnose which part failed.

Check the information actually available

The runtime receives only an observed position, observed velocity, observation age, target and proposed force. It checks that the observation is fresh enough, that the observed state and target lie inside the declared limits, and that the action is present and in range. It also predicts one short interval from that observation.

It does not secretly use the simulator’s true current state. Delay begins after the cart has been moving for one second, so the freshness failure happens in a meaningful moving situation. A short-horizon check from an old state is not a proof that the real trajectory will remain inside the region.

The external evaluator has a different role. It uses the true state and applied force to check actual motion. Turning runtime checks off does not change this definition of correctness. An observed violation must remain a violation in every ablation.

Check the interval, not just its endpoints

Constant force gives a quadratic position curve and a linear velocity curve. A cart can leave a position bound, reverse direction and return before the next sample. Checking only the endpoints can miss that excursion.

The evaluator checks endpoints and any interior time where velocity is zero. With acceleration a, that candidate turning time is −v/a, provided a is nonzero and the time lies inside the interval. Speed extremes for this constant-acceleration segment occur at its endpoints. This exact calculation applies to the stated one-dimensional model; it is not a general collision algorithm.

A fallback must obey dynamics too

Once a runtime failure triggers fallback, normal task commands stay disabled for the remainder of the run. The braking fallback uses the available measured velocity to request an opposing force. The coasting alternative requests zero force. Both retain the same actuator limit.

Coasting does not stop a drag-free cart. Braking changes velocity over time, and stale velocity measurements can make that fallback perform poorly. Neither option teleports the state to rest. The fallback is bounded to 75 intervals, or 1.5 seconds, and may end earlier if the evaluator observes a breach.

Ending this window means the simulated scenario is over. It does not establish what a physical cart would do afterward. The report therefore keeps final speed, actual violations and task completion separate. A low final speed after fallback is useful evidence about that response, not successful completion of the original target request.

Do not hide failure behind reward

The illustrative reward accumulates negative distance-to-target over the accepted intervals. A prematurely ended run can accumulate less negative reward simply because it has fewer intervals. That number omits failure penalties and must not decide acceptance alone.

The separate normal-completion rule requires an eight-second run with no fallback or actual violation, plus low position error and velocity over the final half-second. The independent evaluator ends a scenario after recording an actual breach; it never erases the violating interval. Missing actions cannot drive numerical dynamics even in the checks-disabled experiment, so they still trigger fallback.

Audit the stop decision

For guided practice, compare the same oversized-action fault under braking and coasting. Then test delayed sensing and an impossible target. For implementation practice, replay the interval equations and construct a case whose interior turning point crosses a bound despite acceptable endpoints.

For a decision brief, state which observations and assumptions the runtime relies on, what fallback was attempted, and what the true trace establishes. A passing short trace is not a robust invariant or a physical emergency-stop certificate. This lesson controls no hardware; independent implementation review and learner pilots remain pending.

05 · APPLY
Check your understanding

A runtime check passes using an old observation. What may the independent evaluator still find?

A runtime check passes using an old observation. What may the independent evaluator still find?
06 · CONTINUE

Take this idea with you.

Rejecting a proposal, invoking fallback, avoiding a violation and completing a task are different events. Preserve those distinctions in both traces and reports.

My work
Learn AI · Understand by doing.Loading local progress…Copyright (c) 2026 Mobi Weave, Inc. All rights reserved