Microskill Data Handling

Microskill Data Handling Policy

This Microskill Data Handling Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), handles data submitted to and produced by microskills, including inline payloads, output payloads, files, file references, metadata, telemetry, external-service calls, and support-related examples.

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 is designed to let applications, developers, AI agents, automation systems, and other software clients invoke explicit, single-purpose capabilities called microskills.

This policy explains:

• what a microskill receives;
• what a microskill returns;
• how raw payloads are handled;
• what is and is not stored;
• how telemetry differs from payloads;
• how file-based workflows are handled;
• when external services may be involved;
• what skill-level data handling labels mean;
• what customers are responsible for before submitting data;
• how this policy relates to privacy, DPA, security, retention, file handling, and AI/training use.

2. Core promises

Squillify's default microskill data handling model is based on data minimisation, explicit execution, and transparency.

Default platform promises:

• raw submitted microskill payloads are processed only to perform the requested execution;
• raw submitted microskill payloads are not permanently stored as part of normal execution;
• usage telemetry is designed to be metadata-only;
• customer-submitted raw microskill payloads are not used to train artificial intelligence models;
• customer-submitted raw microskill payloads are not sold;
• customer-submitted raw microskill payloads are not sent to hidden external services;
• temporary file storage is used only where required by a file-based workflow;
• temporary files are short-lived by default;
• customers decide what their users, agents, applications, API keys, and integrations may submit.

These promises describe the default platform model. Individual skills may have additional characteristics, labels, restrictions, or external-service behaviour that customers must review before use.

3. What a microskill receives

When you invoke a microskill, you send an input payload defined by that skill's input schema.

The input payload may include:

• text;
• structured JSON data;
• numbers;
• identifiers;
• URLs;
• configuration parameters;
• file references;
• metadata required by the skill;
• customer-supplied options;
• other fields defined by the skill's input contract.

The contents of the payload are determined by the customer, application, agent, script, or API client making the request.

Depending on what is submitted, a payload may contain personal data, confidential data, regulated data, trade secrets, third-party data, authentication secrets, or other sensitive information.

Customers are responsible for deciding whether the data is appropriate and lawful to submit.

4. What a microskill returns

A microskill returns an output payload defined by that skill's output schema.

The output may include:

• transformed text;
• structured JSON data;
• calculated values;
• validation results;
• metadata;
• file references;
• generated outputs;
• error information;
• warnings;
• execution status;
• other fields defined by the skill's output contract.

Outputs may contain personal data or sensitive information if the input contained such data or if the skill generated such data from the input.

Customers are responsible for how outputs are stored, displayed, logged, transmitted, or used in their own systems.

5. Raw payload handling

A raw payload means the submitted input or returned output content processed by a microskill.

Default rules:

• raw payloads are processed to perform the requested execution;
• raw payloads are not permanently stored as part of normal execution;
• raw payloads are not intentionally written to permanent operational logs;
• raw payloads are not used for AI model training;
• raw payloads are not added to shared training datasets;
• raw payloads are not sold;
• raw payloads are not made available to other tenants;
• raw payloads are not sent to external services unless the skill is explicitly labelled as using an external service or the customer configures the external destination.

This model supports the GDPR principles of data minimisation and storage limitation, but it does not remove the customer's responsibility to submit only data that is lawful and appropriate.

6. What "not permanently stored" means

"Not permanently stored" means that Squillify's normal execution path is designed not to retain raw submitted microskill payloads as durable platform records after execution.

It does not mean that data is never temporarily present in memory, buffers, transient processing components, network transmission, short-lived file storage, provider infrastructure, or temporary diagnostic contexts necessary to perform the requested operation.

It also does not override:

• temporary file handling;
• short-lived output availability;
• operational metadata;
• security or abuse investigations;
• legal obligations;
• customer-provided support examples;
• external-service use explicitly disclosed for a skill;
• provider-level technical behaviour required to operate the service.

This distinction matters. Squillify minimises durable raw payload retention by design; it does not claim that submitted data is never processed.

7. Telemetry and metadata

Usage telemetry is designed to be metadata-only.

Telemetry may include:

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

Telemetry should not include raw submitted payload content as part of normal execution.

Telemetry is used for:

• billing;
• quota enforcement;
• rate limiting;
• usage visibility;
• reliability monitoring;
• debugging;
• platform operations;
• abuse prevention;
• security monitoring;
• product analytics;
• aggregate reporting.

Telemetry retention is described in the Telemetry and Analytics Policy and Data Retention Policy.

8. File-based workflows

Some microskills operate on files or produce files.

File-based workflows may involve:

• uploaded files;
• generated files;
• transformed files;
• converted files;
• extracted files;
• temporary intermediate files;
• output files;
• opaque file references;
• short-lived upload or download URLs.

