Telemetry and Analytics

Telemetry and Analytics Policy

This Telemetry and Analytics Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), records, uses, retains, and protects metadata about platform activity, microskill invocations, API requests, quota events, billing counters, errors, performance, security, and abuse prevention.

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

1. Purpose

Squillify needs telemetry to operate a reliable, fair, secure, and billable API platform.

This policy explains:

• what telemetry Squillify records;
• what Squillify does not record by default;
• how telemetry differs from raw payloads;
• why telemetry is needed;
• how telemetry is used for billing, quotas, reliability, security, and abuse prevention;
• how telemetry is retained;
• how customers can use telemetry;
• how telemetry relates to privacy, DPA, data retention, and AI/training use.

2. Core position

Squillify's telemetry model is designed to be metadata-only.

Default principles:

• telemetry records metadata about requests and executions;
• telemetry is designed not to include raw submitted microskill payloads;
• telemetry is designed not to include raw file content;
• telemetry is used for billing, quotas, operations, reliability, security, support, and abuse prevention;
• telemetry is not used to train artificial intelligence models;
• recent telemetry is retained for approximately 90 days in the production-intended configuration;
• aggregate telemetry is retained for approximately 90 days;
• telemetry may still be personal data where it relates to an identified or identifiable person.

Metadata-only does not mean anonymous. Tenant identifiers, user identifiers, API key identifiers, IP addresses, timestamps, and similar records may be personal data depending on context.

3. What telemetry is

Telemetry means technical and operational metadata recorded by Squillify to understand and operate the service.

Telemetry may be generated by:

• API requests;
• microskill executions;
• skill discovery;
• skill descriptor access;
• file upload or download operations;
• temporary file expiry;
• rate-limit decisions;
• quota decisions;
• billing events;
• authentication events;
• dashboard activity;
• support investigations;
• security and abuse detection;
• operational monitoring.

Telemetry is not intended to be a copy of the raw input or output submitted to a microskill.

4. Typical telemetry fields

Squillify may record fields such as:

The exact fields may evolve as the platform changes.

5. What telemetry excludes by default

Squillify telemetry is designed to exclude:

• raw submitted microskill input payloads;
• raw microskill output payloads;
• raw uploaded file content;
• raw generated file content;
• full API key secrets;
• passwords;
• private keys;
• access tokens;
• session cookies;
• payment card numbers;
• unnecessary personal data;
• customer secrets.

Telemetry may include sizes, hashes, identifiers, status codes, or metadata related to those items where needed for security, billing, integrity, debugging, or operations.

6. Raw payloads and telemetry

Raw submitted microskill payloads are processed to perform the requested execution.

Telemetry records metadata about the execution, not the raw content of the input or output.

Example:

• Squillify may record that text.slugify ran successfully, took 38ms, consumed 2048 input bytes, and was billed to a given tenant and API key.
• Squillify should not record the actual text submitted to text.slugify as permanent telemetry.

This supports data minimisation and reduces durable exposure of submitted content.

7. File telemetry

For file-based workflows, Squillify may record file metadata.

File telemetry may include:

• file reference identifier;
• file purpose;
• file status;
• tenant identifier;
• API key identifier or derived identifier;
• skill key;
• file size;
• content type;
• checksum or hash where used;
• upload time;
• expiry time;
• deletion time;
• deletion attempts;
• deletion error;
• presigned URL generation metadata;
• download status;
• error codes;
• file count;
• temporary storage status.

File telemetry should not include raw file content.

File handling is described in the File Handling Policy.

8. Error telemetry

Squillify may record error telemetry to diagnose failures and improve reliability.

Error telemetry may include:

• error code;
• error category;
• validation error type;
• rejected field name;
• skill key;
• skill version;
• status code;
• component name;
• timestamp;
• request identifier;
• tenant identifier;
• API key identifier or derived identifier;
• stack trace metadata where appropriate;
• file metadata where relevant;
• retry or rejection metadata.

Error telemetry should avoid echoing raw submitted payload values where possible.

Validation errors may identify fields or schema paths that failed validation, but should avoid storing raw field values unless explicitly required, controlled, and temporary.

9. Logs

Operational logs are related to telemetry but may be produced by infrastructure, application services, security systems, providers, or support tooling.

Logging practices are designed to favour metadata over raw payload content.

Logs may be used for:

• debugging;
• reliability;
• service operations;
• security monitoring;
• abuse prevention;
• incident response;
• audit support;
• provider troubleshooting.

Logs should redact or avoid:

• full API keys;
• authorization headers;
• passwords;
• tokens;
• private keys;
• session cookies;
• payment card data;
• raw payloads;
• unnecessary personal data.

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

10. Why telemetry is used

Squillify may use telemetry for:

• billing;
• quota enforcement;
• rate limiting;
• usage reporting;
• customer dashboards;
• support and troubleshooting;
• reliability monitoring;
• performance monitoring;
• capacity planning;
• security monitoring;
• abuse prevention;
• fraud prevention;
• incident response;
• service improvement;
• aggregate analytics;
• internal operational reporting;
• legal compliance;
• enforcement of Terms and policies.

Telemetry is necessary for Squillify to operate a paid, quota-based, API-driven, agent-compatible platform.

11. Billing and quota telemetry

Squillify uses telemetry to measure usage and enforce commercial limits.

Billing and quota telemetry may include:

• billable execution count;
• non-billable execution count;
• success count;
• error count;
• rejected request count;
• quota reservation;
• quota charge;
• quota denial;
• rate-limit rejection;
• skill category;
• heavy-skill marker;
• file operation count;
• usage by tenant;
• usage by API key;
• usage by billing period.

