Legal Document

Service Level
Agreement

RGX Systems, Inc. — A Delaware Corporation

Effective Date: As specified in the applicable Order Form or as of the date Client first accesses the API Infrastructure, whichever is earlier.

This Service Level Agreement ("SLA") is entered into between RGX Systems, Inc., a Delaware C-Corporation ("RGX Systems"), and the Client identified in the applicable Order Form or Master Services Agreement ("Client"). This SLA is incorporated into and governed by the Master Services Agreement ("MSA") between the parties. Capitalized terms not defined herein have the meanings given in the MSA.

1. Scope and Purpose

This SLA defines the performance commitments, availability targets, logging transparency standards, overage billing mechanics, and remedies applicable to Client's use of the RGX Systems API Infrastructure. This SLA represents RGX Systems' complete commitment with respect to service levels and supersedes any informal representations regarding uptime or performance.

2. Infrastructure Foundation

2.1 Hosting Platform

The RGX Systems API Infrastructure is hosted on Render Pro (render.com), a managed cloud platform providing high-availability deployment across redundant, geographically distributed compute resources. RGX Systems operates its Services on Render's professional-tier infrastructure, which provides:

Automated zero-downtime deployments via rolling release pipelines

Persistent HTTPS endpoints with automated TLS certificate management

Managed PostgreSQL databases with automated daily backups and point-in-time recovery

Distributed routing with automatic failover

DDoS mitigation and edge-level traffic filtering at the platform layer

2.2 Dependency Acknowledgment

Client acknowledges that RGX Systems' ability to meet the performance commitments in this SLA is partly dependent on Render's underlying infrastructure and third-party AI model provider APIs (including but not limited to Anthropic). Outages, degradations, or failures caused by Render's infrastructure or third-party model providers are classified as Excused Outages under Section 4.4 and do not count against RGX Systems' uptime commitments.

3. Service Availability Commitments

3.1 Monthly Uptime Target

RGX Systems commits to the following monthly uptime availability for each Client's VAR Node:

Service TierMonthly Uptime TargetMaximum Allowed Downtime per Month
Standard99.5%~3 hours 39 minutes
Pro (if applicable per Order Form)99.9%~43 minutes

Unless otherwise specified in an Order Form, all VAR Nodes operate at the Standard tier.

3.2 Uptime Calculation

Monthly Uptime Percentage is calculated as:

Uptime % = ((Total Minutes in Month − Downtime Minutes) / Total Minutes in Month) × 100

Downtime is measured from the time a verified incident is opened in RGX Systems' internal monitoring to the time the API Infrastructure resumes normal operation for Client's VAR Node, excluding Excused Outages.

3.3 Measurement Method

Availability is measured via automated synthetic monitoring that performs HTTP health checks against the API Infrastructure at intervals of no greater than five (5) minutes. RGX Systems is the authoritative source for uptime measurements. Clients may request access to the current status dashboard or subscribe to status notifications at RGX Systems' discretion.

4. Downtime Definitions and Exclusions

4.1 "Downtime"

Means any period during which Client's VAR Node is unable to process API requests due to a fault originating within RGX Systems' direct control, resulting in complete API unavailability (HTTP 5xx responses or connection failures) for a continuous period of five (5) or more minutes.

4.2 "Partial Degradation"

Means a condition in which the API Infrastructure is available but operating with elevated latency (exceeding 10 seconds for standard inference requests) or elevated error rates (exceeding 5% of requests returning errors) for a continuous period of fifteen (15) or more minutes. Partial Degradation events are tracked but do not independently trigger SLA credits unless they persist for more than two (2) continuous hours.

4.3 "Scheduled Maintenance"

Means planned maintenance windows of which RGX Systems provides at least forty-eight (48) hours' advance notice. Scheduled Maintenance does not count as Downtime. RGX Systems will use commercially reasonable efforts to schedule maintenance during off-peak hours (02:00–06:00 UTC) and to limit maintenance windows to four (4) hours per month.

4.4 "Excused Outages"

Means periods of unavailability resulting from:

(a) Render platform infrastructure failures, including compute, networking, DNS, or database layer outages attributable to Render's systems;

(b) Third-party AI model provider outages or API degradations (e.g., Anthropic API unavailability);

(c) Client-initiated configuration changes, key rotations, or integration errors;

(d) Client-caused traffic anomalies, including abusive request patterns, malformed payloads at scale, or traffic volumes exceeding the overage thresholds defined in Section 8;

(e) Force majeure events as defined in the MSA;

(f) Internet backbone or transit failures outside RGX Systems' network perimeter;

(g) Distributed denial-of-service attacks targeting Client's VAR Node specifically;

(h) Scheduled Maintenance.

5. Response Time Commitments

5.1 API Latency

RGX Systems targets the following p95 (95th percentile) response times for the API Infrastructure layer, excluding third-party model inference time:

Endpoint Typep95 Target
Authentication / Key Validation< 200ms
Request Routing & Passthrough< 500ms (excluding model latency)
Webhook Processing< 1,000ms
Admin API Endpoints< 2,000ms

