Service Level Agreement (SLA)

The purpose of this SLA is to establish the framework under which Asiyst may provide service availability commitments for eligible Services.

This SLA addresses:

• Covered Services.
• Availability measurement.
• Service interruptions.
• Scheduled maintenance.
• Service credits.
• Incident handling.
• Exclusions.
• Customer responsibilities.
• Third-party dependencies.
• SLA claims.

This SLA applies only where:

• The applicable Asiyst plan expressly includes an SLA.
• A written agreement incorporates this SLA.
• Asiyst expressly identifies the customer's Service as SLA-covered.

If an SLA is not applicable to the customer's account or agreement, the Service Availability / Status Policy governs general availability information.

The specific Services covered by an SLA are determined by the applicable order, plan, subscription, or written agreement.

Covered Services may include, where expressly identified:

• Asiyst APIs.
• Production application services.
• AI-related infrastructure.
• Other designated production Services.

Individual features, beta functionality, third-party services, or unsupported components may not be covered.

For an eligible Service, Asiyst may provide a defined availability commitment as stated in the applicable commercial agreement or service documentation.

The applicable agreement controls the actual availability percentage or commitment.

No availability percentage should be inferred from this general SLA where no specific commitment has been stated.

Where availability is measured monthly, the measurement period will generally correspond to a calendar month unless the applicable agreement specifies a different period.

The applicable agreement may define a different measurement period for a particular Service.

Availability may be calculated based on the applicable Service's ability to respond successfully to qualifying requests or remain accessible according to the measurement methodology specified for that Service.

The precise measurement method may differ between Services.

A qualifying service failure may include an outage or material interruption that satisfies the measurement requirements of the applicable SLA.

Not every failed request constitutes SLA downtime.

Individual request failures caused by customer configuration, invalid requests, rate limits, or third-party dependencies may be excluded.

For purposes of an applicable SLA, downtime means a period during which a covered Service is unavailable according to the applicable measurement methodology.

Downtime may be measured differently depending on the Service architecture.

A partial outage may qualify for SLA purposes only if it satisfies the applicable measurement criteria.

An outage affecting a non-covered feature does not necessarily constitute downtime for the covered Service.

Reduced performance does not automatically constitute downtime.

Where an SLA specifically covers performance thresholds, those thresholds will be governed by the applicable agreement.

Scheduled maintenance is generally excluded from downtime calculations where the applicable SLA permits such exclusion.

Scheduled maintenance may be announced through:

• Status pages.
• Email.
• Dashboard notifications.
• Other appropriate communication channels.

Emergency maintenance may be excluded from SLA calculations where reasonably necessary to:

• Protect security.
• Prevent data loss.
• Address critical vulnerabilities.
• Restore system stability.
• Respond to a serious operational event.

The applicable agreement determines whether a particular emergency maintenance event is excluded.

Temporary restrictions imposed to protect the Services from:

• Security attacks.
• Credential compromise.
• Fraud.
• Malicious traffic.
• Vulnerability exploitation.
• Other security threats.

may be excluded from SLA calculations where permitted by the applicable agreement.

Downtime caused by the customer's systems, configuration, application, credentials, network, or actions may be excluded from SLA calculations.

Examples include:

• Incorrect API credentials.
• Invalid configuration.
• Customer-side firewall restrictions.
• Customer application failures.
• Unsupported integrations.
• Customer-caused traffic overload.

Asiyst may rely on third-party services and infrastructure.

Third-party failures may be excluded from SLA calculations where the applicable agreement provides such an exclusion.

Third-party dependencies may include:

• Cloud infrastructure.
• AI providers.
• Payment providers.
• Authentication providers.
• Networking providers.
• Storage providers.
• Email providers.
• Other infrastructure or service providers.

Failures of the public Internet, telecommunications providers, customer networks, DNS services, or other infrastructure outside Asiyst's reasonable control may be excluded.

Events outside Asiyst's reasonable control may be excluded from SLA calculations.

Such events may include:

• Natural disasters.
• War.
• Civil disturbances.
• Government actions.
• Widespread telecommunications failures.
• Major Internet disruptions.
• Large-scale cybersecurity events.
• Infrastructure failures outside Asiyst's control.
• Other extraordinary events.

Beta, preview, alpha, experimental, or otherwise non-production Services are generally excluded from SLA commitments unless expressly stated otherwise.

Services used outside documented or supported configurations may be excluded from SLA calculations.

Unsupported configurations may include:

• Deprecated API versions.
• Modified or unsupported SDK implementations.
• Unsupported browsers.
• Unsupported infrastructure configurations.
• Unauthorized integrations.
• Circumvention of documented technical controls.

