Data Handling Statement

Before work begins

The order must identify the purpose, input and output categories, rights to use the inputs, who may access them, delivery format, provider/processing locations, retention and return/deletion arrangements, and any confidentiality requirements. Begin with the smallest useful, rights-cleared dataset. Remove names, personal data and secrets unless they are necessary and explicitly covered.

Where Sunnyday acts as a processor of personal data, a separate data-processing agreement must cover documented instructions, confidentiality, safeguards, approved subprocessors, rights-request and incident assistance, return/deletion and appropriate audit information, including any required international-transfer mechanism. This statement alone is not an Article 28 agreement or a claim of universal privacy compliance.

We may decline data or a scope whose rights, sensitivity, export controls, privacy conditions or intended use cannot be resolved. Do not submit credentials, payment instruments, regulated personal data or controlled technical data through ordinary email, public pages, an agent manifest or blockchain metadata.

Use and access

We use customer material to perform the accepted scope, resolve delivery/support issues and meet relevant obligations. Access is limited to authorized people and approved providers who need it, with appropriate confidentiality and security conditions. We do not promise a particular cloud region, exclusively local processing or zero retention unless that arrangement is specifically agreed and verified.

No general model training, public benchmarking, case-study publication, marketing reuse or unrestricted data contribution is authorized by a normal order. Separate, specific permission is required. Customer identities and sensitive project details should not be embedded in public trace identifiers or provenance records. A hash can still be linkable and is not automatically anonymous.

Evidence and delivery

We distinguish customer-supplied measurements, public source records, synthetic examples, modeled estimates and analyst judgments. A delivery should identify relevant source and product versions, assumptions, missing data, uncertainty and limitations within its scope. A trace receipt records provenance or computation; it does not certify the truth of an input or validate a physical outcome.

Preserve the delivered files and the policy/order versions provided with them. A fixed version does not include future updates, a hosted account or indefinite recovery support unless expressly agreed. Open-source components keep their own license and provenance requirements.

Retention, return and recovery

The order must set a purpose-specific retention period or event for project content, a return/deletion method and any necessary support window. We retain only the minimum order, acceptance, accounting, compliance and dispute evidence needed under applicable obligations. Those records need not include the full project formulation or dataset.

Deletion requests follow the Privacy Notice. Eligible active-system data is targeted for deletion or irreversible deidentification through the applicable response process, normally within 30 calendar days and within one month where required. Our recovery-copy policy calls for encryption, restricted access, exclusion from ordinary processing and expiry within 90 days after removal from active use, except for a documented retention duty or lawful hold. Automated enforcement and coverage have not been verified across every historical system. We check relevant copies, explain remaining steps and timing or lawful exceptions, and reapply approved deletion after restoration. A technical gap is not a lawful retention exception; shorter legal deadlines prevail.

Before new scoped-project data is transferred, its actual storage, access, retention, deletion and recovery controls must be agreed and verified. A shorter retention term, a specific region or a complete erasure outcome requires verification before it is promised. Provider records outside Sunnyday’s control may have independent lawful retention, while processors must receive required instructions.

Gateway history and future automation

Historical gateway acceptance, payment, refund, usage, compliance and credential-hash records remain evidence of their original transaction and version. We do not rewrite an old policy identifier to describe new wording. A correction is an additive, dated record; privacy minimization and lawful retention still apply.

Future API, MCP/ACP or x402 operation requires a separately approved data inventory, lawful retention schedule, buyer authority, policy receipt, incident process and provider controls. It is not enabled by publishing this statement. Public-chain records can remain visible and cannot be erased by Sunnyday; no customer project content or personal identifiers should be placed there.

Requests and incidents

Send privacy or deletion requests to privacy@sunn3d.com, commercial concerns to cemforge@sunn3d.com, and security reports through the security contact. Do not include live credentials or unnecessary sensitive data. We investigate reported incidents, take proportionate containment and recovery steps, and provide notices and assistance where required by law or the applicable data agreement.