Service Availability Policy

Service Availability Policy

This Service Availability Policy explains how Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), approaches service availability, maintenance, incidents, exclusions, and service level commitments.

This policy is a draft and is not effective until published as active by Squillify. It is intended for legal and operational review before launch.

1. Purpose

Squillify is designed to provide reliable access to deterministic microskill execution through APIs, dashboard features, and related services.

This policy explains:

• how Squillify approaches service availability;
• what availability commitments may apply;
• how maintenance and incidents are handled;
• what is excluded from availability calculations;
• how beta, preview, free, and enterprise features are treated;
• how this policy relates to support, billing, and the Terms of Service.

This policy does not create a formal Service Level Agreement ("SLA") unless an applicable plan, order form, enterprise agreement, or written contract expressly says so.

2. Scope

This policy applies to the Squillify production services made generally available to customers, including:

• public Squillify APIs;
• microskill execution services;
• tenant dashboard access;
• authentication-dependent dashboard features;
• usage and telemetry views;
• billing-related service access;
• file handling features where available;
• public documentation and trust pages, where relevant.

This policy does not apply to:

• beta, preview, experimental, alpha, internal, test, sandbox, or development features;
• local customer environments;
• third-party systems outside Squillify's control;
• customer applications, agents, scripts, integrations, networks, devices, or credentials;
• issues caused by customer configuration, customer traffic, or customer misuse;
• features expressly labelled as unsupported or best-effort.

3. Availability approach

Squillify aims to provide a reliable service through architecture and operational controls such as:

• stateless execution where practical;
• horizontally scalable service design;
• rate limiting and quota controls;
• tenant isolation controls;
• monitoring and operational telemetry;
• short-lived temporary file handling;
• incident response procedures;
• controlled production access;
• infrastructure provider redundancy where configured.

These design goals do not guarantee uninterrupted service.

4. No general SLA at launch

Unless expressly stated in a separate written agreement, Squillify does not provide a contractual uptime commitment, service credit, financial remedy, or penalty for downtime.

Any availability targets shown in documentation, dashboards, sales materials, or public pages are operational goals unless expressly identified as contractual commitments.

Formal SLA commitments may be offered only for specific paid plans, enterprise plans, or written agreements.

5. Availability targets

Where Squillify publishes a general availability target, that target is an operational objective and not a binding service level unless expressly stated otherwise.

Any binding SLA must specify at least:

• the covered services;
• the availability target;
• the measurement period;
• the calculation method;
• excluded downtime;
• customer obligations;
• service credit or remedy, if any;
• claim process and deadlines;
• maximum credit cap;
• whether the SLA is the exclusive remedy for availability failure.

No such binding SLA applies unless expressly included in the applicable plan, order form, or agreement.

6. Service credits

Service credits are not available unless expressly included in the customer's plan, order form, enterprise agreement, or written contract.

Where service credits apply, they will be the customer's sole and exclusive remedy for the covered availability failure, unless applicable law requires otherwise.

Service credits, if offered, may be subject to:

• timely claim submission;
• account being in good standing;
• exclusion of free, beta, preview, or trial usage;
• exclusion of customer-caused issues;
• exclusion of third-party provider outages outside Squillify's reasonable control;
• maximum monthly or annual caps.

7. Maintenance

Squillify may perform maintenance to improve, secure, repair, update, or operate the platform.

Maintenance may include:

• software deployments;
• database maintenance;
• infrastructure upgrades;
• security patches;
• provider maintenance;
• emergency fixes;
• scaling or reliability improvements;
• dependency updates.

Where planned maintenance is expected to materially affect production availability, Squillify will aim to provide reasonable advance notice through appropriate channels, such as the dashboard, email, documentation, or a status page.

Emergency maintenance may be performed without advance notice where needed to protect the platform, customers, data, infrastructure, security, or legal compliance.

8. Incidents

An incident is an unplanned event that materially affects the availability, reliability, security, integrity, or performance of the Services.

During an incident, Squillify may:

• investigate and triage the issue;
• restrict, throttle, disable, or reroute affected services;
• disable affected capabilities;
• suspend risky traffic;
• prioritise restoration over detailed communication;
• communicate status through appropriate channels;
• provide follow-up information where appropriate.

Incident communications may include:

• affected services;
• known impact;
• mitigation or workaround, if available;
• restoration status;
• post-incident summary, where appropriate.

Squillify does not guarantee a fixed incident response time unless an applicable support plan, SLA, or written agreement expressly provides one.

9. Status communications

Squillify may communicate maintenance, incidents, and service status through one or more of the following channels:

• dashboard notice;
• email notice;
• documentation update;
• support communication;
• public or private status page;
• API response errors;
• developer console notice.

The specific communication channel may depend on the severity, affected customers, operational urgency, and available information.

10. Performance and degradation

Availability is not the same as performance.

Squillify may remain available while experiencing:

• increased latency;
• partial degradation;
• delayed telemetry;
• delayed billing views;
• temporary queueing;
• reduced throughput;
• limited access to specific microskills;
• temporary feature restrictions;
• rate-limit or quota rejections.

