Service Level Commitment

Last reviewed 2026-09-27. Served live at /legal/sla.

This is the public commitment for eudr.dev, operated by Vortx AI Private Limited.

This commitment is informational. It does not, by itself, create a contractual service-level obligation enforceable beyond the service-credit schedule below. The service credit is the Customer's sole and exclusive remedy for any unavailability of the hosted service. The Provider does not commit to specific uptime, throughput or latency outside the schedule below.

1. Scope

This commitment covers:

• the public A2A surface (/.well-known/agent-card.json, /a2a/message/send, /a2a/tasks/, /a2a/tasks//events),
• the authenticated dashboard at /app,
• the receipt verifier (/verify, /api/verify_receipt).

It does not cover:

• planned maintenance windows announced ≥ 24 hours in advance (typically Sunday 02:00–04:00 UTC, capped at one window per month in normal operations);
• third-party dependencies (emem.dev, Razorpay, TRACES NT, AWS region-wide outages) — but the Provider will document upstream incidents in the status log;
• account-specific issues caused by the Customer (rate-limit exceedance, expired payment method, sanctions screen flag, etc.).

2. Availability target

Pre-launch placeholder. The numeric target on this page is set by the Provider before the hosted service opens for billing customers. Until then this commitment is informational. Email avijeet@vortx.ai to ask for the current operational posture.

The intent at general availability is a rolling-30-day uptime target in the 99.0–99.5 % range, reflecting an early-stage hosted service running on a single AWS EC2 instance in eu-north-1 (Stockholm, Sweden), with the primary SQLite store on that instance. It will tighten as the operational footprint hardens.

3. Measurement

Availability is measured every minute from an external prober that performs:

• GET /api/health (must return HTTP 200 within 5 seconds), and
• GET /.well-known/agent-card.json (must return HTTP 200 with a valid signature within 5 seconds).

Two consecutive failures count as a one-minute outage. Downtime during announced maintenance windows is excluded. Downtime caused by a Customer-side issue (auth, rate limit, AUP breach, etc.) is excluded.

A formal status-page service is on the roadmap but is not yet wired. Until it ships, planned-maintenance notices and incident updates are sent to the account email on file — the same status channel referenced in the Terms.

4. Service credits

Pre-launch placeholder — the credit schedule below is the Provider's drafting intent and will be finalised before the hosted service opens for billing customers.

If monthly availability falls below the target, the Customer may request a service credit against the next billing cycle. Indicative schedule:

Credits are issued against the next billing cycle's hosted-service fees. They are not paid out as cash. Credits cap at the fees paid in the affected month.

To request a credit, email avijeet@vortx.ai within 30 days of the affected window, including the approximate downtime period.

5. Severity-1 response

A "Severity 1" event is a confirmed outage of the in-scope endpoints where no Customer can compile a DDS.

Pre-launch placeholder — the response-time matrix below reflects the Provider's operational intent and will be finalised before the hosted service opens for billing customers.

The Provider aims to: acknowledge confirmed customer reports within one business hour, publish a status update on the same channel, work on a partial workaround or restore as the first engineering priority, restore full service before the end of the same business day, and publish a brief post-incident review within one business week. These are response targets, not warranties.

6. Restore-from-backup commitment

The primary SQLite store is snapshotted every hour, with each snapshot integrity-checked. Hourly snapshots are kept for 48 hours and one a day for 30 days. The recovery point is therefore at most one hour. A restore from a snapshot on the same host targets ≤ 30 minutes.

The snapshots are on the same host as the database. They protect against a faulty change or a corrupted write, not against losing the instance; off-site copies are not yet in place. Customers who need a stronger recovery commitment should ask before relying on this one.

7. Backup, encryption, and residency

• All persistent data is stored in eu-north-1 (Stockholm, Sweden).
• Transactional email is sent from eu-north-1 (Stockholm, Sweden) via AWS SES.
• Encryption in transit: TLS only, terminated on the host; HSTS for two years with preload.
• Per-deployment signing keys (ed25519, 32-byte) are stored outside the runtime image; the boot guard refuses to start with the deterministic dev key over HTTPS.

8. What is out of scope

The Provider does not guarantee:

• the contents of third-party signed receipts (emem.dev fact CIDs, TRACES NT submission references). Those derive their own integrity from their own signers and verification surfaces.
• the lawful basis of the Customer's processing under GDPR. That is the Customer's responsibility.
• the timeliness of upstream regulatory data (country tier table under Implementing Reg. (EU) 2025/1093 refreshes). The engine logs a warning when the table is older than 180 days; operators should cross-reference the latest EUR-Lex publication for production use.

9. Contact

Status questions, incident reports, credit requests: avijeet@vortx.ai.

Provider: Vortx AI Private Limited (see Imprint).

This page last changed on 2026-09-27. It describes the Regulation as it stood then; where a date or a code matters to a decision, check it against the EUR-Lex text it cites.