Skip to content

Safe Action Selection

An autonomous system agent should not treat every technically possible action as an acceptable action. HeimerClean therefore separates selection intelligence from execution authority. Models can rank choices, but a deterministic guard decides which choices exist in the first place.

The registered action boundary

The current action registry is intentionally small:

Registered action What it means Default risk cost
none Do nothing and wait for the next cycle 0.02
qos_only Apply bounded process-priority stabilization 0.08
temp_clear Run the registered temporary-data maintenance path 0.15
ram_clear Run the registered memory-pressure routine 0.20

These values are policy inputs, not universal safety scores. They let the contextual policy prefer a less disruptive option when expected benefits are close. A name outside the registry is rejected instead of being executed.

The deterministic action mask

Before Random Forest or LinUCB can influence a decision, GuardConstrainedActionMask evaluates the current technical state. The mask follows four principles:

  1. No action is always allowed. Waiting is a valid decision, not a failure.
  2. Cleanup needs evidence. Memory and temporary-data actions require their relevant resource pressure or a sufficiently high CPU-pressure condition.
  3. Interactive work is protected. A game, render task, high foreground-load score, or high GPU load removes cleanup actions from the available set.
  4. Unknown actions fail closed. Anything not explicitly recognised is marked unavailable.

The learning policy receives the mask after these rules run. It cannot override a false value.

Three real-world paths

Gaming or rendering

When the device shows a game or render session, the mask blocks temp_clear and ram_clear. If CPU or interactive pressure justifies it, qos_only may remain available; otherwise the final result is none. The agent avoids beginning disruptive maintenance simply because temporary data exists.

Office workload

During ordinary office work, cleanup remains unavailable until the measured pressure supports it. If memory pressure is high and interactive pressure is low, ram_clear may enter the safe set. If temporary-data or CPU pressure is sufficient, temp_clear may enter the safe set. The policy then ranks only those permitted actions.

Healthy device

If CPU, RAM, and temporary-data conditions do not justify maintenance, the deterministic baseline returns none. The system does not need to perform an action merely to show activity.

How the final choice is constrained

For each permitted action, LinUCB estimates a mean reward and an uncertainty value. The implementation adds an exploration allowance, subtracts the configured risk penalty, and selects the highest remaining score. Cleanup actions also have minimum-support requirements. When evidence for temp_clear or ram_clear is still thin, the manager can replace the recommendation with a close-scoring none or qos_only alternative.

This creates multiple safety layers:

  • explicit action registry;
  • deterministic action mask;
  • action-specific risk cost;
  • minimum evidence support for cleanup;
  • safe fallback margin;
  • single-run locking;
  • cooldown and scheduling controls;
  • shadow mode;
  • rollout rings and policy kill switch.

Explainable decision records

A decision record can show the initial rule decision, the final action, policy source, model confidence, bandit recommendation, allowed-action mask, fallback reason, and whether the learning policy actually controlled execution. This prevents three different events from being confused:

  1. a model recommended an action;
  2. the safety system allowed and executed it;
  3. the action produced a measurable benefit.

Only the third statement requires outcome evidence. See Outcome Verification and Policy Lifecycle.

What rollback means

The current rollout controller can move the learning policy from a wider rollout ring back to a narrower ring, and repeated failures can arm the policy kill switch. This stops or restricts the learning path.

Policy rollback must not be confused with restoring every operating-system change. For example, deleting an approved temporary file is not presented as a reversible file-restore operation. Safety is achieved by limiting action scope, blocking unsuitable timing, failing closed, and retaining the deterministic baseline—not by claiming that every maintenance effect can be undone.

Relationship to Windows and AI safety guidance

Windows process scheduling already defines priority classes and thread priority behaviour. HeimerClean's qos_only action works within that operating-system mechanism. The broader design also follows the risk-management principle that an AI-enabled system should be able to fail safely when it operates near or beyond its knowledge limits. NIST's AI Risk Management Framework identifies validity, safety, security, resilience, accountability, transparency, and explainability as important trustworthiness characteristics.

References