Where file handling is used, files are governed by the File Handling Policy and Data Retention Policy.

Default assumptions:

• files are addressed by opaque file references, not arbitrary filesystem paths;
• file references are scoped to the owning tenant;
• file access is checked when a file reference is resolved;
• temporary files are short-lived;
• uploaded/input temporary files default to approximately 5 minutes;
• generated/output temporary files default to approximately 10 minutes;
• the production file TTL ceiling is 10 minutes;
• presigned URLs are short-lived;
• default maximum presigned URL lifetime is approximately 60 seconds;
• expired files may return 410 Gone;
• file content is not intended to be used as persistent storage.

Customers must not use Squillify file handling as long-term storage.

9. External service use

Most microskills are intended to be self-contained unless explicitly labelled otherwise.

A microskill may use an external service where its function requires:

• fetching a public URL;
• calling a third-party API;
• using a provider-backed capability;
• sending data to a customer-configured webhook;
• writing to an external system;
• using an external OCR, AI, media, conversion, validation, enrichment, or integration provider.

Where submitted data leaves Squillify as part of a microskill execution, the skill must be explicitly labelled or documented as using an external service.

External service use is governed by the External Service Use Policy, Sub-processors page, Data Processing Agreement, Privacy Policy, and relevant skill documentation.

Customers are responsible for deciding whether submitted data may lawfully be sent to the relevant external service.

10. Skill descriptors and data handling labels

Each microskill should expose or be associated with a descriptor that defines its relevant operational and data handling characteristics.

A descriptor may include:

• skill key;
• version;
• input schema;
• output schema;
• execution mode;
• reliability mode;
• latency class;
• side-effect classification;
• input sources;
• output targets;
• platform I/O profile;
• file handling requirements;
• external service use;
• telemetry behaviour;
• data handling labels;
• privacy or PII policy;
• required scopes;
• quota or rate-limit profile;
• retention profile;
• safety warnings.

Customers should review the descriptor before sending data through a skill, especially where the data may be personal, confidential, regulated, sensitive, or subject to sector-specific rules.

11. Data handling labels

Squillify may use labels or badges to describe skill behaviour.

Labels may include:

The exact UI labels may differ, but their meaning should remain consistent with this policy.

12. Per-skill differences

Different microskills may have different data handling characteristics.

For example:

• a text formatter may be self-contained and inline-only;
• a file converter may use temporary file storage;
• a URL metadata skill may fetch an external URL;
• a webhook skill may write to a customer-configured endpoint;
• an OCR skill may be self-contained or provider-backed depending on implementation;
• an AI-backed skill may send data to a model provider if explicitly labelled.

This policy describes the default platform model. It does not override specific skill descriptors, external-service disclosures, or additional terms that apply to a particular capability.

13. Customer responsibility for submitted data

Customers are responsible for determining what data may be submitted to Squillify.

Customers must consider:

• whether the data contains personal data;
• whether the data contains special categories of personal data;
• whether the data contains confidential or proprietary data;
• whether the data contains regulated financial, health, criminal offence, children's, government identifier, payment card, authentication, or sector-specific data;
• whether the customer has authority to process and submit the data;
• whether the selected skill is appropriate for the data;
• whether agentic or automated submission creates additional risk;
• whether customer-side filtering, approval, minimisation, or redaction is needed;
• whether external-service skills should be disabled or restricted.

Squillify does not provide a general-purpose sensitive data detection or classification service and does not guarantee that sensitive or regulated data will be detected or blocked.

14. Personal data and GDPR roles

Customer-submitted microskill payloads may contain personal data if the customer submits personal data.

For personal data contained in customer-submitted payloads and processed on the customer's instructions, the customer generally acts as controller and Squillify acts as processor.

The Data Processing Agreement governs Squillify's processing of Customer Personal Data as processor.

Squillify may act as controller for account data, platform administration, billing, security, abuse prevention, legal compliance, and other purposes described in the Privacy Policy.

15. Sensitive and regulated data

Customers must not submit special categories of personal data, criminal offence data, health data, children's data, payment card data, government identifiers, authentication secrets, regulated financial data, confidential third-party data, or other high-risk data unless:

• the processing is lawful;
• the customer has authority to submit the data;
• the selected skill is appropriate for that data;
• required contractual, technical, and organisational safeguards are in place;
• any sector-specific rules have been assessed by the customer.

Customers subject to regulated-sector obligations, including financial services, healthcare, public sector, education, employment, or defence-related obligations, must assess whether Squillify is appropriate for their use case before submitting regulated data.

16. AI and training use

Squillify does not use customer-submitted raw microskill payloads to train artificial intelligence models.

