OpalSpan: customer technical-work processing instructions

Version: dpa-instructions-en-2026-10-05-v6. Applicable agreement: dpa-en-2026-10-05-v6.

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-05-v6: 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-05-v6, dpa-instructions-en-2026-10-05-v6 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 human confirmation 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 separate human confirmation. 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.

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.