Data Retention

Data Retention Policy

This Data Retention Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), retains, deletes, aggregates, anonymises, or expires data in connection with the Squillify platform, APIs, dashboard, microskill execution environment, telemetry, file handling, billing, support, and related services.

This policy is a draft and is not effective until published as active by Squillify. It is intended for product, engineering, security, privacy, and legal review before launch.

1. Purpose

Squillify's retention model is designed around data minimisation.

This policy explains:

• what categories of data Squillify handles;
• which data is retained;
• which data is not permanently retained by default;
• how long key categories are retained;
• how temporary files expire;
• how telemetry is retained;
• how billing, legal, security, and support records are handled;
• how deletion works after account or tenant closure;
• what exceptions may apply.

2. Core retention principles

Squillify applies the following retention principles:

• raw submitted microskill payloads are not permanently stored as part of normal execution;
• usage telemetry is designed to be metadata-only;
• recent usage telemetry is retained for a limited operational period;
• aggregate telemetry is retained for a longer but limited period;
• temporary files are short-lived;
• expired temporary files may become unavailable and may return 410 Gone;
• billing, tax, accounting, legal, fraud, security, and dispute records may be retained for longer where required or permitted by law;
• data is deleted, anonymised, aggregated, or made inaccessible when it is no longer needed for its purpose, subject to legal and operational exceptions.

3. Legal basis for retention

Squillify retains personal data only where there is a lawful basis or valid operational need, including:

• providing the service;
• performing a contract;
• complying with legal obligations;
• billing and accounting;
• tax compliance;
• security monitoring;
• abuse prevention;
• fraud prevention;
• dispute handling;
• support;
• platform reliability;
• enforcing Terms of Service and policies;
• establishing, exercising, or defending legal claims.

Where Squillify processes Customer Personal Data as processor, retention is also governed by the Data Processing Agreement and the customer's documented instructions.

4. Categories of data

Squillify handles several categories of data, each with a different retention approach.

5. Raw microskill payloads

Squillify is designed so that raw submitted microskill payloads are not permanently stored as part of normal execution.

This means:

• raw inputs are processed to perform the requested microskill execution;
• raw outputs are returned to the requester;
• raw payloads are not added to permanent execution logs by default;
• raw payloads are not used for AI model training;
• raw payloads are not used for hidden third-party processing unless the relevant skill is explicitly labelled as using an external service;
• support generally cannot retrieve raw payloads after execution.

Customers are responsible for determining what data their users, applications, agents, API keys, and integrations submit to Squillify.

6. Usage telemetry

Usage telemetry is designed to be metadata-only.

It may include:

• request timestamp;
• tenant identifier;
• API key identifier or derived identifier;
• skill key and version;
• execution status;
• latency;
• error code;
• quota events;
• rate-limit events;
• billing counters;
• file metadata;
• payload size;
• content type;
• deletion status;
• operational and security signals.

Recent usage telemetry is retained for approximately 90 days in the production-intended configuration. Non-production environments may intentionally use shorter windows and are not evidence of the launch retention period.

Telemetry is used for:

• usage visibility;
• billing;
• quota enforcement;
• rate limiting;
• support;
• reliability;
• performance monitoring;
• abuse prevention;
• security monitoring;
• debugging;
• operational reporting.

7. Aggregate telemetry

Aggregate telemetry may include counters and summaries derived from usage events.

Aggregate telemetry may include:

• total executions;
• executions by skill;
• executions by tenant;
• executions by API key;
• success and error counts;
• billable usage counts;
• aggregate latency;
• aggregate quota consumption;
• aggregate file operation counts.

Aggregate telemetry is retained for approximately 90 days.

Aggregates should not include raw submitted payloads.

8. Temporary file handling

Some Squillify capabilities may use temporary files.

Temporary files may include:

• uploaded files;
• generated files;
• converted files;
• transformed files;
• intermediate files;
• output files;
• file references used by a microskill workflow.

Temporary file availability depends on purpose:

