Problem → Pilot Scope → Readiness Score → Controlled Test → Review Decision
Pilot Readiness is for one specific project that needs a small, safe, measurable test before larger investment.
Pilot readiness for one focused project, test, or workflow.
This page is for deciding whether a project is ready for a small controlled pilot.
It defines the pilot problem, users, data boundary, success metrics, risk controls, timeline, outputs, and review criteria before IYABOKO or a client invests in larger delivery.
What a pilot should prove
A pilot should test one clear workflow or project outcome, not the whole IYABOKO ecosystem at once.
Clear problem
Define the exact workflow pain point: unclear documents, slow research review, messy project intake, weak evidence structure, or poor readiness visibility.
Clear output
Choose one main deliverable: readiness report, evidence brief, project roadmap, workflow dashboard, research summary, or consultation pack.
Clear decision
End the pilot with a decision: stop, revise, expand, partner, seek funding, or move into managed delivery.
Score one project before pilot investment
Use the sliders and evidence checklist to estimate whether a project is ready for a controlled test or should start with a smaller clarity/review pathway.
Evidence checklist
Tick the evidence already available for this pilot.
Generated pilot readiness report
Minimum conditions before testing
If these items are not clear, the project should start with consultation or a readiness snapshot before a pilot.
Defined user
Who will use the pilot and what task will they complete?
Defined input
What information, documents, ideas, or cases will be used?
Defined output
What report, roadmap, summary, or workflow result should be produced?
Defined boundary
What will the pilot not do, claim, automate, or decide?
Defined metrics
How will improvement be measured: time, clarity, completeness, readiness, user feedback?
Defined reviewer
Who checks accuracy, suitability, and final release?
Defined timeline
What happens in week 1, week 2, week 3, and final review?
Defined next step
What action follows success or failure?
Simple scoring model
Use this to decide whether a pilot is ready now or needs more preparation.
| Score Area | 0–1: Not Ready | 2–3: Partly Ready | 4–5: Ready |
|---|---|---|---|
| Problem clarity | Problem is broad or unclear. | Problem is known but not scoped. | One clear workflow problem is defined. |
| Input quality | No usable input material. | Some notes or examples exist. | Test documents, cases, or prompts are ready. |
| Output definition | No clear deliverable. | General output idea only. | Specific output format and review criteria. |
| Risk boundary | High-risk claims or sensitive data. | Some caution needed. | Safe non-sensitive pilot boundary. |
| Review owner | No accountable reviewer. | Reviewer not confirmed. | Named human reviewer or decision owner. |
A simple controlled pilot structure
This gives the user, mentor, or client a practical path from intake to review.
Scope
Confirm problem, user type, test cases, output format, exclusion list, and review owner.
Build
Create the workflow, prompts, forms, report format, evidence checklist, and pilot dashboard.
Test
Run sample cases, collect feedback, compare before/after clarity, and log risks or gaps.
Review
Prepare findings, recommendation, next-stage decision, and revised scope if moving forward.
How to know whether the pilot worked
Operational metrics
- Time saved per report
- Number of cases processed
- Completeness of intake
- Review turnaround time
Quality metrics
- Clarity improvement
- Evidence completeness
- Readiness score improvement
- Reviewer confidence
Governance metrics
- Human review completed
- Sensitive data avoided
- Limitations documented
- Decision owner confirmed
Do not run a pilot if the risk is too unclear
Do not pilot yet
When the project needs regulated approval, contains sensitive data, lacks a decision owner, or has no measurable output.
Start smaller
Use a Project Clarity Call, Starter Readiness Snapshot, AI Workspace preparation, or Consultation before a pilot.
Make it safe
Use fictional, anonymised, public, or user-owned information for the first controlled test whenever possible.
Submit one specific project for pilot-readiness review
This form should collect the project goal, users, data type, expected output, success metrics, risks, and desired timeline.
Use it for one pilot project only. If you have multiple project ideas, submit the highest-priority one first.
Score the project, then request pilot review
A good pilot starts small, measures one thing clearly, and ends with an honest decision.