Billing and quota telemetry is governed by the Billing and Refund Policy and API Usage and Fair Use Policy.

12. Customer visibility

Squillify may expose telemetry to customers through dashboard, API, exports, or reports.

Customer-visible telemetry may include:

• usage summary;
• usage by skill;
• usage by API key;
• recent executions;
• quota status;
• rate-limit rejections;
• billing counters;
• error categories;
• performance indicators;
• file operation metadata.

Customer-visible telemetry is scoped to the customer's tenant and access permissions.

Customers should not assume telemetry is a complete application log or raw execution archive.

13. Internal analytics

Squillify may use telemetry for internal analytics.

Internal analytics may include:

• skill popularity;
• aggregate error rates;
• aggregate latency;
• aggregate throughput;
• common rejection reasons;
• capacity planning;
• documentation improvement;
• product prioritisation;
• abuse trend detection;
• reliability improvement;
• cost monitoring.

Internal analytics should use aggregate or minimised data where practical.

Internal analytics are not raw customer payload analytics.

14. Security and abuse telemetry

Squillify may use telemetry to detect and investigate security or abuse risks.

Security and abuse telemetry may include:

• suspicious request patterns;
• repeated failed authentication;
• excessive rate-limit violations;
• unusual quota consumption;
• high-volume traffic;
• malformed requests;
• policy violations;
• external-service abuse;
• file handling abuse;
• suspected credential compromise;
• suspected scraping;
• blocked destinations;
• IP addresses;
• user agents;
• tenant and API key identifiers.

Security and abuse telemetry may be retained longer where reasonably necessary to protect the platform, customers, providers, or third parties.

15. Retention

Default retention assumptions:

Retention is described in more detail in the Data Retention Policy.

No active version of this policy should contain unconfirmed operational log retention periods.

16. Append-only usage records

Squillify may use append-only usage records to support billing, auditability, quota enforcement, and operational integrity.

Append-only records are designed to preserve the fact that usage occurred.

Append-only does not mean raw payload storage.

Corrections, reversals, refunds, credits, or billing adjustments may be represented through additional records rather than destructive modification of historical records.

17. Hashes and derived metadata

Squillify may use hashes, checksums, derived identifiers, or fingerprints for:

• file integrity;
• deletion verification;
• deduplication where applicable;
• abuse prevention;
• debugging;
• correlation;
• audit support;
• idempotency;
• quota and billing integrity.

Hashes and derived metadata are not intended to store raw payload content.

Depending on context, hashes or derived identifiers may still be personal data if they can be linked to an identified or identifiable person, tenant, user, or customer.

18. AI and training use

Telemetry is not used to train Squillify artificial intelligence models.

Telemetry is not used to train third-party AI models.

Squillify may use operational metadata 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.

19. Personal data and GDPR

Telemetry may contain personal data where it relates to an identified or identifiable person.

Examples may include:

• user identifiers;
• account email where present in account systems;
• IP address;
• authentication events;
• support records;
• tenant membership;
• API key metadata associated with a user;
• timestamps linked to a user or tenant.

Squillify processes such data in accordance with the Privacy Policy, Data Processing Agreement where applicable, and Applicable Data Protection Law.

Where Squillify processes telemetry for its own platform purposes, Squillify may act as controller.

Where telemetry relates to Customer Personal Data processed on behalf of a customer, Squillify may act as processor depending on the context.

20. Customer responsibilities

Customers are responsible for:

• deciding what data their systems submit;
• maintaining their own application logs where needed;
• not relying on Squillify telemetry as a raw payload archive;
• not submitting secrets or unnecessary personal data;
• configuring API keys and agents safely;
• monitoring their own agents and integrations;
• reviewing usage and billing regularly;
• investigating unexpected usage;
• exporting telemetry where available before retention expiry;
• complying with their own legal and regulatory obligations.

Because Squillify telemetry is metadata-only by design, customers may need their own logs for debugging, audit, regulated workflows, or customer support.

21. Support investigations

Support may use telemetry to investigate issues.

Support may ask for:

• request identifier;
• run identifier;
• tenant context;
• API key label or partial identifier;
• skill key and version;
• approximate timestamp;
• status code;
• error code;
• expected versus actual behaviour;
• sanitized example input or file where needed.

Because Squillify does not permanently store raw submitted payloads by default, support may be unable to reconstruct the exact request without customer-provided sanitized examples.

Support is described in the Support Policy.

22. What this policy does not promise

This policy does not promise that:

• telemetry is anonymous;
• telemetry contains no personal data;
• Squillify stores raw payloads for later debugging;
• Squillify can reconstruct every execution;
• Squillify detects all sensitive data;
• Squillify blocks all secrets;
• customer applications do not log payloads;
• third-party providers never create their own logs;
• all telemetry has identical retention periods;
• security and abuse records are deleted on the same schedule as recent usage telemetry.

Customers must assess their own logging, monitoring, privacy, compliance, and audit obligations.

23. Relationship with other policies

This policy should be read together with:

• Microskill Data Handling Policy;
• Data Retention Policy;
• Privacy Policy;
• Data Processing Agreement;
• AI / Training Use Policy;
• Security Policy;
• File Handling Policy;
• API Usage and Fair Use Policy;
• Billing and Refund Policy;
• Support Policy;
• Tenant and API Key Responsibility 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 what telemetry is recorded, whether raw payloads are excluded, telemetry retention, billing counters, training use, or customer visibility, Squillify will provide reasonable notice through appropriate channels.

Squillify will not intentionally change the default metadata-only telemetry position without updating this policy and related documentation.

25. Contact

For questions about telemetry and analytics, contact:

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

For suspected abuse involving telemetry, usage, or billing, contact [email protected].