SLA
Q-Trust Plane — Service Level Agreement
Document: SLA (Enterprise SaaS, Closed-Source)
Version: 1.0
Applies to: Hosted SaaS & Dedicated Tenant Deployments
1. Purpose
This Service Level Agreement (SLA) defines the availability, reliability, responsibilities, and limitations of the Q-Trust Plane service.
Q-Trust Plane is a security-critical governance control plane.
This SLA prioritizes integrity and safety over permissive availability.
2. Service Description
Q-Trust Plane provides:
- authorization decisions for critical actions
- issuance of short-lived cryptographic grants
- evidence ingestion and verification
- on-chain anchoring of audit commitments
- audit proof retrieval
Q-Trust Plane does not execute customer actions and does not replace customer tooling.
3. Availability Commitment
3.1 Core API Availability
| Deployment Model | Monthly Availability |
|---|---|
| Hosted SaaS | 99.5% |
| Dedicated Tenant | 99.9% |
| Private / On-Prem | Best effort (customer-operated) |
Availability applies to:
/v1/authorize/v1/evidence/v1/audit/proof/*
3.2 Planned Maintenance
- Scheduled maintenance windows will be communicated in advance
- Maintenance may temporarily reduce availability
- Emergency maintenance may occur without prior notice for security reasons
4. Security-First Failure Semantics
Q-Trust Plane is designed to fail closed for critical actions.
4.1 Authorization Failures
If the authorization service is unavailable:
- critical actions are denied
- no cached or implicit permissions are granted
4.2 Evidence & Anchoring Failures
If evidence ingestion or anchoring is temporarily unavailable:
- evidence may be queued
- grants requiring anchoring may be withheld
- actions may be blocked until integrity guarantees are restored
Availability never overrides security guarantees.
5. Anchoring Guarantees
5.1 On-Chain Anchoring
- Evidence is anchored using Merkle roots
- Anchoring occurs in discrete epochs (e.g., every 60 seconds)
- Anchoring depends on public blockchain availability
5.2 Blockchain Dependencies
Q-Trust Plane is not responsible for:
- blockchain congestion
- chain halts
- consensus failures
- gas price volatility
Anchoring delays caused by blockchain conditions do not count as SLA violations.
6. Performance Targets (Non-Binding)
Typical performance targets under normal conditions:
| Operation | Target Latency |
|---|---|
| Authorization decision | < 500 ms |
| Grant issuance | < 700 ms |
| Evidence ingestion | < 500 ms |
| Audit proof retrieval | < 1 s |
These are best-effort targets, not guarantees.
7. Incident Classification
7.1 Severity Levels
| Severity | Description |
|---|---|
| Sev-1 | Complete service outage |
| Sev-2 | Partial degradation |
| Sev-3 | Non-critical issue |
| Sev-4 | Informational |
7.2 Response Targets
| Severity | Initial Response |
|---|---|
| Sev-1 | ≤ 1 hour |
| Sev-2 | ≤ 4 hours |
| Sev-3 | ≤ 1 business day |
| Sev-4 | As scheduled |
8. Customer Responsibilities
Customers are responsible for:
- correct policy configuration
- managing approval groups
- maintaining CI/CD hygiene
- securing identity providers
- ensuring correct agent deployment
- monitoring their own execution environments
Misconfiguration by the customer does not constitute a service failure.
9. Exclusions
This SLA does not cover:
- customer-side outages
- CI/CD pipeline failures
- misconfigured policies
- misuse of grants
- blockchain failures
- force majeure events
- attacks outside the control plane
10. Service Credits (If Applicable)
Service credits (if contractually agreed):
- apply only to Hosted SaaS or Dedicated Tenant
- calculated monthly
- capped as defined in customer contract
Credits do not apply if:
- outages were caused by customer misconfiguration
- security incidents required emergency mitigation
- blockchain dependencies were the root cause
11. Support Scope
Support includes:
- platform availability issues
- authorization failures caused by service defects
- anchoring pipeline issues
Support does not include:
- policy design consulting (unless contracted)
- customer CI/CD debugging
- smart contract debugging
- blockchain transaction debugging
12. Change Management
- SLA terms may evolve
- material changes communicated in advance
- continued use constitutes acceptance
13. Legal & Contractual Priority
This SLA:
- complements the main service agreement
- does not override security requirements
- does not imply liability beyond contractual terms
14. Summary
Q-Trust Plane provides high-assurance governance, not permissive availability.
Customers adopting Q-Trust Plane accept that:
- some actions may be blocked for safety
- integrity is prioritized over uptime
- cryptographic proof matters more than speed
A secure system that is occasionally unavailable
is preferable to an available system that cannot be trusted.