Service Level Agreement

2. Scope & Applicability

This SLA applies to the Avigrah-managed infrastructure layer: API availability, pipeline orchestration, data storage, and the operator dashboard. It governs infrastructure Avigrah operates directly.

It does not govern the availability or output quality of third-party AI model providers (e.g. underlying LLM inference APIs) invoked by a deployment. Those dependencies are covered by the relevant provider's own SLA, and are disclosed to the Client during system design.

3. Service Availability

Avigrah is engineered to target high service Availability. Because deployment architecture varies by engagement — from single-instance deployments to redundant, multi-region infrastructure — the specific Availability objective for a given environment is agreed during onboarding and documented in the Client's Master Service Agreement.

Where a specific Availability target is agreed, it is calculated as: (total minutes in month − Downtime minutes) / total minutes in month × 100. Scheduled Maintenance (Section 7) and Excluded Events (Section 10) are not counted as Downtime.

4. Support Tiers & Response Times

Support tier is determined by engagement structure (see Pricing). The response times below are targets, measured from ticket creation or incident detection to first human response — not contractual guarantees unless stated otherwise in the MSA.

5. Incident Severity Classification

• Sev 1 (Critical): Core environment is fully unavailable, or a production pipeline critical to business operations has stopped executing entirely.
• Sev 2 (Major): Significant degradation — elevated latency, partial pipeline failures, or a major feature is unavailable, but the Service is still operating.
• Sev 3 (Minor): Limited-impact issue affecting a single non-critical workflow or a cosmetic/dashboard defect.
• Sev 4 (General): Questions, configuration requests, or feature guidance with no operational impact.

6. Escalation Path

If a response time target in Section 4 is missed, the Client may escalate directly to the assigned engagement lead. Enterprise-tier clients are provided a designated technical contact at contract signing for direct escalation on Sev 1 and Sev 2 incidents.

7. Scheduled Maintenance

Avigrah performs scheduled maintenance outside standard business hours wherever possible. The Client is notified at least 72 hours in advance for maintenance expected to affect Availability, via email and the status channel described in Section 8. Scheduled Maintenance is excluded from Availability calculations.

8. Monitoring & Status Reporting

• Core infrastructure is monitored continuously by automated health checks, with alerts routed to the engineering team for prompt follow-up.
• Priority and Enterprise-tier clients receive incident notifications through their dedicated communication channel as Sev 1/Sev 2 incidents are detected and resolved.
• A monthly Availability report is made available to Enterprise-tier clients on request.

9. Service Remedies

Because engagements are individually scoped — and vary significantly in deployment architecture, contract value, and agreed Availability target — service remedies for a missed Availability or response-time target, including any applicable service credits, are defined in the Client's executed Master Service Agreement rather than fixed here as a single blanket schedule.

10. Exclusions

The following are excluded from Downtime, Availability calculations, and remedy eligibility under Section 9:

• Scheduled Maintenance performed in accordance with Section 7.
• Outages or degraded performance of third-party AI model providers, cloud infrastructure providers, or other Sub-processors outside Avigrah's direct control.
• Issues caused by the Client's own integrations, misconfiguration, or misuse of the Service.
• Force majeure events, including but not limited to natural disasters, internet backbone failures, and government action.
• Beta, preview, or explicitly experimental features not yet part of the general release.

11. Backup & Recovery

Production data is backed up on a rolling basis with a target Recovery Point Objective (RPO) of 24 hours and a target Recovery Time Objective (RTO) of 4 hours for Core environment restoration following a catastrophic failure. Apex (fully sandboxed) environments may be configured with tighter RPO/RTO targets as part of the engagement scope.

12. Change Management

Material changes to a Client's deployed pipelines, integrations, or governance rules are only made on the Client's explicit request or approval, consistent with the access-control model described in the platform's Security documentation. Non-breaking platform updates are deployed continuously; breaking changes to APIs the Client integrates with are communicated at least 30 days in advance.

13. Client Responsibilities

• Provide accurate, up-to-date contact information for incident notifications and escalation.
• Report suspected Incidents promptly through the agreed support channel.
• Maintain the security of Client-side credentials and integrations connecting to the Service.
• Ensure any Client-managed data sources feeding the Service remain available and correctly configured.

14. Term & Review

This SLA remains in effect for the duration of the Client's MSA and is reviewed at each renewal. Either party may propose revised terms — including tier changes or custom availability targets — as part of a scoping or renewal discussion.

15. Governing Law

This SLA is governed by the same jurisdiction and laws stipulated in the Client's Master Service Agreement, ensuring consistency in legal enforcement and interpretation.