Latency targets apply to RGX Systems' infrastructure processing time only. Total end-to-end response time includes third-party model inference, which is outside RGX Systems' control.

5.2 Support Response Times

RGX Systems will acknowledge and triage support requests within the following windows:

SeverityDefinitionInitial ResponseTarget Resolution
P1 — CriticalVAR Node completely unavailable2 business hours8 business hours
P2 — HighSignificant degradation affecting >25% of requests4 business hours24 business hours
P3 — MediumIntermittent errors or non-critical feature issues1 business day5 business days
P4 — LowGeneral inquiries, documentation, billing questions2 business daysBest effort

Support requests must be submitted via the designated channel specified in the applicable Order Form. Response times apply during RGX Systems' business hours (09:00–18:00 ET, Monday–Friday, excluding U.S. federal holidays) unless an enhanced support tier is specified in the Order Form.

6. Data Logging and Transparency

6.1 Infrastructure-Level Logging

RGX Systems maintains the following categories of infrastructure logs for operational and security purposes:

Log TypeData CapturedRetention Period
Access LogsTimestamp, VAR Node ID, HTTP method, endpoint path, response code, response time (ms), IP address30 days
Error LogsTimestamp, VAR Node ID, error type, stack trace (infrastructure layer only)60 days
Authentication LogsTimestamp, key prefix (not full key), auth result, IP address90 days
Billing LogsInvoice ID, period, seat count, amounts, Stripe event IDs7 years (financial compliance)

6.2 Payload Non-Inspection

RGX Systems does not log, store, inspect, or retain the content of Client Data payloads, including:

(a) the body of AI model inference requests or responses;

(b) User Tokens or OAuth credentials submitted in request payloads;

(c) Context Data, conversation history, or session memory objects;

(d) Configuration Arrays or system prompt content.

This commitment reflects both RGX Systems' headless infrastructure model and its obligations under the MSA Section 4. RGX Systems cannot reconstruct, reproduce, or provide discovery of payload content because such content is not retained.

6.3 Log Access

Upon written request, RGX Systems will provide Client with a summary of infrastructure-level access logs pertaining to Client's VAR Node for a specified time period, in a machine-readable format, within ten (10) business days. Log exports are provided at no charge up to twice per calendar year; additional requests are billed at RGX Systems' then-current professional services rate.

6.4 Security Incident Logging

In the event of a security incident affecting Client's VAR Node, RGX Systems will preserve all relevant infrastructure logs for the duration of any investigation and for a minimum of one (1) year thereafter, and will make such logs available to Client and authorized law enforcement upon lawful request.

6.5 Third-Party Provider Logging

Client acknowledges that third-party AI model providers (e.g., Anthropic) may maintain their own logging and data retention practices governed by their independent terms of service. RGX Systems has no control over and assumes no responsibility for third-party provider data practices.

6.6 Audit Rights

Client may, upon thirty (30) days' written notice and no more than once per calendar year, request a written attestation or third-party audit report confirming RGX Systems' compliance with the logging commitments in this Section 6. RGX Systems will cooperate in good faith with reasonable audit requests at Client's expense.

7. Security Standards

7.1 Encryption

RGX Systems implements the following encryption controls:

All data in transit encrypted via TLS 1.2 or higher

API keys stored as SHA-256 hashes; plaintext keys are never retained after initial generation

OAuth tokens and integration credentials encrypted at rest using AES-256-GCM with per-record initialization vectors

Database connections secured via SSL

7.2 Access Controls

Access to production infrastructure is restricted to authorized RGX Systems personnel via multi-factor authentication. Principle of least privilege is applied to all system access.

7.3 Vulnerability Management

RGX Systems maintains a vulnerability management program and will apply critical security patches to the API Infrastructure within seventy-two (72) hours of patch availability, subject to testing requirements.

7.4 Penetration Testing

RGX Systems conducts or commissions penetration testing of the API Infrastructure on an annual basis. Summaries of findings and remediation status are available to Clients upon written request and execution of a mutual NDA.

8. Bandwidth Overage Pass-Through

8.1 Standard Allocation

Each VAR Node is allocated a standard monthly outbound data transfer allowance as specified in the applicable Order Form. Unless otherwise specified, the standard allocation is 50 GB of outbound API traffic per VAR Node per month, which is sufficient for normal multi-tenant AI inference workloads.

8.2 Overage Detection

RGX Systems monitors outbound bandwidth consumption at the VAR Node level. Consumption is measured as total outbound bytes delivered from the API Infrastructure to Client's systems and End Users, including AI model response payloads.

8.3 Overage Pass-Through Billing

Any outbound data egress exceeding the standard monthly allocation — whether resulting from legitimate high-volume usage, misconfigured automated pipelines, API abuse, or traffic anomalies — will be programmatically billed back to Client as follows:

(a) Overage Rate: USD $0.09 per GB (or such other rate as specified in the Order Form) for all egress in excess of the monthly allocation.

(b) Calculation: Overage charges are calculated at the end of each calendar month based on total measured egress. Overage invoices are issued within five (5) business days of month-end and are payable within fourteen (14) days.

