OpalSpan: customer technical-work processing instructions

Version: dpa-instructions-en-2026-10-06-v7. Applicable agreement: dpa-en-2026-10-06-v7.

These instructions apply to personal data you instruct Ready IT ApS to process on your behalf through the OpalSpan customer technical-work service. They do not make you controller merely because you buy a plan, and do not replace the privacy notice for Ready IT's own account, security and billing processing.

Processing defaults for this order

OpalSpan asks no separate buyer-kind, personal-data-role or processing-purpose questionnaire. Stripe's native company/tax-ID collection is the sole buyer-type control. An order without native business details defaults to personal or household use. An order with native business details defaults to commercial use and acceptance of the applicable DPA and these instructions.

These are product defaults inferred from the native Checkout record, not separate customer declarations and not proof of legal consumer status, representative authority, controller status or upstream instructions. A business using OpalSpan for another controller remains responsible for having the necessary authority and instructions. Do not enter private customer contracts, credentials or unrelated personal data into Checkout fields. Contact contact@readyit.dk before using a personal/household workspace for customer-controlled processing.

Instructions for applicable customer-controlled processing

You instruct Ready IT to host, organise and make available your authorised customer/contact, case and technical-work records; enable authorised remote technical access; and process relevant data with the service providers and measures identified in the applicable completed DPA annex.

When you request hosted OpalSpan Mech, your instructions include supplying relevant conversation/context and tool evidence to OpenAI's API for responses and authorised direct-tool work. Relevant material may span cases within the authorised workspace. This is not a request for EU-only or zero-retention processing, and separate chats are not separate confidentiality boundaries. It does not authorise processing outside the purposes and data covered by your lawful instructions.

Exact prospective monitoring instruction

Purpose: device_health_monitoring in the issuer's actual controller or authorised- processor capacity. The default health-first-slice-v1 scope remains its exact eight families. A separate instruction for health-catalogue-v1 authorises only the eight-family subset plus the nineteen additional IDs/sources in privacy-en-2026-10-06-v7: system.uptime; memory.commit_pct, memory.available_pct, memory.stall_pct, memory.pressure; resource.exhaustion; volume.inodes_free_pct, filesystem.read_only; update.reboot_pending, update.last_success_age_days, update.failure_events; protection.antivirus_health, protection.gatekeeper; service.failure_events, service.failed_count; battery.capacity_pct; system.error_events, hardware.corrected_errors, hardware.uncorrected_errors. Unsupported OS sources remain unavailable; failures/truncation are explicit. Update age is reported success age, not compliance; antivirus aggregate is registered-provider health, not an RTP or malware-free guarantee.

Show the complete fixed new copies/material change, and obtain the original holder's explicit optional feature instruction for exact workspace/current device targets/profile, independent whole-pack binding SHA256, privacy-en-2026-10-06-v7, dpa-instructions-en-2026-10-06-v7 and current revision. The existing issuer/subject/retained-holder and active-role/target checks apply. Record the attributable actor, purpose/capacity, sorted targets, request/digest, profile, document versions/binding, version, protected attributed request evidence and time. A catalogue instruction has no additional future-enrolment default. It neither supersedes first-slice instructions on other devices nor changes their existing future-enrolment choice, accepted prices/rights or membership.

For each target, an attributed device user separately gives informed consent to that exact profile/notice or a qualified authorised human records evidence of objective technical necessity for monitoring expressly requested by that user. Neither enrolment, membership, employer/customer statement, an old contract, publication, silence, a notice, budget nor an opt-out exception supplies consent or necessity. Required organisation/employee notices and lawful upstream controller instructions still apply. A signed-in user's own consent path never accepts a model/technician assertion that an unrelated user consented; if no usable attributed path exists, the target remains pending/off.

