OpalSpan: customer technical-work processing instructions

Version: dpa-instructions-en-2026-10-08-v8. Applicable agreement: dpa-en-2026-10-08-v8.

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 Telemetry instruction

Purpose remains device_health_monitoring in the issuer's actual controller or authorised-processor capacity. Telemetry, including resource usage, is selected as Disabled, Light or Full. Disabled performs no optional telemetry collection; existing authenticated presence and service-security traffic remain separate. Light (telemetry-light-v1) contains exactly 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 cpu.utilization_pct. Full (telemetry-full-v1) contains these fourteen IDs plus 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, thermal.temperature_c, gpu.memory_used_bytes, gpu.memory_total_bytes and gpu.memory_used_pct. The v8 privacy notice describes the native sources and per-platform limits. Unsupported or failed sources remain unavailable; update age is not compliance, antivirus aggregate is not a malware-free guarantee, temperature is not always CPU die temperature and dedicated GPU usage is not reclaim pressure.

Show the complete fixed new copies and record the authorised original-holder/ controller or upstream-processor's explicit tier instruction for its exact workspace/current devices, independent whole-pack binding, privacy-en-2026-10-08-v8, dpa-instructions-en-2026-10-08-v8 and current revisions. Record actor, capacity, sorted targets, request/digest, tier/profile identity, versions/binding, protected attributed request evidence and time. Existing first-slice/catalogue/ resource instructions and device-user grants retain their historical meanings; none silently authorises this combined scope.

An explicitly selected workspace default may prefer Full for future enrolments. It is a prospective instruction/preference, not fabricated consent, new technical access or evidence that an unknown future user requested monitoring. Each new device still needs current supported advertised capability, covered instruction, applicable attributed user consent or evidenced necessity for the expressly requested service and no local veto. Changing the default does not widen earlier devices or relabel their observations. Apply current-device upgrades separately with exact versions and attributed request evidence; no local opt-out is cleared.

An attributed device user gives required informed tier-specific consent, or a qualified authorised human records evidenced objective necessity for expressly requested telemetry. Enrolment, membership, publication, silence, an old contract, a notice or budget does not supply that evidence. Applicable organisation/ employee notices and upstream-controller instructions remain the responsible party's obligations. The signed-in own-consent path cannot invent another person's consent. Missing, withdrawn, expired or mismatched authority keeps collection pending/off; removing a veto creates no grant.

Consent/evidence binds workspace/device, tier, notice and whole-pack hash, user-subject/evidence hashes, recorder, time/expiry and revision. Full may cover its Light subset but never selects extra collection automatically. Explicit selection and current native0.23-or-newer advertised Light/Full support are required; old/unknown software and unknown profile IDs fail closed.

Instruction is limited to the minimised scoped feed through existing Bridge/AWS, tenant-authorised recording/retrieval/pruning, bounded deterministic evaluation and only necessary context for an independently authorised Mech run. It adds no AI-credit/device-work units, default model feed, provider, application/service/ threat-name inventory, raw log/report/file content, network identity, serial, command/environment capture or routine DiagnosticSnapshot. Temporary Rescue is excluded; deeper technical work remains separately explicit.

Both tiers keep five-minute cheap/fifteen-minute night sampling, hourly/daily slow sources, six-hour keyframes,64signals/16KiB per batch,256KiB/day and 64queued batches/256KiB. Historical readings retain their original measurement time and expire after seven days; events/alerts after thirty days. Latest, authority/comparison metadata, protected cases/contracts and financial/recovery records retain their independent lifetimes. Bounds may suppress or drop excess history; neither instant nor exhaustive monitoring is promised.

Unsent telemetry clears on acknowledgement/off/downgrade and expires by original sample age during operation or next startup. A stopped device cannot be remotely wiped. Superseded non-cancellable reads may finish locally but cannot enter the new queue or accumulate workers. Transfer retires old-workspace telemetry and user authority. No price, statutory right, historical order or invoice changes.

Authenticated requested telemetry

An explicit telemetry 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 telemetry 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 telemetry request or new grant. Explicit Light/Full tier 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.