The normal expiry time controls access. The cleanup scheduler runs separately, so physical deletion may occur after expiry. A one-day object-storage lifecycle rule is configured as a backstop for temporary-object cleanup; it does not extend the period during which an expired file is authorised or available.

After expiry:

• files may be automatically deleted;
• download links may stop working;
• file references may become invalid;
• expired file access may return 410 Gone;
• support may not be able to recover the file.

Temporary files are described in more detail in the File Handling Policy.

9. Presigned URLs

Where Squillify uses presigned URLs for upload or download, those URLs are short-lived.

Default maximum lifetime:

60 seconds

Presigned URLs may expire earlier where required for security, policy, provider behaviour, or operational reasons.

Customers must design integrations to handle expired URLs and request a new operation where appropriate.

10. Account and tenant data

Account and tenant data is retained while the account or tenant is active.

After account closure, tenant deletion, or subscription termination, Squillify may retain account and tenant data for a limited period where needed for:

• billing;
• tax;
• accounting;
• security;
• fraud prevention;
• abuse prevention;
• dispute handling;
• legal compliance;
• enforcement of Terms;
• backup rotation;
• legitimate business records.

Before this policy becomes active, Squillify must confirm the standard post-closure retention period for inactive accounts and deleted tenants.

No active version of this policy should contain an unconfirmed post-closure retention period.

11. API key metadata and secrets

API key secret values should not be retrievable after creation.

Squillify may retain:

• key identifiers;
• hashed or equivalent verification material;
• key labels;
• key creation timestamps;
• key revocation timestamps;
• scope metadata;
• rate-limit settings;
• quota settings;
• last-used metadata;
• security events;
• audit metadata.

API key metadata may be retained after key revocation where needed for security, audit, billing, abuse prevention, or dispute handling.

Customers are responsible for rotating and revoking API keys when needed.

12. Billing, invoice, tax, and accounting records

Billing and invoice records may be retained for longer periods where required by Luxembourg, EU, tax, accounting, commercial, or payment processing obligations.

Such records may include:

• customer billing identity;
• company name;
• billing address;
• VAT or tax identifier;
• invoices;
• payment status;
• transaction identifiers;
• plan history;
• refund records;
• chargeback or dispute records;
• tax calculation records;
• accounting records.

For Luxembourg business accounting records, a retention period of 10 years may apply.

This section does not override mandatory legal retention obligations.

13. Support records

Support records may include:

• support tickets;
• emails;
• dashboard support messages;
• customer-provided examples;
• screenshots;
• logs;
• sanitized payload examples;
• attachments;
• support notes;
• resolution history.

Support records are retained as needed to:

• respond to requests;
• investigate issues;
• maintain service quality;
• document customer communications;
• resolve disputes;
• protect security;
• improve documentation;
• comply with legal obligations.

Customers should avoid sending secrets, full API keys, passwords, private keys, payment card data, unnecessary personal data, confidential data, or regulated data in support requests.

Because Squillify does not permanently store raw submitted payloads by default, support may ask customers to provide sanitized examples when investigating execution issues.

Before this policy becomes active, Squillify must confirm the standard retention period for support records.

14. Security and abuse records

Security and abuse records may be retained for as long as reasonably necessary to protect Squillify, customers, infrastructure, providers, or third parties.

Such records may include:

• authentication events;
• suspicious activity records;
• abuse reports;
• rate-limit violations;
• quota abuse records;
• blocked traffic;
• security alerts;
• vulnerability reports;
• incident records;
• enforcement actions;
• IP addresses;
• user-agent data;
• request metadata;
• API key metadata;
• fraud and misuse signals.

Security and abuse records may be retained longer than ordinary operational telemetry where necessary for investigation, platform protection, legal compliance, or defence of claims.

15. Operational logs

Operational logs are retained for limited operational, security, reliability, debugging, and compliance purposes.

Logging practices are designed to avoid permanent raw payload capture as part of normal execution.

If temporary diagnostic logging is required for a specific investigation, it must be:

• limited;
• documented;
• access-controlled;
• time-bound;
• deleted when no longer needed;
• consistent with the Privacy Policy, Data Processing Agreement, Security Policy, and this policy.

16. Backups

Backups may contain copies of retained data until the relevant backup cycle expires.

Backup deletion may occur through rotation rather than immediate deletion from every backup copy.

Where data is deleted from production systems, it may remain in backups for a limited period until overwritten or expired, unless earlier deletion is technically and operationally feasible.

Backups are not used to restore individual expired payloads or temporary files unless Squillify determines that restoration is necessary and lawful for security, legal, disaster recovery, or operational reasons.

Before this policy becomes active, Squillify must confirm the standard backup retention period.

17. Legal holds and exceptions

Squillify may retain data longer where necessary for:

• legal obligations;
• tax or accounting obligations;
• regulatory requests;
• court orders;
• law enforcement requests;
• sanctions or export compliance;
• fraud prevention;
• security investigations;
• abuse investigations;
• payment disputes;
• chargebacks;
• debt recovery;
• enforcement of Terms;
• establishment, exercise, or defence of legal claims.

When a legal hold applies, deletion may be delayed until the hold is lifted.

18. Deletion after account closure or tenant deletion

When an account is closed or a tenant is deleted, Squillify will delete, anonymise, aggregate, or retain data according to:

• the Terms of Service;
• the Data Processing Agreement where applicable;
• this policy;
• the Privacy Policy;
• the Billing and Refund Policy;
• legal obligations;
• security and abuse needs;
• backup cycles;
• technical feasibility.

Some data may already be unavailable before closure because of short-lived retention, including raw microskill payloads and expired temporary files.

Before this policy becomes active, Squillify must define the operational deletion workflow and customer-facing deletion expectations for tenant closure.

19. Customer deletion requests and data subject rights

Customers may request deletion of account or tenant data through the channels made available by Squillify.

Individuals may exercise data protection rights as described in the Privacy Policy.

Where Squillify acts as processor on behalf of a customer, Squillify may refer data subject requests to the relevant customer or assist the customer under the Data Processing Agreement.

Because raw microskill payloads are not permanently stored by default, Squillify may be unable to access, retrieve, correct, export, or delete raw payload content after execution or after expiry of temporary retention periods.

20. Anonymisation and aggregation

Squillify may anonymise or aggregate data for reporting, reliability, abuse prevention, security, capacity planning, and product analytics.

Where data is truly anonymised so that individuals are no longer identifiable, it may no longer be personal data under data protection law.

Squillify will not intentionally use anonymised or aggregated information to identify a customer, user, data subject, or raw payload content.

21. Data export

Export availability depends on the data category and the customer's plan.

Exportable data may include:

• account information;
• tenant metadata;
• API key metadata;
• usage summaries;
• billing records;
• invoices;
• support records where appropriate.

Raw microskill payloads and expired temporary files may not be exportable because Squillify is designed not to permanently store raw payloads and to expire temporary files quickly.

22. Retention schedule summary

No active version of this policy should contain pending confirmation values.

23. Customer responsibilities

Customers are responsible for:

• deciding what data their users, agents, applications, API keys, and integrations submit;
• avoiding unnecessary personal data in payloads;
• avoiding submission of prohibited, sensitive, regulated, or high-risk data unless lawful and appropriate;
• maintaining their own records where required;
• exporting data they need before deletion or expiry;
• designing integrations to handle expired files and expired URLs;
• retaining their own logs where needed for audit, debugging, compliance, or dispute purposes;
• respecting the Terms of Service, Data Processing Agreement, Acceptable Use Policy, and API Usage and Fair Use Policy.

24. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect retention periods, deletion behaviour, temporary file handling, telemetry retention, or customer rights, Squillify will provide reasonable notice through appropriate channels.

The version, last updated date, and effective date are shown at the top of this policy.

25. Contact

For questions about this policy, contact:

• Privacy: [email protected]
• Legal: [email protected]
• Security: [email protected]
• Support: [email protected]