Skip to content

Local Context and Privacy

HeimerClean needs to understand the operating condition of a Windows device, not the private meaning of the user's work. The local agent asks a narrow question: is one of the registered maintenance actions useful and safe now, or should the system wait?

That distinction defines the data architecture.

Technical state is not personal content

The decision context can contain CPU and RAM pressure, temporary-data volume, disk and GPU activity, energy-related ratios, recent operation timing, and indicators that a game, render task, or other interactive session is active. These signals describe machine load.

The optimizer does not need to open or semantically analyse:

  • documents or their contents;
  • e-mails, messages, or contact text;
  • photographs or media content;
  • browser-page content or search history;
  • the user's accounting, office, or creative files.

This is why HeimerClean is described as local-first. The live context vector, the safety mask, and the final action decision are produced on the Windows device. A cloud response is not required to decide whether the local agent should wait or apply an allowed action.

What the current code evaluates locally

The present context encoder produces the following technical features:

Feature group Examples
Resource pressure CPU percentage, RAM percentage, GPU percentage
Maintenance state Temporary-data size, recent action timing
Device context CPU capacity ratio, NVIDIA GPU presence
Workload protection Interactive-load score, game-session flag, render-session flag
Derived context RAM and temporary-data interaction

Values are bounded and normalized before they reach the contextual policy. A game or render indicator is a technical state flag; it is not a recording of what the user is playing, creating, reading, or typing.

What can leave the device

When synchronization is enabled and an authenticated connection is available, the current learning pipeline can queue a compact ai_lesson_data_v1 technical record. It contains:

  • selected action and trigger type;
  • policy mode and policy source;
  • bounded reward and outcome score;
  • before values for CPU, RAM, temporary-data size, GPU load, and game-session state;
  • CPU, RAM, and temporary-data deltas;
  • flags showing whether the bandit acted or a shadow recommendation was recorded;
  • compact profile and device tokens used for technical continuity.

The payload does not contain document text, e-mail content, image content, browser-page content, or file contents. After successful synchronization, uploaded learning records are removed from the local upload queue according to the current queue lifecycle.

Anonymity is not claimed

The technical lesson payload uses compact tokens, but authenticated server ingestion can also retain operational account or device metadata for licensing, deduplication, security, and support. It is therefore more accurate to call the record minimized and pseudonymized technical telemetry, not guaranteed anonymous data.

Local and cloud responsibilities

Responsibility Device Cloud service
Read Windows technical state Yes No
Build live context vector Yes No
Apply deterministic safety mask Yes No
Select and execute local action Yes No
Store immediate/delayed outcome locally Yes No
Receive minimized lesson record Queue origin When synchronization succeeds
Aggregate validation evidence Local evidence Supported through ingested technical records

If the network is unavailable, records remain in the local SQLite-backed queue and are retried later. The optimization decision itself remains local; cloud availability does not authorize a blocked action.

Why this boundary matters

Data minimization is a design constraint, not a claim that all technical telemetry is legally non-personal. Article 5 of the General Data Protection Regulation requires personal data to be adequate, relevant, and limited to what is necessary. NIST's Privacy Framework similarly treats privacy risk as something that must be identified and managed throughout system design.

HeimerClean applies those ideas by separating private content from machine-state measurements, minimizing the learning payload, keeping the live decision path on-device, and documenting the remaining operational metadata. Product deployment must still provide the appropriate notice, lawful basis or consent mechanism, retention rules, access controls, and deletion procedures for the relevant jurisdiction.

How to read HeimerClean privacy claims

The precise claim is:

HeimerClean does not read or analyse personal file content to make optimization decisions. The live decision path runs locally. Only limited technical learning and before/after records are eligible for cloud synchronization, together with operational metadata required by the authenticated service.

This is deliberately narrower—and more verifiable—than saying that the application sends "no data" or that every record is anonymous.

References