Service Level Objectives

Know Your Service Levels Before Deployment.

Review our standard service level objectives for availability, support, incident response and recovery—so you can plan enterprise AI operations with clear expectations.

Our responsibilities reflect the deployment environment: Technica AI-operated cloud, your cloud or your own infrastructure. We set out the objectives and scope for each.

This page is organized with reference to the Ministry of Economy, Trade and Industry (METI) publications “SLA Guideline for SaaS” and “Cloud Service Level Checklist.” We can also review service-level questionnaires provided by your organization or its customers. These references do not constitute independent certification or approval.

Positioning

Published Objectives, Not a Contractual SLA.

The figures and arrangements below describe our standard operating targets for evaluation and planning. They are not service guarantees or binding service-level commitments unless expressly included in an agreement.

Where a signed agreement or service-level agreement (SLA) specifies different requirements, responsibilities, exclusions, or remedies, those agreed terms take precedence.

Published Service Objectives

Our baseline approach and the targets we normally use when discussing deployment and support.

Contract-Specific Service Levels

Agreed in writing for the relevant product, configuration, responsibilities, and operating model.

Published objectives help establish a starting point. Applicable service levels and responsibilities are confirmed in the relevant agreement before operation begins.

Deployment Models

Responsibilities Depend on the Deployment Model.

Our solutions can be deployed under three operating models. Availability measurement, monitoring, backups, and recovery responsibilities depend on the environment and the agreed division of work.

Operated by Technica AI

We manage the application and its cloud hosting arrangements. The published availability, monitoring, and backup objectives apply to this model, subject to stated exclusions and the agreed service scope.

Client Cloud

We deploy the application in your cloud account. Your cloud arrangements govern the underlying infrastructure; application-level monitoring, incident response, and any availability commitments are defined in the project agreement and depend on the access provided.

On-Premises / Closed Network

The system runs within your facilities or restricted network. Our default uptime objective does not apply because operational access and monitoring may be limited. Support for incidents, software fixes, and recovery is provided within the agreed scope.

Item	A. Operated by Technica AI	B. Client cloud	C. On-premises / closed network
Uptime target	Standard objective applies	Application-level scope, if agreed	No standard uptime objective
Incident intake and initial response	Within standard support scope	Within agreed support scope	Within agreed support scope
Provision of software fixes	Within support scope	Within agreed support scope	Within agreed support scope
Monitoring	Performed by us	Agreed at the design stage	Performed by you (procedures provided by us)
Backup	Performed by us	Agreed at the design stage	Performed by you (procedures provided by us)
Recovery work	Performed by us	Performed by us where access and scope are agreed	Performed by you, with support as agreed

Deployment regions, operational access, and any Japan-only data-location requirements are confirmed for each project. See our Information Security page for related controls.

Availability

Availability Targets and Measurement.

These are standard objectives for model A, where Technica AI operates the service. Application-level targets for model B require separate agreement. The standard uptime objective does not apply to model C.

Service hours
The service is intended to be available 24 hours a day, 365 days a year, apart from scheduled maintenance, emergency maintenance, and applicable exclusions described below. These are service availability hours, not staffed support hours.
Monthly uptime target
99.0% per calendar month for model A, excluding scheduled and emergency maintenance windows and other applicable exclusions. This is an objective, not a guaranteed minimum.
How uptime is calculated
A qualifying outage is a period of at least five consecutive minutes during which the production service is unavailable within the measured scope. A security incident categorized as “Critical” does not count as downtime unless it also interrupts service availability. Monthly uptime (%) = (eligible service minutes − qualifying downtime minutes) ÷ eligible service minutes × 100. Eligible minutes exclude scheduled and emergency maintenance windows and other excluded periods expressly agreed for the service.
Concurrent use
Our standard planning guideline is 100 concurrent sessions per tenant, not a guaranteed capacity for every workload. Sustained excessive use may be subject to traffic controls to protect service stability. Higher concurrency is evaluated and sized for each engagement.
Monitoring
For our managed service, availability, network conditions, and performance indicators—including applicable generative AI API responses—are checked at approximately five-minute intervals, with alerts for detected anomalies. Monitoring coverage depends on the components included in the managed service.
Supported environment
Current Windows and macOS releases with current Google Chrome or Microsoft Edge versions are the standard supported combination. Internet Explorer mode is not supported. The interface is designed for a screen width of at least 1280 px at 100% browser zoom.

Maintenance

Planned Changes and Emergency Maintenance.

Scheduled maintenance
We aim to provide at least five business days’ notice and normally schedule work outside standard business hours in Japan. The expected timing and impact are communicated through the notification channels below.
Emergency maintenance
Urgent security or stability issues may require maintenance without prior notice. We provide information as soon as reasonably practicable and explain the impact and actions taken once the immediate issue is addressed.
Notification method
Email to designated administrators and, where available, in-service notices.
Version upgrades
We release product updates and improvements periodically. For changes expected to affect business operations or integration points, we aim to provide advance notice and relevant release information.
Language model updates and retirement
External AI providers may change or retire models on schedules outside our control. When we become aware of a material impact, we assess available alternatives and inform affected clients as early as practicable; advance notice may not always be possible.

