# Proof gates and draft milestones

Use technical proof gates to reduce uncertainty while meeting the draft's separate contractual phases. The five gates below come from the engineering proposal; they are not the four phases named in the SOW.

## Proposed proof gates

| Gate | Work to demonstrate | Pass evidence |
|---|---|---|
| 1. Format and protection | Build a tiny complete book with the approved profile, encoder, protection and packaging | Approved validation results and working navigation/playback on target systems. |
| 2. Long-form speech | Compare candidate engines on chapters and complete representative books | Agreed fidelity and quality results, with measured correction effort. |
| 3. Both ingestion paths | Process structured text, less-structured text, commercial audio with and without matching text | Source coverage and independently checked navigation, including explicit unavailable information. |
| 4. Repair and rebuilds | Change pronunciation, replace a paragraph, edit a heading, interrupt processing and fail encoding | Only necessary work repeats; all dependent timing, hashes, metadata and packaging remain correct. |
| 5. Production operation | Run batches, security checks, recovery and real integration | Repeatable accepted outputs, measured throughput and operational handover. |

Prove codec/protection compatibility early with simple known content so that format errors can be separated from speech errors. Speech and importer experiments can proceed in parallel after their required inputs are available.

## Schedule in the supplied draft

**POP** means period of performance. No actual start date or total duration is supplied here, so the dates below are relative triggers rather than calendar commitments. [SOW §4.1 and named phase descriptions](https://sam.gov/api/prod/opps/v3/opportunities/resources/files/34eacfe92b1a46228b9f90674c4c60e1/download).

| Deliverable or event | Draft timing |
|---|---|
| Key personnel resumes | At proposal submission. |
| Kickoff | Within 10 business days; the table uses POP start while §5.2 uses contract award. Clarify the trigger. |
| Five architecture diagrams and eight technical documents | Within 30 calendar days after POP start. |
| Status and quality-control reports | Every 30 calendar days during POP. |
| Phase I prototype, sample DTBs, workflow demonstration and test report | Within six months of POP start. |
| Phase II integration and operational testing | Starts after Phase I completion and Government acceptance; completed within 90 calendar days. |
| Phase III full deployment | Starts after Phase II completion and Government acceptance; completed within 90 calendar days. |
| Phase IV ongoing support | After Phase III completion and acceptance, through the remainder of POP. |
| Warranty | 12 months after written Government acceptance of all deliverables. |

The 24-hour support-response requirement appears in §3.8. The warranty includes free defect correction and patches under §3.9. Do not turn the phase durations into a promised total project length: Government acceptance timing and the total POP are not established here.

## How the gates can fit the phases

**Proposed mapping:** use Phase I to resolve the profile and prove format/protection, model behavior and initial ingestion. Continue hardening ingestion, repair and operational behavior through Phase II integration tests. Phase III adds deployment, handover and acceptance evidence. Phase IV covers production support and controlled improvement.

This mapping does not reduce the deliverables required in any phase. Validate it against the final solicitation and approved project plan.

## Early documents should expose real decisions

The first-month architecture package should show both source paths, data ownership, security boundaries, failure/retry handling, and the split between AI proposals and accepted compiler inputs. List unresolved standards and supplied-component dependencies rather than hiding them behind a generic cloud diagram.

## Suggested readiness check before a pilot

Confirm the output profile; acquire reference books, target players and required tooling; agree supported content classes and quantitative acceptance criteria; record authorized voices and dependency rights; obtain Section H; and identify who can accept exceptions and release a book. These are suggested prerequisites tied to the [decision register](decisions.md).