What a Worker Must Report Beyond ‘Online’

A worker may answer a ping while loading a model, approaching its RAM limit, running on battery, or being used directly by a person. Those conditions affect long idle work differently from an interactive chat request, so one green online badge cannot justify every assignment. The heartbeat is therefore treated as an eligibility report as well as a liveness signal.

The working rule for “The operating problem” is: A worker may answer a ping while loading a model, approaching its RAM limit, running on battery, or being used directly by a person. Those conditions affect long idle work differently from an interactive chat request, so one green online badge cannot justify every assignment. The heartbeat is therefore treated as an eligibility report as well as a liveness signal. Preserve timestamped state transitions, reason codes, and retry outcomes so that an operational decision can be reconstructed later.

For verification, save the model and runtime versions, source input, relevant settings, and observed output together. Repeat the step while changing only one factor, and record unexpected results and untested limits as carefully as successes before applying the guidance to private or production data.

The example heartbeat contains worker ID, allowed roles, ready models, RAM use, temperature value and state, AC state, idle time, and active job. Receipt time is stored separately as `last_seen` rather than trusting a device-provided timestamp, and claim rejects a report older than the 60-second timeout. The current eligibility path uses role, RAM, temperature state, AC power, and idle time; `models_ready` and `active_job` are stored but not yet gates.

The working rule for “The design decision” is: Unknown resource values are not treated as healthy. Missing RAM defaults to 100%, missing AC to false, and missing idle time to zero, which blocks assignments that depend on those signals. Temperature blocking follows configured states—currently `over_limit` and `sensor_error`—so `sensor_unavailable` must be added to policy or handled by restricting that device's roles when a stricter posture is required. Preserve timestamped state transitions, reason codes, and retry outcomes so that an operational decision can be reconstructed later.

Preserve the before-and-after state and the time of the check so that another run can reproduce the result. Include at least one failure condition—such as empty input, constrained resources, or a restart—to reveal the boundary of the step rather than documenting only the happy path.

Unknown resource values are not treated as healthy. Missing RAM defaults to 100%, missing AC to false, and missing idle time to zero, which blocks assignments that depend on those signals. Temperature blocking follows configured states—currently `over_limit` and `sensor_error`—so `sensor_unavailable` must be added to policy or handled by restricting that device's roles when a stricter posture is required.

The working rule for “How the mechanism works” is: The eligibility helper returns fixed reasons such as `memory_limit`, `thermal_limit`, `ac_power_required`, and `user_active`, but claim currently discards the reason and status does not expose it. OS-specific collectors must still measure memory, temperature, power, and user activity without turning sensor failure into a false zero. Observable refusal reasons, model-readiness gates, active-job reconciliation, and cross-platform collectors remain adapter and dashboard work. Preserve timestamped state transitions, reason codes, and retry outcomes so that an operational decision can be reconstructed later.

Define completion with an observable result instead of a general impression. Repeat the same input, and if the output changes, isolate whether the model, runtime settings, or source data changed before moving to the next stage.

The automated test injects 90% RAM and confirms claim rejection against the 85% starting gate. Code review also confirms rejection after the last heartbeat is more than 60 seconds old, while a healthy-report recovery remains the manual exercise criterion rather than a dedicated test. A complete regression pair should eventually verify both blocking and return to eligibility.

The working rule for “What we verified” is: A worker may answer a ping while loading a model, approaching its RAM limit, running on battery, or being used directly by a person. Those conditions affect long idle work differently from an interactive chat request, so one green online badge cannot justify every assignment. The heartbeat is therefore treated as an eligibility report as well as a liveness signal. Preserve timestamped state transitions, reason codes, and retry outcomes so that an operational decision can be reconstructed later.

For verification, save the model and runtime versions, source input, relevant settings, and observed output together. Repeat the step while changing only one factor, and record unexpected results and untested limits as carefully as successes before applying the guidance to private or production data.

The eligibility helper returns fixed reasons such as `memory_limit`, `thermal_limit`, `ac_power_required`, and `user_active`, but claim currently discards the reason and status does not expose it. OS-specific collectors must still measure memory, temperature, power, and user activity without turning sensor failure into a false zero. Observable refusal reasons, model-readiness gates, active-job reconciliation, and cross-platform collectors remain adapter and dashboard work.

The working rule for “Boundary and completion criteria” is: Unknown resource values are not treated as healthy. Missing RAM defaults to 100%, missing AC to false, and missing idle time to zero, which blocks assignments that depend on those signals. Temperature blocking follows configured states—currently `over_limit` and `sensor_error`—so `sensor_unavailable` must be added to policy or handled by restricting that device's roles when a stricter posture is required. Preserve timestamped state transitions, reason codes, and retry outcomes so that an operational decision can be reconstructed later.

Preserve the before-and-after state and the time of the check so that another run can reproduce the result. Include at least one failure condition—such as empty input, constrained resources, or a restart—to reveal the boundary of the step rather than documenting only the happy path.