Support

Support Channels and Coverage Hours.

Support hours
Monday to Friday, 9:00 a.m.–5:00 p.m. Japan Standard Time (JST), excluding Japanese public holidays, year-end/New Year closures, and announced company holidays.
Channels
Email and the designated contact form. Where applicable, emergency contact procedures are provided in the service agreement or at onboarding.
Languages
Japanese and English
Scope of support
Support covers incident reports, usage questions, and configuration guidance within the contracted service. New features, additional development, and substantial customization are scoped and quoted separately.
Outside support hours
Reports can be submitted by email at any time; routine acknowledgment and handling normally begin in the next support window. For monitored model A services, a Critical alert detected automatically may trigger out-of-hours investigation. This does not establish a one-hour, 24/7 response guarantee; any contracted out-of-hours response target is agreed separately.

Incident Severity

Incident Severity and Initial Response Targets.

Shared severity definitions help teams prioritize incidents consistently. The targets below describe initial acknowledgment and investigation during standard support hours; recovery times are assessed separately.

Level	Condition	Initial response target	Reporting method
Critical	A complete service outage or a suspected serious security incident requiring urgent attention. Security incidents are assessed separately from availability downtime.	Within 1 hour during support hours	Phone or web meeting, and email
High	Major functions are unavailable or materially impaired and no practical workaround is available.	Within 4 hours during support hours	Email (web meeting if needed)
Medium	Some functions do not operate as intended, but a practical workaround is available.	Within 1 business day	Email
Low	Minor defects with limited operational impact, cosmetic issues, or routine usage questions.	Within 3 business days	Email

“Initial response” means acknowledging a reported incident and starting triage; it does not mean resolution or recovery. For requests received outside support hours, the standard response clock starts at the next support window. An automatically detected Critical event in a monitored environment may be investigated earlier as described above. Recovery estimates are provided when sufficient information is available.

Suspected information-security incidents are also managed under our incident-response procedures. See Information Security.

Backup & Recovery

Backup Coverage and Recovery Objectives.

The following are the standard arrangements for model A. For model B, backup ownership, schedules, storage and restoration access are agreed during design. For model C, clients normally operate backups using procedures agreed with our team.

Backup frequency
Daily backups are the standard objective for managed deployments.
What is backed up
The standard scope includes daily full backups of the database, registered documents and settings, and applicable access and operation logs (including question-and-answer logs). Search indexes are generally rebuilt from source documents rather than restored directly. The precise backup schedule and coverage are confirmed for each deployment.
Retention period
Standard targets: database backup retention of 14 days; log retention of 90 days. Log retention does not necessarily mean that every log is included in each daily database backup.
Recovery point objective (RPO)
Target: recovery from the latest successful daily backup, with a data-loss window of up to 24 hours under normal backup operation.
Recovery time objective (RTO)
Target: within 24 hours after restoration work begins, subject to backup integrity, required environment access, and the nature of the incident. This is not a promise of restoration within 24 hours of initial incident detection.
Access to backups
Backup access is limited to authorized infrastructure and operations personnel with a defined business need.

Out of Scope

Scope Limits and Exclusions.

The following circumstances may fall outside the published objectives, depending on the deployment model, root cause, and agreed responsibilities. Contractual exclusions and remedies, if any, are determined by the applicable agreement.

Issues Caused by Your Environment

Outages attributable to client-managed networks, endpoints, identity systems, or other infrastructure, including changes outside our agreed control.

Issues Caused by Third-Party Services

Disruptions or material changes to external cloud or AI services beyond our direct control, to the extent these dependencies are excluded by the applicable service scope. Responsibilities for providers used in our managed service should be confirmed in the agreement.

Force Majeure

Natural disasters, widespread telecommunications failures, and other events beyond reasonable control, to the extent recognized under the applicable agreement.

Generative AI output
Availability and support objectives do not guarantee the accuracy, completeness, or consistency of individual AI-generated answers. Requirements for answer quality, evaluation, and acceptance are defined separately for each solution. Evidence display and access controls depend on the product and configuration.
Downtime agreed by you
Approved service interruptions for maintenance, migration, or testing are excluded from availability measurement as defined in the agreed service scope.

General

Service Credits, Delivery Arrangements, and Updates.

Service credits
The published objectives do not create an automatic entitlement to a refund, fee reduction, or service credit. Any such remedy is governed by the applicable contract.
Subcontracting
Operational work is normally performed by personnel of Technica AI Inc. and Technica Co., Ltd. External infrastructure, hosting, and AI service providers may also support the technical environment under their respective arrangements. Project-specific subcontracting terms, where applicable, are agreed with clients.
Revisions to this policy
We may revise these published objectives to reflect changes in our services and operating practices. We will update the revision date and, where reasonably practicable, notify affected clients in advance of material operational changes. Revisions do not replace service levels already agreed in a signed contract.
Established / last revised
October 1, 2026

Service Level Consultation

Discuss Your Service Requirements.

Tell us about your deployment model, operational hours, incident priorities, and recovery requirements. We can review the appropriate service-level arrangements and your procurement or security checklist before you finalize an agreement.

Discuss Service Levels Information Security