(c) No Overage Cap. There is no cap on overage charges. Client acknowledges that runaway automated pipelines, misconfigured clients, or API abuse patterns can generate significant egress, and Client accepts full responsibility for all bandwidth consumed by systems using its VAR Node credentials.

(d) Programmatic Enforcement: For VAR Nodes generating sustained egress at rates exceeding three (3) times the monthly allocation within any rolling seven (7) day period, RGX Systems may, at its sole discretion and without prior notice: (i) apply dynamic rate limiting to the offending VAR Node; (ii) suspend the VAR Node pending Client acknowledgment; or (iii) require Client to prepay estimated overage charges before service resumes. RGX Systems will use commercially reasonable efforts to notify Client promptly when such measures are applied.

8.4 Abuse-Triggered Overages

Bandwidth consumption caused by unauthorized use of Client's API credentials — including credential theft or sharing in violation of the MSA — is Client's financial responsibility. RGX Systems is not liable for overage charges resulting from unauthorized access to Client's VAR Node credentials.

8.5 Overage Disputes

Client may dispute overage charges in good faith by providing written notice within thirty (30) days of invoice date. RGX Systems will provide bandwidth logs supporting the overage calculation within ten (10) business days of a dispute notice. Undisputed portions of overage invoices remain due and payable during dispute resolution.

8.6 Inbound Traffic

Inbound API requests (Client to RGX Systems) are not metered for bandwidth purposes and are not subject to overage charges. Inbound traffic is subject to rate limiting as described in Section 9.

9. Rate Limiting

9.1 Default Rate Limits

To protect infrastructure stability for all tenants, the following default rate limits apply per VAR Node:

Limit TypeDefault Value
Inbound API requests60 requests per minute per IP address
Concurrent connections20 per VAR Node
Maximum request payload size1 MB
Maximum response streaming duration300 seconds

9.2 Custom Limits

Clients requiring higher throughput may request custom rate limit tiers via a written Order Form amendment. Custom limits are subject to availability and may incur additional fees.

9.3 Rate Limit Enforcement

Requests exceeding rate limits receive HTTP 429 responses with a Retry-After header. Sustained rate limit violations may trigger automatic temporary blocks at RGX Systems' discretion to protect multi-tenant infrastructure integrity.

10. SLA Credits

10.1 Credit Eligibility

If RGX Systems fails to meet the Monthly Uptime Target in Section 3.1 in any calendar month (excluding Excused Outages), Client is eligible for service credits as follows:

Monthly Uptime AchievedCredit as % of Monthly Base Fee
99.0% – below SLA target5%
95.0% – 98.9%10%
90.0% – 94.9%20%
Below 90.0%30%

10.2 Credit Request Process

To receive credits, Client must submit a written request within thirty (30) days of the end of the affected month, including: (a) the dates and times of the alleged Downtime; (b) a description of the impact on Client's systems. RGX Systems will review the request against its monitoring records and issue credits within two (2) billing cycles if the claim is validated.

10.3 Exclusive Remedy

Service credits are Client's sole and exclusive remedy for RGX Systems' failure to meet uptime commitments. Credits apply as offsets against future invoices and are not redeemable for cash.

10.4 Credit Cap

Total credits in any calendar month shall not exceed 30% of the monthly Base Infrastructure Fee for the affected VAR Node.

11. Disaster Recovery

11.1 Recovery Objectives

RGX Systems targets the following recovery objectives for full infrastructure failures:

Recovery Time Objective (RTO): 4 hours for full service restoration following a platform-level failure.

Recovery Point Objective (RPO): 24 hours for database state (based on Render's daily automated backup schedule). Transient in-flight requests at the time of failure are not recoverable.

11.2 Backup Verification

RGX Systems tests database restore procedures on a quarterly basis. Results of restore tests are available to Clients upon written request.

11.3 Client Responsibility

Client is responsible for maintaining its own backups of any Client Data it wishes to preserve. RGX Systems' backup infrastructure is intended for service restoration purposes, not as a data archival service for Client Data.

12. Change Management

12.1 API Versioning

RGX Systems will provide a minimum of thirty (30) days' advance notice before making breaking changes to the API surface. Non-breaking additions, performance improvements, and security patches may be deployed without advance notice.

12.2 Deprecation Policy

Deprecated API endpoints or features will remain available for a minimum of ninety (90) days following deprecation notice, unless immediate removal is required for security reasons.

13. General

13.1 Order of Precedence

In the event of a conflict between this SLA and the MSA, the MSA controls, except with respect to uptime commitments and overage billing, which are governed exclusively by this SLA.

13.2 SLA Amendments

RGX Systems may amend this SLA upon thirty (30) days' written notice. Continued use of the Services after the effective date of an amendment constitutes acceptance. If Client does not accept an amendment, Client may terminate this Agreement for convenience under the MSA.

13.3 Applicability

This SLA applies only to the API Infrastructure. It does not apply to: (a) third-party AI model provider availability; (b) Client's own systems or networks; (c) beta or preview features designated as such by RGX Systems.

13.4 Governing Law

This SLA is governed by the laws of the State of Delaware, consistent with the MSA.