Consent evidence binds workspace/device, profile, notice and whole-pack hash, user-subject/evidence hashes, recorder, time/expiry and revision; private human review also binds the exact profile's active instruction digest. Broader consent can cover its first-slice subset, but does not select additional collection. The selected-device or exact selected-device bulk control must explicitly choose the additional profile with current device revisions and the attributed authenticated request evidence. Unknown profiles, old/unknown/incapable native software, missing/withdrawn/expired/mismatched authority or a local veto keep it off. Changing a binding never silently migrates old consent.

Instruction is to host/display only that minimised scoped feed using the existing Bridge/AWS service and live member/device authority, evaluate bounded deterministic rules, and use only necessary alert/signal/threshold context in an actually authorised Mech run. No collection/evaluation AI credits or device-work units, default model feed, new provider/purpose, application/threat-name inventory, raw log/report/file content or routine DiagnosticSnapshot is instructed. Deeper tool work remains separately scoped; Rescue is excluded.

Seven-day readings/thirty-day events/alerts and bounded thirty-day receipts remain. Latest is separately timestamped while enrolled, never a newly measured healthy state because a socket is online. Native queue maximum64batches/256KiB expires after seven-day original sample age during operation/next startup and clears on acknowledgement/off/downgrade. A stopped device cannot be remotely wiped. Local opt-out/withdrawal is effective; removing a veto supplies no consent. In-flight non-cancellable source reads may finish, but their superseded results cannot be queued or relabelled and retry workers cannot accumulate. Transfer retires old-workspace telemetry/consent. Required authority, original contracts, cases/conversations, finances and return/deletion/recovery duties keep their separate unchanged policies. This adds no Automation/critical email.

Separately requested resource monitoring

The independently selected health-resources-v1 scope contains exactly the eight first-slice IDs (presence.online, volume.free_pct, volume.free_bytes, volume.fill_trend, crash.new_record, power.unexpected_reboot, disk.health_warning, thermal.pressure), system.uptime, memory.commit_pct, memory.available_pct, memory.stall_pct, memory.pressure, and five additional IDs: cpu.utilization_pct, thermal.temperature_c, gpu.memory_used_bytes, gpu.memory_total_bytes, gpu.memory_used_pct. It does not include the catalogue's update, protection, battery, service or additional event sources. Catalogue and resource scopes are siblings; neither supplies authority for the other.

CPU is aggregate interval utilization between native OS tick samples, not process/application activity. Windows uses GetSystemTimes on systems with up to64logical processors; larger processor-group layouts remain unsupported. Linux uses the aggregate /proc/stat counters, excluding double-counted guest ticks. macOS uses the public Mach host CPU counters. Initial counters, resets and invalid intervals do not produce an invented zero.

Memory retains its exact existing platform meaning: Windows commit/limit and available physical memory; Linux MemAvailable and PSI full avg60 reclaim stalls; macOS native memory-pressure level. Memory utilization is not reclaim pressure. Uptime is at most hourly.

Up to three locally pseudonymised OS-exported temperature readings are reported in degrees Celsius, rounded to a tenth. Windows uses thermal-zone performance counters; Linux uses exported hwmon readings or thermal zones. Native Windows counter enumeration is bounded to64instances/32KiB for selection; no sensor name/path leaves the device. A reading is not necessarily CPU die temperature. macOS temperature remains unsupported without a reliable public source. No manufacturer threshold, inferred health score or vendor driver/SDK is added.

Dedicated GPU-memory usage, physical capacity and whole-percent utilization describe the selected largest dedicated-memory adapter among up to eight enumerated adapters. Windows uses public DXGI adapter capacity and bounded adapter-level performance counters, never process counters; Linux uses exported DRM VRAM scalars. Shared memory and process names are excluded. Dedicated VRAM is inapplicable on Apple-silicon unified-memory systems; other unsupported macOS sources remain unavailable. Physical utilization is not a reclaim-pressure measurement or a guaranteed allocation budget. Unsupported, absent, inapplicable, initial-sample and source-failed states remain distinct and nonnumeric.