Squillify does not use customer-submitted raw microskill payloads to improve third-party AI models.

Operational metadata may be used for security, billing, reliability, abuse prevention, debugging, capacity planning, product analytics, and service improvement.

AI and training use are described in the AI / Training Use Policy.

17. Support and debugging

Because Squillify does not permanently store raw submitted microskill payloads as part of normal execution, support may not be able to inspect or reconstruct the exact input or output of a microskill run.

Support may use:

• request identifiers;
• run identifiers;
• timestamps;
• skill key and version;
• status codes;
• error codes;
• latency;
• file metadata;
• quota and rate-limit events;
• operational metadata;
• customer-provided sanitized examples.

Support may ask customers to provide sanitized examples when investigating execution issues.

Customers must remove or mask secrets, full API keys, passwords, private keys, payment card data, unnecessary personal data, confidential data, regulated data, and other sensitive information before sharing examples with support.

18. Error handling and logs

Microskill executions may generate errors, warnings, exceptions, validation failures, or diagnostic metadata.

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

Logs may include:

• error code;
• skill key;
• tenant identifier;
• API key identifier or derived identifier;
• request identifier;
• status;
• latency;
• validation error metadata;
• file metadata;
• system component;
• timestamp;
• abuse or security signals.

Validation errors should avoid echoing raw submitted payload content where possible.

If temporary diagnostic logging is ever required for a specific investigation, it should be limited, documented, access-controlled, time-bound, and deleted when no longer needed.

19. Hashes, checksums, and archive metadata

Squillify may use hashes, checksums, or derived metadata for:

• integrity checks;
• deduplication where applicable;
• file validation;
• audit support;
• abuse prevention;
• debugging;
• archive or file handling workflows;
• deletion verification.

Hashes or checksums are not intended to function as raw payload storage, but depending on context they may still be considered personal data if they can be linked to an individual or customer.

Retention of such metadata is described in the Data Retention Policy.

20. Tenant and API key controls

Customers can reduce data exposure by using available controls, including:

• tenant membership management;
• API key scoping;
• per-key skill access;
• key rotation;
• key revocation;
• rate limits;
• quotas;
• role-based access;
• external-service restrictions where available;
• customer-side agent guardrails;
• approval flows for risky actions;
• input minimisation;
• redaction before submission.

Customer-side control is especially important for agentic use cases where applications or agents may submit data automatically.

21. Agentic use

Squillify is designed to support applications, AI agents, automation systems, and software clients.

Customers are responsible for agent behaviour under their accounts and API keys.

Customers must ensure that agents:

• submit only authorised data;
• respect rate limits and quotas;
• do not expose API keys;
• do not submit unnecessary personal or sensitive data;
• do not call external-service skills inappropriately;
• do not trigger unintended external-write actions;
• do not enter uncontrolled retry loops;
• handle errors and expired file references safely;
• comply with the Terms of Service, Acceptable Use Policy, and API Usage and Fair Use Policy.

22. What this policy does not promise

This policy does not promise that:

• Squillify will never process any personal data;
• Squillify identifies, classifies, or flags sensitive data on your behalf;
• Squillify blocks all regulated data;
• Squillify makes customer submissions lawful;
• Squillify classifies customer payloads;
• Squillify anonymises all payloads;
• Squillify guarantees suitability for sensitive or regulated data;
• Squillify guarantees every skill has identical data handling;
• Squillify guarantees that third-party external providers behave according to this policy unless contractually required;
• Squillify stores raw payloads for customer recovery;
• support can reconstruct raw execution inputs or outputs after execution.

Customers must not treat this policy as a substitute for their own legal, security, privacy, compliance, or data governance review.

23. Relationship with other policies

This policy should be read together with:

• Privacy Policy;
• Data Processing Agreement;
• Data Retention Policy;
• File Handling Policy;
• Telemetry and Analytics Policy;
• External Service Use Policy;
• AI / Training Use Policy;
• Security Policy;
• Support Policy;
• Tenant and API Key Responsibility Policy;
• Acceptable Use Policy;
• API Usage and Fair Use Policy;
• Sub-processors page.

If there is a conflict between this policy and the Data Processing Agreement regarding processing of Customer Personal Data on behalf of a customer, the Data Processing Agreement controls for that processing.

24. Changes to this policy

Squillify may update this policy from time to time.

If changes materially affect raw payload storage, training use, telemetry, file handling, or external-service use, Squillify will provide reasonable notice through appropriate channels.

Squillify will not intentionally change the default no-permanent-raw-payload-storage or no-training position without updating this policy and related documentation.

25. Contact

For questions about this policy, contact:

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

For abuse involving submitted payloads or microskill execution, contact [email protected].