Translation for information purposes only. This English version has no contractual value. Only the French version, available at https://arrmesh.ai/fr/legal/sla, is legally binding and prevails before the courts, which have jurisdiction under French law.

Service Level Agreement

This agreement (the “SLA”) forms an integral part of the subscription contract for the ArrMesh service governed by the Terms of Subscription. It sets out the service quality commitments of Atyos SAS (“Atyos”) and the service credits granted in the event of a breach.

1. Scope

1.1. The SLA applies to the Starter, Business and Enterprise Plans. The Free Plan does not benefit from it.

1.2. An Enterprise Order Form may provide for different commitments, which then prevail over this SLA.

2. Definitions

• Valid request: any HTTP request sent to the Service by the Customer, its Users or its applications, whose syntax and parameters comply with the documentation.
• Service error: any HTTP 5xx response returned by the Service to a Valid request. 4xx responses (invalid authentication, malformed request, resource not found, 429 rate limiting due to the Customer exceeding its quotas) are never counted as Service errors.
• Interval: a window of five (5) consecutive minutes.
• Interval availability rate: the percentage of Valid requests in the Interval that did not result in a Service error. An Interval with no traffic is deemed 100% available.
• Monthly availability: the arithmetic mean of the availability rates of all Intervals in a calendar month.
• Scope: one of the three functional subsets of the Service defined in Section 3, each subject to its own commitment.
• Monthly fee: the amount, excluding taxes, of the subscription fee for the month concerned; for an annual subscription, one twelfth (1/12) of the annual amount. Usage-based fees are not included in this base.
• Service credit: a discount granted on a subsequent invoice in the event of a breach of an availability commitment.

3. Availability commitments

3.1. Authentication scope — 99.9%

Coverage: session management, token issuance and renewal, authentication flow configuration — routes POST /login, POST /logout, POST /refresh, GET /auth_config — and the API authoriser, which is on the critical path of all protected requests.

Monthly availability	Cumulative downtime (approx.)	Credit
< 99.9% and ≥ 99.0%	45 min to 7 h 10	10% of the Monthly fee
< 99.0% and ≥ 95.0%	7 h 15 to 36 h	25% of the Monthly fee
< 95.0%	> 36 h	50% of the Monthly fee

3.2. Usage collection scope — 99.9%

Coverage: real-time ingestion of usage events — route POST /consumption.

Downstream event processing (aggregation, usage calculation) is asynchronous and not covered by this commitment; it is subject to the freshness commitment in Section 9.

Monthly availability	Cumulative downtime (approx.)	Credit
< 99.9% and ≥ 99.0%	45 min to 7 h 10	10% of the Monthly fee
< 99.0% and ≥ 95.0%	7 h 15 to 36 h	25% of the Monthly fee
< 95.0%	> 36 h	50% of the Monthly fee

3.3. Application scope — 99.0%

Coverage: all other management features available through the API and the console: organisations, solutions, users, roles, permissions, policies, webhooks, wallets, API keys, tags, licences, applications and usage reporting.

Monthly availability	Cumulative downtime (approx.)	Credit
< 99.0% and ≥ 95.0%	7 h 15 to 36 h	10% of the Monthly fee
< 95.0% and ≥ 90.0%	36 h to 72 h	25% of the Monthly fee
< 90.0%	> 72 h	50% of the Monthly fee

The durations shown are for illustration with regular traffic; only the Monthly availability calculated in accordance with Section 4 is authoritative.

4. Availability measurement

4.1. For each Scope and each Interval:

Interval availability rate = (Valid requests − Service errors) / Valid requests × 100

then:

Monthly availability = mean of the availability rates of all Intervals in the calendar month

4.2. Availability is measured by Atyos using the metrics of the Service's API gateway and functions. The monthly availability report is provided to the Customer upon request.

5. Exclusions

The commitments in Section 3 do not apply to unavailability resulting from:

• scheduled maintenance carried out in accordance with Section 8;
• force majeure within the meaning of the Terms of Subscription;
• a failure of the equipment, networks or internet service providers of the Customer or of third parties acting on its behalf;
• an act or omission of the Customer or its Users (incorrect configuration, deletion of data, use not compliant with the documentation or exceeding quotas);
• a general outage of an underlying AWS service in the region concerned, acknowledged by AWS, provided that Atyos has implemented the continuity measures set out in Section 10;
• an external attack (in particular denial of service) despite the implementation of reasonable protection measures;
• a suspension of the Service in accordance with the Terms of Subscription (in particular for non-payment).

6. Support and incident management

6.1. All support requests, including critical incidents (P1), are submitted exclusively through the support portal https://help.arrmesh.ai, stating their priority. The Customer and its authorised Users have access to this portal.

6.2. Target response and resolution times:

Priority	Description	Response	Target resolution
P1 — Critical	A Scope is unavailable (error rate > 50% for 15 consecutive minutes)	1 hour	4 hours
P2 — Major	Significant degradation of a Scope (error rate > 5% for 30 minutes)	4 business hours	24 business hours
P3 — Minor	Partial degradation, workaround available	1 business day	5 business days
P4 — Information	Question or feature request	2 business days	As scheduled

6.3. Business hours and days are Monday to Friday, 9 am to 6 pm (Paris time), excluding French public holidays. For the Business and Enterprise Plans (24×7 support), P1 incidents are handled 24 hours a day, 7 days a week. For the Starter Plan (9×5 support), all times are counted in business hours.

6.4. Resolution times are targets and do not give rise to service credits.

7. Service credits

7.1. To obtain a credit, the Customer submits a request through the support portal https://help.arrmesh.ai, with the subject “SLA credit request — [Scope] — [month concerned]”, within thirty (30) calendar days after the end of the month concerned, together with the information available to it (timestamps, error messages, request identifiers).

7.2. Atyos confirms or disputes the request within fifteen (15) business days, based on its measurements. An accepted credit is applied to the next invoice; it is not refundable in cash, except at the end of the contract.

7.3. Where a single incident affects several Scopes, only the highest credit is granted. The total credits granted for any given month may not exceed 50% of the Monthly fee.

7.4. Service credits are the Customer's sole compensation for unavailability of the Service, except in the event of gross negligence or wilful misconduct by Atyos. They count towards the liability cap set out in the Terms of Subscription.

8. Maintenance

8.1. Atyos may carry out scheduled maintenance for up to four (4) hours per month, preferably between 10 pm and 6 am (Paris time), after informing the Customer by email at least forty-eight (48) hours in advance.

8.2. Emergency maintenance required to fix a critical security vulnerability may be carried out without notice; the Customer is informed within twenty-four (24) hours at the latest. Such maintenance is taken into account when calculating availability.

9. Usage data freshness

Atyos endeavours to make ingested usage events available in hourly aggregates within two (2) hours under normal operation. In the event of a delay of more than four (4) consecutive hours, Atyos informs the Customer. This commitment is a quality indicator monitored monthly; it does not give rise to service credits.

10. Backup and disaster recovery

10.1. The Service is operated in the primary region eu-west-3 (Paris, France), across multiple availability zones. Persistent data is replicated to the disaster recovery region eu-central-1 (Frankfurt, Germany), which is activated only in the event of a major incident affecting the primary region. The failover decision is made by Atyos's operations team. The regions are given for information purposes and may change under the conditions set out in Section 7.2 of the DPA; the recovery objectives below apply regardless of the disaster recovery region used.

10.2. Recovery objectives in the event of failover to the disaster recovery region:

Data	Mechanism	RPO (maximum data loss)	RTO (recovery time)
Business database	Automatic backups and cross-region replication	< 1 hour	< 4 hours
Usage events	Point-in-time recovery and cross-region backup	< 5 minutes	< 2 hours
Analytics data	Versioning and cross-region replication	< 24 hours	< 4 hours

[Verify that the replication mechanisms actually deployed meet these RPO/RTO targets before publication.]

11. Revision

The SLA may be amended under the conditions set out in the Terms of Subscription (Section 21). Any revision unfavourable to the Customer gives it a right to terminate at no cost.

12. Contacts

• Support, including P1 incidents: https://help.arrmesh.ai
• Atyos SAS — 18a Route de Paris, 67117 Ittenheim, France