Service restrictions resulting from violations of:

• Terms of Service.
• Acceptable Use Policy.
• AI Usage Policy.
• API Terms.
• Developer Terms.
• Security requirements.

may be excluded from SLA calculations.

Requests rejected because of applicable rate limits do not necessarily constitute downtime.

Customers are responsible for designing applications to operate within applicable limits.

Service interruptions caused by exceeding documented or contractual resource limits may be excluded.

Resource limits may include:

• API requests.
• Storage.
• File size.
• Processing capacity.
• AI usage.
• Concurrent requests.
• Other technical limits.

Failures resulting from invalid, expired, revoked, or improperly configured credentials generally do not constitute SLA downtime.

Failures occurring inside a customer's application or deployment do not constitute Asiyst downtime unless the applicable agreement expressly states otherwise.

Failures caused by customer-controlled integrations may be excluded.

This includes situations where an external service connected by the customer:

• Rejects requests.
• Changes its API.
• Becomes unavailable.
• Revokes authorization.
• Exceeds its own limits.

Where Asiyst functionality depends on a third-party AI model provider, provider-level outages or failures may be excluded from the applicable SLA where the agreement permits.

Availability of a particular AI model is not necessarily equivalent to availability of the overall Asiyst Service.

Changes to third-party AI models, model versions, capabilities, limitations, or provider policies do not necessarily constitute SLA downtime.

Where customers connect their own AI provider accounts, availability of those providers is outside Asiyst's direct control.

Failures of customer-selected AI providers may therefore be excluded from applicable SLA calculations.

Payment processing is generally dependent on third-party payment providers.

Payment-provider outages do not necessarily constitute downtime of the covered Asiyst application or API.

If authentication depends on an external identity or authentication provider, provider failures may be excluded where the applicable SLA permits.

Asiyst may publish operational status information through a status page or other communication channel.

Status information may be useful for incident tracking but does not necessarily constitute the contractual measurement of downtime.

A status page may not immediately reflect every incident.

There may be delays between:

• Incident occurrence.
• Detection.
• Investigation.
• Status publication.
• Resolution.

Asiyst may investigate and respond to incidents using its incident-response procedures.

Response may include:

• Detection.
• Assessment.
• Containment.
• Investigation.
• Mitigation.
• Recovery.
• Post-incident review.

Where appropriate, Asiyst may notify affected customers of significant incidents.

Notification may occur through:

• Email.
• Status page.
• Dashboard.
• Other applicable communication channels.

During a significant incident, Asiyst may provide updates as additional information becomes available.

Updates may include:

• Current status.
• Affected Services.
• Mitigation activities.
• Recovery progress.
• Resolution.

Information may remain limited while investigation is ongoing.

Asiyst may use recovery procedures, backups, infrastructure controls, or other measures to restore affected Services.

Recovery times may vary depending on the nature and severity of the incident.

Where an applicable SLA expressly provides service credits, an eligible customer may request the applicable credit following a qualifying SLA failure.

Service credits are generally the primary contractual remedy for failure to meet an availability commitment unless the applicable agreement states otherwise.

Where service credits apply, the applicable agreement or order form will determine:

• Availability threshold.
• Measurement period.
• Credit percentage.
• Credit calculation.
• Maximum credit.
• Claim requirements.

This general SLA does not establish a credit percentage where one has not been expressly specified.

Where applicable, service credits may be subject to a maximum amount or percentage established by the relevant agreement.

Unless otherwise agreed, service credits may be provided as:

• Account credits.
• Credits toward future Services.
• Other remedies expressly specified in the applicable agreement.

Service credits are not necessarily payable as cash.

Service credits are not necessarily applied automatically.

An eligible customer may need to submit a valid claim within the applicable claim period.

An SLA claim should generally include:

• Customer account information.
• Covered Service.
• Relevant incident or outage.
• Applicable measurement period.
• Supporting information.
• Any other information reasonably required to verify eligibility.

A claim must be submitted within the period specified by the applicable SLA or written agreement.

If no separate claim period is specified, Asiyst may require the customer to submit the claim within a reasonable period after the end of the relevant measurement period.

Asiyst may review:

• Service logs.
• Monitoring data.
• Status records.
• Incident records.
• Customer information.
• Third-party provider records.
• Applicable contractual terms.

Asiyst's service records may be used to determine whether an SLA event occurred.

System logs and monitoring information may be used to measure availability.

Where a dispute exists, Asiyst may rely on its reasonably maintained operational records unless otherwise required by the applicable agreement or law.