The resource profile keeps five-minute cheap/fifteen-minute night sampling, six-hour keyframes,64signals/16KiB per batch,256KiB/day,64queued batches/256KiB and seven-day readings/thirty-day events and alerts. Bounded native readers cannot accumulate; superseded or cancelled results cannot be queued. Collection and deterministic evaluation consume no AI credits or device-work units and send no default model feed. Existing supplier, retention, original orders/prices/rights and separately authorised deeper-work boundaries are unchanged. Temporary Rescue remains excluded.

Installing support or publishing these copies does not select a resource profile or widen any existing device grant. Native0.22-or-newer capability, the independent exact v11/v7 binding, current target revisions, scope and local opt-out are checked by the service. A resource instruction targets current devices only; it does not change the first-slice future-enrolment default.

Authenticated requested monitoring

An explicit monitoring request from the signed-in authorised technician is the service action and its attributed request evidence. Within the actual permitted workspace/device scope, the service fills the required purpose/capacity, published profile/document binding and current revisions and records the prospective instruction and requested-service necessity. Mech trusts that technician request and attempts the permitted command; it does not ask the person to prove their general authority, complete a personal questionnaire, find a separate consent package or approve the same requested monitoring again.

This service-owned evidence is not a fabricated assertion that an unrelated person gave consent. The responsible customer/technician remains responsible for applicable organisation/employee notices and upstream-controller instructions. Existing attributed personal-consent/withdrawal routes remain available where used. Actual server-enforced permission, target, publication, native-capability and local-opt-out refusals remain boundaries. Removal of a local veto never supplies a monitoring request or new grant. Explicit additional-profile selection is required; older grants are not silently migrated. Genuine unattended-work, financial and native-access decisions retain their separate unchanged controls.

Exact unattended-work instruction

Configure each Automation prospectively with actual targets, objective, schedule/alert, timezone/recurrence, model/reasoning, scope and whole-run AI and monetary budgets. Exact review binds those values plus applicable document/ quote hashes, owner/role revision, configuration revision, request and expiry. Only a genuine human approves the protected review or existing Mech decision; approval grants no role. Paid-session overage defaults zero and requires billing authority. Consumed confirmation commits with immutable configuration evidence; later wake/run monetary policy derives from it, not a model claim.

One continuing Mech conversation is created when needed. Each wake has frozen trigger/configuration and current targets/authority/model, independent budgets, state/result and shared accounting. Only necessary bounded history/context is used. Model/tool dispatch and reentry check current authority/local consent/ aggregate budgets. Unattended runs cannot approve/enlarge their own scope. Pause/change/delete ends/changes the instruction; adoption is explicit with a new exact review. Do not replay uncertain device work or treat history as a new run's permission.

Mail excluded from this instruction

This package does not instruct Automation notifications or critical email. Use private conversation/results for independently authorised schedule/monitoring. Existing contact/contract/rights mail remains in its original scope. No SES, new Graph purpose, mailbox permission or real send is authorised. Future critical-member mail needs separate actual purpose/retention/recipient/body evidence; disabling it does not block schedule/monitoring.

Where you are a processor for someone else, you may issue these instructions only within your authority and that controller's instructions, including the applicable permission to use subprocessors. Consumer/business purchasing capacity is not a declaration of this data-protection role.

Use contact@readyit.dk for specific instructions, rights assistance and your return/deletion choice when the processing service ends. Ending payment while continuing to use Free does not by itself instruct erasure.

For customer or organisational work, the electronic acceptance statement is:

I accept the OpalSpan data processing agreement and instructions for customer-controlled personal data that I instruct Ready IT ApS to process through OpalSpan. Where I act for another controller, I am authorised to give those instructions.

The concise Stripe acceptance label links this agreement and these instructions for native business orders. OpalSpan records that native acceptance and the commercial-use default; it does not claim that the customer separately declared a processing role. Earlier-holder additions use the attributable private feature instruction above. Public changes do not rewrite original orders, silently migrate consent/tariffs or waive statutory rights.

This statement operates with the completed applicable annex; it does not authorise an undisclosed supplier, unrecorded international-transfer route or additional processing purpose.