Skip to content

Outcome Verification and Policy Lifecycle

An optimization command completing successfully does not prove that the computer improved. HeimerClean separates execution, immediate measurement, delayed verification, model learning, and rollout authority so those claims can be evaluated independently.

Immediate before/after measurement

Each optimization cycle takes a technical snapshot before and after the selected action. The current outcome function evaluates:

  • change in CPU usage;
  • change in RAM usage;
  • change in temporary-data volume;
  • action type and workload context.

Positive deltas mean that the measured value fell after the action. Each delta is bounded before it contributes to the reward. In the current implementation, CPU and RAM changes each carry 40% of the base reward and temporary-data change carries 20%:

base reward = 0.40 × CPU delta
            + 0.40 × RAM delta
            + 0.20 × temporary-data delta

The result is also transformed into a bounded outcome_score between 0 and 1. none can receive a small positive adjustment when avoiding work protects an active game or high-GPU session; unnecessary inactivity can receive a penalty. qos_only can receive a small contextual adjustment when it responds to CPU pressure during an interactive workload.

These weights are current implementation parameters, not independent scientific findings. They must be calibrated against controlled measurements and user outcomes.

Why delayed verification exists

An optimization action can temporarily consume CPU or memory while it runs. Measuring only at completion can therefore reward or punish the operation for its own short-lived overhead. HeimerClean stores the first result as pending and schedules another system snapshot after a configured delay.

The delayed record stores:

  • verification state and due time;
  • delayed technical snapshot;
  • recalculated final reward;
  • recalculated final outcome score;
  • completion or failure state.

This lets reporting and verified-model training distinguish immediate change from a result that remained observable after the action ended.

Local evidence store

Outcome evidence is stored in a local SQLite table with the profile key, device key, action, trigger, before/after JSON, decision metadata, immediate reward, final reward, verification state, policy mode, and reward-version identifier. This makes policy changes auditable across software versions.

The cloud learning payload is smaller. It contains compact technical fields and deltas rather than the full local record. See Local Context and Privacy for the exact boundary.

Two learning paths

HeimerClean uses outcome evidence in two different ways.

Contextual-bandit evidence

LinUCB can update its local action evidence from the immediate bounded reward. Its role is to rank a small, safety-approved action set under uncertainty. The action mask remains authoritative, so learning cannot make a blocked action available.

Random Forest training

The Random Forest classifier is trained only from outcome rows whose delayed verification state is complete. The current preprocessing:

  • uses memory and temporary-data actions as the two classifier labels;
  • excludes none, qos_only, and unknown actions from classifier labels;
  • excludes sufficiently negative outcomes;
  • requires a minimum number of rows;
  • requires both classes and a minimum sample count per class;
  • records model version, feature schema, training-row count, class distribution, and artifact hash.

The classifier pipeline standardizes the feature input and fits 50 decision trees with a fixed random seed for reproducibility.

Policy modes

Mode Final authority
Deterministic baseline Rules select the action
Shadow Model recommendation is recorded; safe baseline remains authoritative
Model live Random Forest can resolve delegated memory/temporary-data choices
Bandit live LinUCB can select only from the deterministic safety mask and only when rollout controls allow it

The default and available modes are configuration-controlled. A recorded recommendation is not evidence that the model controlled the final action.

Promotion, rollout, and failure response

The bandit promotion gate checks sample count, average reward, success rate, negative-result rate, and comparison with deterministic or Random Forest baseline rows. The rollout controller uses three deterministic device buckets:

  • pilot: approximately 10% eligibility;
  • wave1: approximately 40% eligibility;
  • wave2: full eligibility.

Promotion requires repeated passing evaluations and minimum dwell time. Repeated gate failures move the policy toward a narrower ring. A longer failure streak can arm the kill switch and stop bandit-live application.

Current evidence boundary

Immediate bandit updates and rollout-gate calculations currently use the recorded immediate reward fields. Delayed final rewards are retained separately and are already required by the Random Forest training path, but full delayed-score use in every promotion decision remains part of the expanding validation work. HeimerClean therefore does not claim proven live-learning superiority.

Independent validation

HeimerClean's internal records support reproducibility, but external performance claims should be checked under the same device and workload. Microsoft Windows Performance Recorder can capture Event Tracing for Windows data, and Windows Performance Analyzer can inspect the resulting traces. Appropriate comparisons include startup or task duration, idle CPU and RAM, intervention time, error rate, repeatability, and whether the measured benefit persists.

The evidence rule is simple:

An action, a recommendation, and a demonstrated benefit are three different facts.

References