LegalX Yapay Zeka Teknolojileri A.Ş.
APY Tekmer, Ataşehir Bulvarı, Atatürk, Ertuğrul Gazi Sk. D:2 Blok No:13, 34758 Ataşehir/İstanbul, Türkiye
This SLA is an appendix to the Terms of Service and applies to the Harmonity cloud service (the “Service”).
| The Legal Text | In Plain English |
|---|---|
| 1.1 Appendix. This Service Level Agreement (“SLA”) forms part of the Agreement between you (“Customer”) and LegalX Yapay Zeka Teknolojileri A.Ş. (“Provider”, “we”, “us”). Capitalized terms not defined here have the meaning in the Terms of Service or Order Form. | This SLA is an add-on to the main contract you sign with us. |
| 1.2 Applicability. This SLA applies to the Service identified in the applicable Order Form. If you purchase an enhanced support offering (if any) described in the Order Form (“Premium Support”), the response targets in Section 4 may be improved as stated in that Order Form. | Everyone gets the baseline SLA. If you buy Premium Support, you may get faster response targets. |
| 1.3 What we cover (and what we don’t). This SLA intentionally includes (i) clear availability measurement and formula, (ii) a severity/response table, (iii) planned maintenance rules and notice, and (iv) service credits and claim mechanics. This SLA intentionally does not measure downtime only during business hours, and does not start downtime only when the Customer reports an incident. | We kept the best enterprise parts (clear uptime, severity table, maintenance, credits). We avoided the parts that can feel unfair (only counting downtime in business hours or only after you report it). |
| The Legal Text | In Plain English |
|---|---|
| 2.1 Business Hours. Unless otherwise stated in the Order Form, “Business Hours” means 09:00–18:00 Europe/Istanbul, Monday–Friday, excluding official public holidays in Türkiye. | Our standard support targets run during Istanbul business hours (unless you bought Premium Support). |
| 2.2 Availability. “Availability” means the Service is operational and materially accessible by the Customer over the public internet in a manner consistent with the Service’s normal operation. | “Up” means the app is basically usable. |
| 2.3 Downtime. “Downtime” means a period in which the Service is not Available, as determined by Provider’s reasonable monitoring and/or logs, excluding the items in Section 3. | Downtime counts when the service is actually down, based on monitoring/logs (with standard exclusions). |
| 2.4 Monthly Measurement Period. Availability is measured per calendar month. | We calculate uptime each month. |
| 2.5 Response Time. “Response Time” means the time from when we receive a properly submitted ticket to when we begin troubleshooting (not merely an automated reply). | Response time means “we started working on it,” not just “we answered.” |
| 2.6 Workaround / Restoration. An incident is considered restored when we (a) resolve the root cause, or (b) provide a commercially reasonable workaround that restores material functionality, and notify Customer. | If we give you a real workaround that gets you unstuck, we treat the incident as restored. |
| The Legal Text | In Plain English |
|---|---|
| 3.1 Uptime Commitment. We will use commercially reasonable efforts to achieve 99.9% Availability of the Service during each Monthly Measurement Period. | Target uptime is 99.9% each month. |
| 3.2 Availability Calculation. Availability (%) = 100 × ((Total Minutes in Month − Downtime Minutes) ÷ Total Minutes in Month). | Simple monthly uptime math. |
| 3.3 Exclusions. Downtime does not include unavailability caused by: (i) planned maintenance under Section 5; (ii) emergency maintenance necessary to address security, safety, or stability; (iii) force majeure events; (iv) Customer’s or Customer’s users’ networks, devices, browsers, or misconfiguration; (v) third-party services outside Provider’s reasonable control (including Customer’s identity provider, payment rails, or Customer-provided integrations); (vi) Customer’s violation of the Agreement; (vii) suspension due to non-payment or legal compliance. | We don’t count downtime caused by things outside our control, your setup, or required suspensions. |
| 3.4 Good-faith measurement. We will measure Availability in good faith using reasonable monitoring, logs, and incident records. Upon request, we will provide a summary of the relevant incident(s) used to calculate Availability for a month. | We’ll be transparent about how we measured uptime for that month. |
| The Legal Text | In Plain English |
|---|---|
| 4.1 How to contact support. Customer may report incidents via email to support@harmonity.ai. Tickets should include: (i) description of issue; (ii) time observed; (iii) affected users; (iv) screenshots/logs if available; (v) business impact; and (vi) suggested severity level. | Email support@harmonity.ai with details so we can move fast. |
| 4.2 Severity classification. Customer may suggest severity; Provider may reclassify based on impact and scope. | You can label severity; we may adjust it to keep things consistent. |
| 4.3 Baseline Response Targets (Business Hours). Response Time targets apply during Business Hours unless Premium Support states otherwise. | Standard response clocks run during business hours (Premium may be 24/7 for critical). |
| 4.4 Premium Support (optional). If the Order Form includes Premium Support, the Order Form may define (i) 24/7 coverage for Sev 1 (and optionally Sev 2), (ii) faster response targets, and (iii) an escalation path. In the event of conflict between this SLA and Premium Support terms in the Order Form, the Order Form controls. | Premium Support (if purchased) can mean 24/7 for critical issues and faster targets. |
| Severity | The Legal Text | In Plain English |
|---|---|---|
| Sev 1 (Critical) | Complete outage or critical failure affecting most users; security incident with active exploitation; data integrity risk with no reasonable workaround. Response Time: 1 hour (Business Hours). | Major outage / emergency. We start within 1 hour (during business hours). |
| Sev 2 (High) | Major feature unusable or severe degradation affecting many users; no reasonable workaround. Response Time: 2 hours (Business Hours). | Big problem for many users. We start within 2 hours (business hours). |
| Sev 3 (Medium) | Partial degradation or bug affecting some users; workaround exists. Response Time: 1 Business Day. | Annoying but not catastrophic. We start within 1 business day. |
| Sev 4 (Low) | General questions, minor issues, requests for guidance or configuration. Response Time: 2 Business Days. | Routine support. We start within 2 business days. |
| The Legal Text | In Plain English |
|---|---|
| 5.1 Planned Maintenance Window. Where reasonably feasible, planned maintenance that may materially affect Availability will be performed between 00:00–04:00 Europe/Istanbul. | We try to do disruptive maintenance at night Istanbul time. |
| 5.2 Advance Notice. We will endeavor to provide at least five (5) days’ advance notice for planned maintenance that is reasonably expected to materially affect Availability. Notice may be provided via email, in-product message, or a status page (if available). | We aim for 5 days’ notice when maintenance could affect uptime. |
| 5.3 Emergency Maintenance. We may perform emergency maintenance at any time to address security, stability, legal compliance, or urgent risk. Such maintenance is excluded from Downtime to the extent reasonably necessary. | Emergencies happen; we may act immediately to keep the system safe. |
| The Legal Text | In Plain English |
|---|---|
| 6.1 Sole and Exclusive Remedy. If we fail to meet the Availability commitment in Section 3.1, Customer’s sole and exclusive remedy is to receive Service Credits as described in this Section 6. | If uptime misses the target, the remedy is credits (not cash damages). |
| 6.2 Credit Calculation Basis. Service Credits are calculated as a percentage of the monthly subscription fee for the affected Service. If Customer pays annually, the monthly fee is calculated as (annual subscription fee ÷ 12). Credits do not apply to one-time services, professional services, taxes, or pass-through fees unless the Order Form states otherwise. | Annual plans are prorated to a monthly amount for credits. Credits usually apply to subscription only. |
| 6.3 Credit Tiers. Service Credits will be issued according to Table B for the applicable month. | The lower the uptime, the bigger the credit. |
| 6.4 Credit Limits. Service Credits (i) are non-refundable, (ii) are not redeemable for cash, (iii) are non-transferable, (iv) may only be applied as an offset against future subscription invoices, and (v) will not exceed the monthly subscription fee for the affected month. | Credits reduce a future bill; we don’t pay cash. Credits can’t exceed that month’s fee. |
| 6.5 Eligibility. Customer is not eligible for Service Credits if Customer is past due on payment obligations at the time the credit request is made or if the unavailability falls under the exclusions in Section 3.3. | You need to be in good standing and the downtime must be “on us.” |
| Monthly Availability | Service Credit (% of monthly subscription fee) |
|---|---|
| 99.9% to 99.71% | 10% |
| 99.70% to 99.51% | 20% |
| 99.50% to 99.11% | 50% |
| 99.10% to 96.71% | 60% |
| Below 96.70% | 100% |
| The Legal Text | In Plain English |
|---|---|
| 7.1 Credit Request Window. To receive a Service Credit, Customer must submit a written request within sixty (60) days after the end of the month in which the Availability fell below 99.9%. | You have 60 days after that month ends to ask for credits. |
| 7.2 Request Requirements. The request must be sent to support@harmonity.ai and include: (i) Customer name and workspace; (ii) the affected month; (iii) a description of the incident(s); and (iv) any relevant evidence (timestamps, screenshots, logs). | Email us the month + details so we can validate quickly. |
| 7.3 Issuance Timing. If approved, Service Credits will be applied to the next invoice(s) issued after approval or otherwise as reasonably determined by Provider. | If approved, we apply credits to the next bill(s). |
| The Legal Text | In Plain English |
|---|---|
| 8.1 No expansion of liability. This SLA does not expand Provider’s liability beyond the limitations in the Terms of Service and the Order Form. | SLA credits don’t override the liability limits in the contract. |
| 8.2 Changes. We may update this SLA from time to time. Updates will not materially reduce Customer’s rights during an active paid subscription term without notice; however, changes may apply at renewal or as otherwise permitted in the Agreement. | We won’t sneakily downgrade your SLA mid-term without notice. |
| 8.3 Interpretation. Headings are for convenience only. If there is a conflict, the Order Form controls, then the Terms, then this SLA. | If documents conflict: Order Form wins, then Terms, then SLA. |
| The Legal Text | In Plain English |
|---|---|
| 10.1 Status Page. Provider maintains a public or customer-accessible service status page (the “Status Page”) describing current Service status, incident summaries, and planned maintenance notices. The Status Page is informational only and does not modify Provider’s obligations under this SLA unless explicitly stated in the Order Form. | We have a status page for transparency. It’s informative, not a separate contract promise. |
| 10.2 Notification Channels. Provider may communicate Service status and incidents via: (i) the Status Page; (ii) email to Customer’s designated notification contacts and/or Authorized Contacts; and (iii) in-product notices or support portal announcements (where available). Customer is responsible for keeping notification contacts current and subscribing to Status Page updates where supported. | We’ll post updates on the status page and may email/in-app notify. You need to keep contacts up to date. |
| 10.3 Incident Declaration. Provider may declare an incident when it determines there is a material Service disruption, security event, or degradation affecting multiple customers or a Customer’s production use. Incidents may be categorized consistent with Severity 1–4 in this SLA, but Provider may use different operational labels on the Status Page (e.g., “Investigating,” “Identified,” “Monitoring,” “Resolved”). | If something serious happens, we’ll “declare an incident” and track it publicly with standard stages. |
| 10.4 Initial Acknowledgement Targets (PSP). For Premium Support customers, Provider will use commercially reasonable efforts to post an initial Status Page update or send an initial notification within: (i) 60 minutes after confirming a Severity 1 incident; and (ii) 2 hours after confirming a Severity 2 incident. These targets are not guarantees and may be delayed where disclosure would increase security risk or violate legal obligations. | For big incidents, we try to acknowledge quickly—unless sharing details would create security/legal risk. |
| 10.5 Update Cadence (PSP). For Premium Support customers, Provider will use commercially reasonable efforts to provide updates during an active incident at approximately the following cadence: (i) Severity 1: at least every 60 minutes; (ii) Severity 2: at least every 4 hours; (iii) Severity 3–4: as reasonably appropriate based on impact. Provider may increase frequency at its discretion. | During an incident, we’ll keep you posted regularly (more often for Sev 1). |
| 10.6 Content of Updates. Incident communications may include: current status, impacted components, known symptoms, mitigation steps/workarounds (if any), and estimated next update time. Provider does not commit to providing an estimated time to resolution. | We’ll share what’s happening and what to do, but we won’t promise exact fix times. |
| 10.7 Customer-Specific Communications. Where an issue affects only Customer (or where details are customer-specific), Provider may communicate primarily through support tickets rather than the Status Page. Such communications may be Confidential Information. | If it’s just your workspace, we’ll handle it in your ticket (more private + detailed). |
| 10.8 Post-Incident Report (PSP). For Severity 1 incidents, upon Customer’s written request, Provider will use commercially reasonable efforts to provide a written incident summary (“Post-Incident Report”) within 10 Business Days after resolution, describing: (i) high-level root cause category; (ii) timeline of key events; (iii) mitigation performed; and (iv) corrective actions planned. Post-Incident Reports may omit sensitive security details and may be shared in aggregated form if multiple customers were affected. | For Sev 1, you can request a postmortem-style summary. We’ll share meaningful learnings without exposing sensitive security info. |
| 10.9 Planned Maintenance Notices. Provider may perform planned maintenance, updates, and releases. Where planned maintenance is reasonably expected to materially affect availability, Provider will use commercially reasonable efforts to: (i) schedule work during off-hours where feasible; and (ii) provide at least five (5) Business Days prior notice via the Status Page and/or email. Emergency maintenance may be performed with as much notice as practicable. | We try to do maintenance off-hours and give ~5 business days notice. Emergencies can happen with short notice. |
| 10.10 Maintenance Windows (Optional). If stated in the Order Form, Provider will maintain a standard maintenance window (e.g., weekday late-night hours in the agreed time zone). If not stated, Provider may choose reasonable windows based on operational needs. | If you want a defined maintenance window, we can put it in the Order Form. |
| 10.11 Service Credits & Uptime Measurements. Status Page postings and incident communications do not determine whether downtime qualifies as “Unavailable Time” under the SLA or whether service credits apply. Uptime and credits (if any) are calculated solely in accordance with the SLA’s Availability and Service Credit terms. | The status page is not the official “credit calculator.” SLA rules decide that. |
| 10.12 Language. Unless otherwise agreed in the Order Form, Provider may issue Status Page updates and incident communications in English. | By default, updates are in English (we can change per contract). |
| 10.13 Subscribing to Updates. Where supported, Customer may subscribe to Status Page notifications (e.g., email, RSS/Atom feed, webhook, or similar mechanisms) by following the instructions made available on the Status Page. Subscription availability and formats may change over time. | If the status page supports it, you can subscribe (email/RSS/webhook). The exact options may change. |
| 10.14 Customer Configuration. Customer is responsible for configuring its systems and filters to receive Status Page notifications (including allowlisting domains, checking spam filtering, and maintaining valid recipients). Provider is not responsible for missed notifications due to Customer-side filtering, misconfiguration, or third-party delivery failures. | If your email/security tools block the notifications, that’s on you—please configure allowlists/recipients. |
| 10.15 Dedicated Notification Contacts (PSP). For Premium Support customers, Customer may designate up to two (2) incident-notification email addresses (or distribution lists) for operational alerts, in addition to support ticket communications. Provider will use commercially reasonable efforts to send Severity 1–2 incident notifications to such contacts when an incident is confirmed. | Premium customers can give us 2 alert addresses (e.g., ops@ / oncall@). We’ll notify them for Sev 1–2. |
| 10.16 Webhooks and Integrations. If Provider offers webhook endpoints or third-party integrations for Status Page notifications, Customer’s use is subject to Provider documentation and any applicable third-party terms. Provider does not guarantee uninterrupted delivery via third-party platforms. | If we offer webhooks/Slack/PagerDuty/etc., they’re “best effort” and depend on third parties too. |
If there’s any question, please email support@harmonity.ai support@harmonity.ai