Milestone 10: Produce and Validate Your First Complete Project Unit
Gary WhittakerProduce and Validate Your First Complete Project Unit
Your production plan remains theoretical until one representative unit moves through it. This milestone helps you create that unit, review the result, document what happened and decide whether the wider project is ready to continue.
Understand pilot production
Create and validate the pilot3. Build · VIP
Build scale-readiness control
Jack Righteous normally uses a black, white and gold identity. Academy lessons use a lighter working format because their exercises, production logs, review tables and records are intended to be printed, highlighted, annotated and saved as PDFs. The lighter presentation uses less ink and remains readable in colour or black and white. Gold remains the Academy accent.
1. Understand what you are producing
| Term | Purpose | Completion level |
|---|---|---|
| Sample | Explores a direction. | May be fragmentary. |
| Prototype | Tests concept or function. | May use temporary elements. |
| Pilot production unit | Tests the real project and real production system. | Complete enough to pass the intended standards. |
2. Why one complete unit comes first
A pilot can expose missing tasks, hidden dependencies, weak instructions, unrealistic capacity assumptions, review delays, tool limitations, version confusion, rights requirements and poor handoffs before those problems multiply across the project.
3. Choose the correct pilot unit
The best pilot is representative, important, bounded and reviewable. It should use the normal workflow without being artificially easy or unusually complex.
| Criterion | Question |
|---|---|
| Audience importance | Does this unit matter to the project promise? |
| Structural representativeness | Does it resemble the remaining units? |
| Technical representativeness | Does it use the normal tools and outputs? |
| Rights/evidence | Does it expose normal documentation needs? |
| Review value | Will feedback improve future units? |
| Completion feasibility | Can it be completed without shrinking the real standard? |
4. Run the readiness gate
A pilot is ready only when its purpose, audience, outcome, structure, sources, owner, tasks, dependencies, review criteria, rights needs, file locations and definition of done are visible.
Ready
All critical conditions are supported.
Ready with conditions
Minor gaps have owners and resolution rules.
Not ready
A critical input, right, approval, owner or delivery path is unresolved.
Stop rule
Do not substitute enthusiasm for readiness evidence.
5. Establish the production baseline
Before creation starts, preserve the planned sequence, tools, expected workload, review stages, known blockers, intended human contribution, intended AI assistance, file structure and completion criteria. Use light, moderate, heavy, specialist or blocked where precise evidence is unavailable.
6. Create through the approved workflow
Start from approved inputs, record major decisions, save source material, preserve meaningful versions and note deviations. Experiments should remain separate from approved production.
7. Document human and AI contribution
Record what the creator conceived, wrote, performed, selected, edited or approved; which AI tools were used; what each tool generated or transformed; material prompt and input decisions; rejected outputs; references; and the creator’s final selection.
8. Validate the unit in layers
| Review | What it tests | Evidence |
|---|---|---|
| Content | Outcome, accuracy, completeness and sequence. | Criteria-based review notes. |
| Audience fit | Clarity, difficulty, value and next-step support. | Specific observations from suitable reviewers. |
| Technical | Playback, exports, dimensions, legibility, accessibility and compatibility. | Test results and approved files. |
| Rights/evidence | Sources, permissions, licences, claims and third-party materials. | Source and permission records. |
| Brand/continuity | Tone, terminology, naming and connection to the wider project. | Continuity checklist. |
9. Gather feedback without surrendering authorship
Separate observations, preferences, confusion, errors, scope requests and strategic disagreement. Ask focused questions rather than “What do you think?”
10. Revise through root cause
Classify issues as unit-specific, task-specific, structural, instructional, technical, rights-related, capacity-related or review-system-related. Fixing only the visible sentence may leave the real system problem untouched.
11. Compare plan against reality
Record planned versus actual sequence, workload, blockers, revisions, review turnaround, tools, new tasks, unnecessary steps, reusable templates and changes to ready/done rules. This is where the pilot becomes evidence for the wider project.
12. Decide whether the system is repeatable
The unit met its outcome, quality passed, dependencies were manageable and the next unit can start without redesigning everything.
The project remains viable, but process, quality or capacity corrections are required first.
A critical structural, rights, technical, capacity or audience problem remains unresolved.
Article 1 completion standard
- Select a representative pilot
- Confirm readiness
- Preserve the production baseline
- Document human and AI contribution
- Run layered validation
- Classify feedback and revisions
- Compare planned and actual production
- Decide whether the system should scale
Continue the milestone
Create with intention. Document the decisions. Release with purpose. Build something you own.
