Start with your business challenge, then define what to validate, build and operate. Our staged process brings clarity to deliverables, responsibilities and costs as the project takes shape.
This page explains our delivery process, six engagement models and approach to acceptance, intellectual property, change control and estimates. The signed agreement defines the terms for each project and takes precedence over this overview.
For clients in Japan, the contracting entity is normally Technica AI Inc. in Tokyo. We confirm the contracting party, delivery team, and communication arrangements for each engagement.
Where feasibility needs testing, we can start with a proof of concept. We explain the findings and recommend whether to proceed, refine the approach or stop, with production planning as the next step for viable solutions.
Our standard approach is to assign copyright in project-specific custom work, subject to the agreement. Pre-existing products, reusable components, and third-party materials are handled separately.
The nine stages below describe a typical custom AI project. Stages may be combined, reordered, or omitted according to the engagement. Durations are planning guidelines; scope, fees, client inputs, and milestones are confirmed in the proposal or agreement.
Tell us about your business challenge, current workflows, and timeline. We discuss initial feasibility considerations and identify questions that need further investigation.
Before exchanging confidential project documents or data, we agree on appropriate nondisclosure terms. We can review your NDA template and discuss any required changes.
Using approved business documents and sample data, we define the target problem, relevant constraints, and questions to resolve before development.
The proposal sets out the scope, team, schedule, pricing, and assumptions, including client responsibilities and dependencies that affect delivery.
Using approved project data, we evaluate the approach against agreed test items and success criteria. The report records findings and limitations, including targets that were not met.
We define business functions, integration requirements, performance, availability, security, and operational responsibilities, together with the evaluation and test plan.
Regular reviews track progress, decisions, and open issues. Proposed scope changes follow a change-control process, with their impact on effort, schedule, and cost agreed before the changed work begins.
For engagements with deliverable acceptance, you review the work against the test specifications and criteria agreed before development. PoCs and ongoing services use the completion or reporting requirements defined for their engagement.
Support may cover inquiries, incident response, and improvement planning within the agreed scope. Our published Service Level Objectives provide a baseline; any contractual service levels and responsibilities are agreed separately.
A PoC supports a feasibility decision, including a decision not to proceed. We report the findings and limitations. Further evaluation, revised conditions, or production development requires a separately agreed scope and budget.
Substantial requirements definition or technical investigation may be scoped as a separate services engagement. The scope, effort, and fees are agreed before that work begins.
We structure engagements around product deployment, PoC, contract-for-work development, quasi-mandate development, a dedicated team (ODC: offshore development center), or joint research. These are delivery and commercial models, rather than six separate legal categories. In the Japanese contracting context, contract-for-work development focuses on completing agreed work; quasi-mandate engagements focus on performing agreed services. Responsibilities, deliverables, payment, and review arrangements are specified in each agreement. Models can be combined across project phases.
Product licensing with agreed configuration and deployment support
Evaluating feasibility using approved project data
A PoC produces evidence for a decision. Its findings are specific to the evaluated data, conditions, and scope.
Completing defined deliverables against agreed specifications
Developing the solution as requirements evolve
A dedicated development team for an agreed term
Investigating research questions before product development
Answers to the questions we often receive from procurement, legal and IT departments.
For clients in Japan, the contracting entity is normally Technica AI Inc. in Tokyo. We confirm the contracting party, project contacts, and delivery responsibilities in the relevant agreement.
For engagements contracted through Technica AI Inc., personnel from Technica Co., Ltd. in Vietnam may participate in delivery. The role of each company, any subcontracting arrangements, and required client approvals are confirmed for the project. External cloud and AI providers may also support the agreed technical environment.
Confidentiality obligations and responsibility for data handling are defined in the applicable agreements. Storage regions and permitted access locations are agreed separately: hosting in Japan does not by itself prevent access from overseas. Where Japan-only handling is required, the design must address storage, operational access, and external providers.
For development engagements with deliverable acceptance, we agree on evaluation data, test specifications, thresholds, and review procedures before development begins. PoCs and ongoing services use their separately agreed completion and reporting requirements.
Our standard proposed acceptance period is 14 calendar days from delivery. Any deemed-acceptance mechanism applies only under the signed agreement, including its notice requirements and exceptions.
Our standard proposed contract-for-work terms include correction without an additional fee for covered non-conformities reported within one year of delivery. The agreement defines coverage, exclusions, notification procedures, and remedies. Issues involving client instructions or supplied data are assessed against the agreed requirements and responsibilities.
Source code for agreed custom-developed components is normally included in the deliverables listed in the contract. Product source code and reusable components are not automatically included. Ownership, licensing, and any third-party restrictions are confirmed before development.
We do not guarantee the correctness of every individual generative AI output. Results can vary with inputs, model behavior, and the available evidence.
Where contracted development includes quality-based acceptance, we evaluate against agreed data, metrics, and thresholds. In a PoC, success criteria normally guide the feasibility decision rather than guarantee a particular result. The applicable obligations are defined in the agreement.
We use entrusted client data only for agreed project purposes. Training or fine-tuning requires an explicit written agreement defining the permitted use. Our standard external AI configurations prohibit provider model training on client data under the applicable service terms. Where external processing is not permitted, we can propose self-hosted open-weight models in an approved environment. Data flows, processing locations, and access restrictions are agreed for the project. See our AI Governance and Information Security pages.
A PoC prototype is not assumed to be production-ready. Its scope may not fully address security, access control, performance, availability, integration, or operational support. Production use requires a separate assessment and agreement, with engineering and validation appropriate to the intended environment.
Yes. We can work under a prime contractor or coordinate with an existing system vendor. Before work begins, we agree on scope, dependencies, technical interfaces, decision authority, and communication responsibilities.
Our standard proposed terms generally use the fees under the relevant contract as the basis for a liability cap. The cap, its calculation, covered claims, and any exceptions are negotiated and set out in the signed agreement.
We can discuss the documents needed for your vendor assessment, including company registration information, financial information, and security questionnaires. Availability and any confidentiality conditions are confirmed for the request.
Yes. We support Japanese and English communication. The language of contracts, minutes, and reports, and any controlling-language provision, are agreed for the engagement.
An estimate should make the proposed work, pricing basis, and assumptions clear enough for business and technical review.
Quotes identify included and excluded work, data assumptions, client responsibilities, staffing, dependencies, and how changes or delays may affect the plan.
When requirements remain open, we provide an indicative range with its assumptions. A formal quote follows once the scope and pricing basis are sufficiently defined.
A change request records the proposed scope change. We assess its impact and agree on any revised effort, schedule, and fees before starting the changed work.
Quotes break down work by phase, function, or team allocation as appropriate. A fixed-fee proposal can still show the scope and effort assumptions needed for evaluation.
Tell us about your business challenge, current systems, and timeline. In an initial consultation, free of charge, we can discuss possible engagement models, key feasibility questions, and the information needed for an estimate.
Contact Us