If a customer disputes an availability measurement, the customer should provide relevant information supporting the dispute.

Asiyst may review the available technical and operational records.

Multiple incidents occurring during the same measurement period may be aggregated according to the applicable SLA methodology.

The applicable agreement controls how overlapping incidents are treated.

If multiple causes affect the same Service at the same time, downtime may not be counted multiple times unless the applicable SLA expressly provides otherwise.

Maintenance performed while responding to an existing incident may be treated according to the incident and maintenance provisions of the applicable agreement.

If some components of a covered Service remain operational while another component is unavailable, the applicable measurement methodology determines whether downtime has occurred.

A regional outage may be treated differently from a platform-wide outage depending on the scope of the applicable SLA.

Services that are unavailable because of legal, regulatory, governmental, or geographic restrictions may be excluded where permitted by the applicable agreement.

Security incidents may require temporary restrictions, isolation, or shutdown of systems.

Where permitted by the applicable SLA, such security-related actions may be excluded from availability calculations.

Customers should provide reasonable cooperation during significant incidents when their systems or configurations may contribute to the problem.

This may include:

• Providing logs.
• Confirming configuration.
• Testing fixes.
• Providing reproduction information.
• Verifying recovery.

Customers remain responsible for monitoring their own applications and integrations.

Asiyst availability does not guarantee successful operation of a customer application built on top of Asiyst.

Customers using APIs should implement appropriate retry behavior where supported.

Retry systems should account for:

• Rate limits.
• Temporary failures.
• Timeouts.
• Duplicate requests.
• Idempotency requirements.

Availability restoration does not necessarily mean that every asynchronous operation will immediately complete.

Some operations may require:

• Reprocessing.
• Synchronization.
• Index rebuilding.
• Queue processing.

Asiyst uses measures intended to protect data integrity.

However, no system can guarantee that data will never be corrupted, lost, or incorrectly processed.

Backups may support recovery from operational or security incidents.

Backup restoration is not necessarily instantaneous and may not restore every system to the exact state existing immediately before an incident.

Where reasonable, Asiyst may provide advance notice of material scheduled maintenance.

Notice may not be provided when immediate action is required to protect security, data, or system stability.

Asiyst may make emergency changes without advance notice when necessary to:

• Address critical security issues.
• Prevent significant data loss.
• Restore service.
• Protect infrastructure.
• Address serious operational problems.

Deprecation or retirement of a Service is not necessarily an SLA outage.

Customers should follow applicable migration or upgrade instructions.

Deprecated API versions may not remain subject to the same availability commitments as supported versions unless expressly stated otherwise.

Features identified as:

• Experimental.
• Beta.
• Preview.
• Alpha.
• Deprecated.
• Unsupported.

may be excluded from SLA coverage.

Documentation may describe supported configurations and operational requirements.

Customers are responsible for following applicable documentation when integrating with Asiyst Services.

Availability commitments may vary according to:

• Subscription plan.
• Customer type.
• Product.
• Service.
• Contract.
• Order form.

Customers should refer to their applicable commercial agreement for the commitments that apply to them.

Enterprise customers may have negotiated SLA provisions.

Where an enterprise agreement conflicts with this general SLA, the enterprise agreement controls to the extent expressly stated.

This SLA supplements the Terms of Service where applicable.

The Terms of Service continue to govern matters not specifically addressed by this SLA.

The Service Availability / Status Policy provides general information about availability and operational status.

This SLA establishes contractual availability commitments only where expressly incorporated into the customer's applicable agreement.

Security events may affect availability.

Security-related obligations are also governed by the Security Policy and Incident Response & Security Breach Policy.

Incident handling and security-breach procedures are described in the Incident Response & Security Breach Policy.

This SLA does not replace those procedures.

Unless expressly provided by applicable law or contract, a customer is not entitled to multiple monetary or service-credit remedies for the same underlying service failure.

Where the applicable agreement specifies service credits as the remedy for failure to meet an SLA commitment, those service credits are the customer's remedy for that SLA failure unless otherwise required by applicable law or expressly agreed in writing.

An SLA commitment for one Service does not create an availability commitment for:

• Other Asiyst Services.
• Third-party services.
• Customer applications.
• Customer infrastructure.
• Unsupported features.
• Beta features.

Asiyst may update this SLA where its Services, infrastructure, commercial arrangements, or operational practices change.

Any contractual SLA commitment already incorporated into a customer's written agreement remains subject to the terms of that agreement.

Questions regarding SLA coverage, availability measurements, service credits, or SLA claims should be submitted through the applicable Asiyst support or account-management contact method.