From Pilot to Supply
TLDR: You can test custom data before you commit to it. A paid pilot gives you real files, manifests, and QA outputs to review. If fit is confirmed, you move to a program and then to ongoing supply.
How do pilot, program, and supply differ?
You buy in stages. Each stage has defined inputs, outputs, and review points.
| Level | What happens | What you sign off |
|---|---|---|
| Paid pilot | Focused collection and annotation against a short spec | Protocol before capture, files and manifest after delivery |
| Program | Wider scope, variation, or languages once fit is confirmed | Locked protocols for larger builds across video from HD to 4K, all environments, all image categories, depth, LiDAR, sensors, radar, and multimodal needs |
| Ongoing supply | Steady deliveries against an agreed schedule and spec | Schedule, spec changes, and acceptance checks |
You stay in control throughout. Nothing scales until you have seen evidence.
What happens at each stage?
The sequence stays the same from pilot to supply.
- You share a brief with success criteria
- We draft a collection and annotation protocol and you approve it
- We collect under consent with raw files preserved unchanged
- We annotate with machine draft plus human confirmation and independent review
- We deliver with visual previews and a per file manifest with checksums
You review twice. Once at protocol stage, once at delivery stage. You always know what was agreed, what was collected, and what was checked.
What should you check in a pilot?
A pilot is for fit with your workflow. You look at label quality against your guidelines. You look at metadata completeness. You verify file integrity with checksums. You confirm coverage for speakers, devices, lighting, camera angles, and environments you asked for.
For language work, you confirm coverage across English, Hindi, Kannada, Telugu, Tamil, Malayalam, Marathi, and Sanskrit, with more available on request. You also confirm prompts and transcription conventions in a separate pass with alignment checks included.
This part is kinda important. You also see how we handle ambiguity, how we document decisions, and how fast we absorb corrections.
What a pilot delivery contains
item_number,track,review_status,reviewer_code,sha256
02d9e8da-...,Image,accepted,REVIEWER_0001,f2cf26e58570...
b9132ff4-...,Speech,accepted,REVIEWER_0001,7f475d58cc2e...
Exhibit 3 — Manifest excerpt: per-file verdict from a reviewer independent of collection, plus a checksum you verify on receipt.
When does scaling make sense?
Scale when the pilot answered your questions and the protocol feels stable enough to repeat. Your team can take in regular deliveries without reworking specs each time.
The pilot cuts risk both ways. You assess our quality and process. We assess whether your spec can be collected and annotated reliably at the scope you need.
Questions buyers ask
How long does a pilot take? Fixed scope, fixed timeline, set in the pilot plan. The protocol draft follows your brief within days; capture and delivery dates are locked before we record.
What do you need from us to start? A brief with success criteria: scenes, devices, speakers, languages, annotation target, and acceptance bar.
What if the pilot shows poor fit? Both sides learn cheaply. The pilot still leaves you with usable, consented, documented files and a clear reason scaling needs a different shape.
Start with a paid pilot. Send your brief and success criteria and we will draft a protocol for your approval. Request a pilot or Talk to us.
Related reads
Pair with how we collect to spec and consent before camera.
Sources
- NIST FIPS 180-4, Secure Hash Standard — the SHA-256 behind the per-file checksums you verify in a pilot.
- First-hand: process claims above describe our own pipeline. The exhibits are verbatim outputs — a real pilot-shape delivery and manifest rows — not illustrations.