Performance targets, latency targets, throughput commitments, or execution-time guarantees apply only if expressly stated in a specific plan, SLA, or written agreement.

11. Rate limits, quotas, and capacity protection

Squillify uses rate limits, quotas, concurrency controls, file limits, execution time limits, and abuse prevention systems to protect platform availability.

Requests may be rejected, throttled, delayed, limited, or blocked where they exceed applicable limits or threaten platform stability.

Such rejections or throttling do not count as downtime where they result from:

• customer plan limits;
• tenant limits;
• API key limits;
• quota exhaustion;
• fair-use enforcement;
• abusive or unsafe traffic;
• unsupported retry behavior;
• customer-side agent loops;
• customer-side automation misconfiguration;
• fraud, abuse, or security controls.

Rate limits and fair use rules are described in the API Usage and Fair Use Policy.

12. File handling and temporary storage

File-based features may depend on temporary file storage, presigned URLs, background cleanup, and provider infrastructure.

Temporary files are designed to be short-lived. Expired temporary files may become unavailable and may return an error such as 410 Gone.

The unavailability of an expired temporary file does not constitute downtime if the file expired according to the File Handling Policy or Data Retention Policy.

13. Third-party dependencies

Squillify may depend on third-party providers for hosting, infrastructure, authentication, payment processing, email, monitoring, storage, database services, or other operational components.

Availability issues caused by third-party providers may affect Squillify. Such issues are excluded from any availability commitment unless the applicable SLA or written agreement expressly says otherwise.

Squillify remains responsible for selecting and managing its providers in accordance with its policies, but Squillify does not guarantee that third-party providers will be uninterrupted or error-free.

14. Exclusions

Unless expressly stated otherwise in a binding SLA, availability commitments exclude downtime, errors, degradation, or unavailability caused by:

• scheduled maintenance;
• emergency maintenance;
• beta, preview, trial, experimental, sandbox, or non-production features;
• customer applications, agents, scripts, integrations, devices, networks, or credentials;
• customer configuration errors;
• customer misuse or violation of the Terms of Service, Acceptable Use Policy, or API Usage and Fair Use Policy;
• API key compromise;
• unauthorised access caused by customer security failures;
• rate limits, quotas, concurrency limits, file limits, execution limits, or fair-use controls;
• free-tier limits or restrictions;
• payment failure, billing suspension, or account suspension;
• force majeure events;
• acts or omissions of third-party providers;
• internet connectivity failures outside Squillify's control;
• DNS, browser, device, operating system, firewall, proxy, VPN, or customer network issues;
• denial-of-service attacks, abuse traffic, malware, fraud, or security incidents;
• lawful suspension, restriction, blocking, or termination;
• customer-requested changes or support actions;
• data deletion or expiry according to retention policies;
• unsupported use, undocumented endpoints, or reverse-engineered behavior.

15. Customer responsibilities

Customers are responsible for designing their use of Squillify in a resilient way.

Customers should:

• implement timeout handling;
• implement retry logic with exponential backoff and jitter;
• avoid uncontrolled retry loops;
• monitor API responses and error codes;
• respect rate limits and quotas;
• scope API keys narrowly;
• rotate compromised keys;
• secure their agents and applications;
• avoid submitting workloads that exceed plan limits;
• maintain fallback behavior for critical workflows;
• monitor their own applications and infrastructure;
• test integrations before production use.

Squillify is not responsible for customer-side failures to handle documented errors, limits, expiry, or degradation.

16. Beta, preview, trial, and free services

Beta, preview, trial, free, experimental, or early-access services are provided on an as-is and best-effort basis.

They may be changed, suspended, limited, discontinued, or removed at any time.

No availability commitment, service credit, support response target, or continuity obligation applies to such services unless expressly stated in writing.

17. Security-related restrictions

Squillify may restrict, suspend, throttle, disable, quarantine, or terminate access where reasonably necessary to protect:

• the platform;
• customers;
• infrastructure;
• sub-processors;
• third parties;
• data;
• security;
• legal compliance;
• service availability.

Such protective actions do not constitute downtime or service unavailability for the affected customer where they are caused by security risk, abuse risk, policy violation, or platform protection needs.

18. Relationship with Support Policy

Support response targets, support channels, and support scope are described in the Support Policy.

Support response targets are not availability commitments unless expressly stated in a binding SLA or written agreement.

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

19. Relationship with Billing and Refund Policy

Service unavailability does not automatically entitle customers to refunds, credits, or billing adjustments.

Refunds, billing adjustments, and credits are governed by the Billing and Refund Policy, the customer's plan, and any applicable written agreement.

Where a binding SLA provides service credits, those service credits apply according to the SLA terms.

20. Changes to this policy

Squillify may update this policy from time to time.

If changes are material, Squillify will provide reasonable notice through appropriate channels, such as the dashboard, website, email, documentation, or other service communications.

Changes do not retroactively create or remove service credits for past periods unless required by law or expressly agreed in writing.

21. Contact

For service availability questions, contact:

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

For abuse or traffic-related concerns, contact [email protected].