AI DATA & EVALUATION
Validate the data, workflow and quality model.
- Data collection and evaluation
- Acceptance criteria
- Versioned delivery
PILOTS
Prove the delivery before you scale it.
YPAI designs each pilot around your real data, your systems, and the way you actually operate. You review the results against acceptance criteria agreed before the work starts, then decide whether to move to production.
For AI Data & Evaluation, AI Implementation, or a connected delivery across both.
THE PURPOSE
A pilot is not a generic demo.
It is a limited, contract-defined validation of the delivery YPAI would be expected to run in production.
- Scope of work
- Technical requirements
- Acceptance criteria
- Data protection and rights
- Commercial structure
- Remediation and change control
The pilot uses your actual objective, operating constraints, technical requirements and acceptance criteria. Depending on the engagement, it may validate a data workflow, an AI system, an evaluation method, or the connection between them.
The question is not whether a sample looks promising. The question is whether the delivery method meets the requirements that matter in production.
PILOT SCOPE
One validation model. Three delivery paths.
Each path is tested against agreed requirements and acceptance criteria before production.
AI IMPLEMENTATION
Validate the system in the real operating context.
- Workflow and system validation
- Human review
- Deployment controls
CONNECTED DELIVERY
Validate the data and the system together.
- One accountable scope
- Shared acceptance criteria
- One decision record
HOW THE PILOT RUNS
Scope. Define. Run. Review. Decide.
Each stage is agreed, executed and reviewed against the pilot requirements.
Start with the real requirement.
You and YPAI define the objective, the current starting point, and the constraints that decide success: technical requirements, expected outputs, timeline, known risks.
THE SCOPE FIXES
- Objective
- Constraints
- Expected outputs
- Known risks
Agree what success means before work begins.
The pilot agreement fixes the test before work begins: what will be delivered, how quality is measured, who carries which risk, and how changes are handled.
THE DEFINE FIXES
- What will be delivered
- How quality is measured
- Who carries which risk
- How changes are handled
Configure and execute the pilot.
YPAI configures the required workflow, environment, review process and delivery controls, then produces the agreed pilot output or working system.
THE RUN FIXES
- Workflow
- Environment
- Review process
- Delivery controls
Inspect the results directly.
You receive access to a dedicated pilot workspace and analyse the outputs, quality measurements, acceptance results and exceptions yourself.
THE REVIEW FIXES
- Outputs
- Quality measurements
- Acceptance results
- Exceptions
Scale, remediate or stop.
You can accept the pilot and proceed to production, request an agreed remediation, or stop without a production commitment. The next step follows the documented result, not a sales assumption.
THE DECIDE FIXES
- Accept and proceed to production
- Request an agreed remediation
- Stop without a production commitment
AFTER THE PILOT
A pilot creates a decision point, not an automatic expansion.
-
ACCEPTED
Move into production.
You and YPAI define the production scope, commercial model, capacity, controls and ramp plan using the accepted pilot as the reference.
-
REMEDIATION
Correct against the same criteria.
Where the agreement provides for remediation, YPAI corrects the identified issues and the affected result is evaluated again against the agreed requirements.
-
STOPPED
End without a production commitment.
A pilot does not obligate you to proceed. The project can stop after review, subject to the commercial and contractual terms agreed during scoping.
-
Scope of work
The objective, deliverables, responsibilities, timeline, dependencies and exclusions.
-
Technical requirements
The relevant modalities, systems, formats, environments, integrations, volumes and operating constraints.
-
Acceptance criteria
The quality rubric, measurement method, review sample, evidence requirements, rejection reasons and acceptance window.
WRITTEN AT MEASUREMENT LEVEL
For a multi-object video tracking pilot, acceptance can require HOTA 0.65 or higher and IDF1 0.75 or higher across the agreed review sample before the result is accepted.
-
Data protection and rights
The DPA, processing roles, permitted use, consent or licensing requirements, retention, access and deletion obligations where applicable.
-
Commercial structure
The pilot fee, setup or mobilisation costs, third-party expenses, payment triggers and treatment of accepted and non-accepted work.
COMMERCIAL MODEL
The commercial structure follows the work.
No hidden universal rule. The commercial and acceptance model is written for the actual pilot.
Some pilots can be completed without a separate pilot fee. Others require paid setup, mobilisation, specialist work, participant costs, hardware, engineering or other project-specific resources.
You and YPAI agree the structure during scoping, based on complexity, setup cost, delivery risk and the resources required.
If YPAI, through its own fault, does not meet the agreed requirements, YPAI bears the cost allocated to that failure under the pilot agreement. The treatment of setup costs, third-party expenses, remediation and changed requirements is agreed before work begins.
AGREED DURING SCOPING
- Complexity
- Setup cost
- Delivery risk
- Resources required
-
Remediation and change control
What YPAI may correct, how the result is re-evaluated, and how changed requirements affect scope, cost and timing.
The pilot contract defines the test.
The documents and requirements are selected for the actual engagement.
PILOT WORKSPACE
Review the evidence directly.
Each pilot includes a dedicated result surface where you can inspect and analyse the work against the agreed criteria. You are not limited to a presentation or a summary prepared by YPAI.
Depending on the engagement, the workspace can include:
- Delivered files, samples or system outputs
- Quality measurements and acceptance results
- Review findings, exceptions and failure reasons
- Versioned specifications and supporting documentation
- Manifests, checksums and rights linkage where relevant
- Remediation status and change history
- Production recommendations and known constraints
You see what was produced, how it was evaluated and what remains unresolved.
SCOPE A PILOT
Scope the pilot around your data or your system.
Acceptance is agreed before work starts. Production is a separate decision after you review the result.
What buyers usually need to know.
The due-diligence answers, in writing, before the call.
No. The commercial structure is agreed during scoping based on complexity, setup cost, required resources and risk.
No. The scope must be large enough to test the relevant delivery method and small enough to remain a controlled validation. The appropriate volume and duration depend on the project.
Yes. A pilot can cover AI Data & Evaluation, AI Implementation, or a connected delivery across both.
Each pilot uses the documentation required for that engagement. This can include a scope of work, DPA, rights and processing terms, technical specification, acceptance criteria, commercial terms and change-control provisions.
Material changes are handled through the agreed change-control process. New requirements do not silently become part of the original acceptance test.
The consequences are defined during scoping and written into the pilot agreement. Where the failure is caused by YPAI, YPAI bears the cost allocated to that failure under the agreement.
No. An accepted pilot provides the evidence and reference point for a separate production decision, scope and agreement.
Yes. You receive access to a dedicated pilot result surface where the relevant outputs, measurements, exceptions and documentation can be analysed.