Learn

Learning preferences

Make learning more comfortable. Changes apply immediately.

Enlarges page content, including diagrams and their labels. You can also use your browser’s zoom.

Choose the colours that are easiest for you to distinguish. Applies to lesson diagrams and lab plots. Labels, shapes, hatching and line patterns also distinguish meanings. Source photographs and raw image brightness stay unchanged; mask-only views are available for image overlays.

ExampleComparisonSample link

Saved in this browser on this device. Preferences are separate from progress backups.

Lesson 12 of 21 in this unit

Build AI Systems · ORIGINAL LEARN AI LESSON

Enforce operating limits.

Keep learned proposals separate from action checks, watchdogs, collision prevention and latched braking.

By the end: Demonstrate independent runtime rejection and stopping without confusing constraint handling with successful task completion.

Start with the exampleJump to the experimentRead the explanation
Prerequisites and path options

Why learn this? Separate a proposed action from the runtime checks that determine whether it may be executed.

01 · TRY

Start with something concrete.

A learned controller can propose useful actions without owning the right to execute every one. A separate runtime can reject a command, request braking and retain the failure evidence.

Try the interactive model
02 · PREDICT
Before you experiment

A runtime stops a cart before a wall that blocks its target. Which outcome should it report?

A runtime stops a cart before a wall that blocks its target. Which outcome should it report?
03 · EXPERIMENT

Change one thing. Watch what follows.

Loading this browser experiment…

04 · UNDERSTAND
READ & CONNECT

Understand what changed.

Back to the experiment

A shorter explanation, with the original worked examples available below. Both explain the same experiment and its limits.

Same learning goal in both modes: Demonstrate independent runtime rejection and stopping without confusing constraint handling with successful task completion.

The idea in everyday terms

A learned policy can propose an action but should not grant itself authority to bypass operating limits. Runtime checks sit between the frozen policy and the simulated actuator. A stop state must be handled by the declared rules.

What to watch in the experiment

Compare proposed and applied forces under the same constraints. Inspect stale observations, limit violations and fallback behavior using the independent outcome trace. Keep reaching the goal separate from respecting the operating contract.

What this does not establish

Sampled simulation checks are not continuous physical safety guarantees. A successful bounded run and an exported capture do not establish deployment readiness or independently reviewed control implementation.

Open the full worked examples, calculations and limitations

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

Put execution authority outside the policy

A learned controller maps observations to proposed actions. That capability does not make it the right component to authorize every action or clear a stop signal. This lesson places explicit checks between a frozen learned force policy and the simulated cart.

The policy is the previous continuous-action lesson’s 17-parameter network, trained from its declared seed and imitation grid for 500 updates. The checkpoint is supplied locally and its recipe is tested for reproducibility. This lesson performs no training. A reproducible checkpoint is software evidence, not a claim that a learner independently implemented or reviewed the controller.

Check what happens after a command

Limiting force alone does not prevent collision. A cart moving toward a wall may need space to brake even if the next force is within range. The runtime therefore predicts one commanded interval and then the stopping position under the maximum available opposing force.

For a 1 kg cart and 4 N braking force, deceleration magnitude is 4 m/s². Stopping distance is speed squared divided by twice that deceleration. At 1 m/s this is 0.125 m. The commanded interval occurs before braking, so its movement must also be included.

The wall is at 0.75 m and the cart radius is 0.05 m. The cart centre must stay below 0.7 m to avoid contact. The runtime uses a small additional reserve. It also checks the position region, speed limit and proposal force range. These checks assume exact current state, the declared dynamics and a working actuator; they are not robust guarantees for uncertain physical machinery.

Give watchdogs explicit meanings

A heartbeat reports whether commands are arriving recently enough. The injected stale-heartbeat fault reports command age 0.2 seconds, exceeding the 0.1-second limit. This differs from stale sensing: observations remain exact and current in this lesson.

The progress watchdog records the best target error seen so far. A reduction of at least 0.001 m resets its counter. Fifty samples without that reduction trigger a stop while target error remains above 0.02 m. This operational rule can reject slow progress. Its threshold is an explicit design choice, not a learned judgment or universal definition of success.

Heartbeat and progress checks can be ablated for comparison. Their diagnostics remain visible. The emergency signal always latches a stop even when the other checks are disabled.

Make the stop physically explicit

A latched stop overrides future policy proposals. The ideal brake applies force opposite the current velocity. Velocity changes over time under that force; it is not set to zero at the moment the signal arrives.

If the calculated zero-speed crossing occurs within a sample, the brake acts only until that crossing. The rest of the interval uses zero force and zero velocity. This is a small hybrid model: one interval can contain both braking and resting. The receipt exposes both durations so the state change can be independently replayed.

The model omits actuator delay, brake failure, external disturbance, slope and uncertainty. It does not implement a physical emergency-stop circuit or establish hardware safety. It teaches how to make the assumed response and its limitations visible.

Keep an external evaluator unchanged

The evaluator checks the actual force interval, including any interior position turning point. Turning the runtime guard off does not redefine collision or remove the violating receipt. The scenario ends after recording an actual violation.

This makes ablations meaningful. With the wall enabled, the guard can stop the cart before contact; without it, the learned controller can reach the collision boundary. An actuator clamp still limits the force in both cases. Different mechanisms should not be conflated: a clamp, a watchdog, a predictive collision check and an emergency signal each enforce a different condition.

Preserve the unfinished task

The target is at 1 m. A wall in between makes that target unreachable in the one-dimensional world. A successful brake response therefore leaves the target task incomplete.

Normal completion requires an uninterrupted eight-second run and a final half-second close to both the target position and zero velocity. A stopped run never receives that success label. Similarly, a no-progress stop can enforce the operating contract while revealing that the controller achieved nothing.

Audit the chain of authority

Guided learners should compare nominal motion, wall braking and the same scenario with its guard disabled. Implementation learners should independently replay each receipt and verify that later valid proposals cannot release a latched stop. Decision learners should record assumptions behind stopping distance and distinguish rejected commands, actual violations, stop response and task completion.

These bounded experiments prepare the cumulative simulated-controller project. Temporary captures are practice; human review and learner pilots remain pending.

Continue with Project 11: A verified simulated controller to save matched evidence, write your report and attempt separate transfer cases.

05 · APPLY
Check your understanding

Why must an emergency stop remain outside the learned policy?

Why must an emergency stop remain outside the learned policy?
06 · CONTINUE

Take this idea with you.

Keep proposal quality, execution permission, braking behavior, actual violations and task completion as separate evidence.

My Learning
Explore related topics and the topic map

How this topic connects

Explore this topic on the interactive map

Use these connections to review a foundation or choose where to go next. You can open any topic without completing the others.

What it builds on

You are hereEnforce operating limits

Keep learned proposals separate from action checks, watchdogs, collision prevention and latched braking.

What it enables

  • Controller project Apply in a project

    Use runtime checks and stop traces as evidence in the controller project, keeping simulated enforcement separate from physical safety claims.