# Gaps to close before a credible response

**The largest current gaps are bidder-specific evidence, protected-output proof and a supported cost estimate.** The technical design is detailed, but no company qualifications, named staff, delivery references, tested prototype or approved commercial estimate have been supplied. Treat those absences as work items rather than fill them with persuasive adjectives. The RFI remains open as shown on the [opportunity page](opportunity.md).

## Prioritized closure register

“Before response” means before an authorized RFI submission; it does not imply the completed production system is due then. “Before bid” means before committing under any later solicitation. Owners below are proposed roles, not assigned people.

| Priority and gap | Why it could cost us the opportunity | Closure evidence and proposed owner | Timing / present state |
|---|---|---|---|
| P0 — Bidder identity and position | A technical concept without an accountable supplier is hard to assess | Legal company name, contact, relevant registration facts as applicable, business status, prime/partner decision — business owner | Before response; missing |
| P0 — Relevant delivery record | The Library cannot assess execution credibility from architecture alone | Two or three factual case studies: work scope, bidder's role, dates, comparable challenge, measurable result and authorized reference — capture lead | Before response where available; not supplied |
| P0 — Named PM and Senior Engineer | Draft §6.1 identifies key roles and qualifications | Accurate resumes, availability, speech/audio/integration experience, degree and experience verification; partner commitment if needed — delivery lead | Capability summary now; full required evidence before future proposal; missing |
| P0 — Credible ROM | Unsupported price makes the market-research response less useful | Actual staffing/rates/effort, direct costs, assumptions, uncertainty, warranty reserve and approval — estimator | Before response; illustrative model only |
| P0 — Rights and continued operation | A recurring software dependency or unclear deliverable rights could defeat a core requirement | Component/voice/encoder inventory; rights assessment and proposed delivery terms — technical + procurement leads | Risks disclosed now; resolved before commitment; open |
| P1 — Encoder and protector access | Good WAV audio is not the required protected DTB | Approved versions, OS/headless interface, licensing, key handling and known reference output — DTB engineer | Ask now; prove before compliance claim; unavailable here |
| P1 — Playback evidence | A demo might fail where patrons actually listen | Target device/app matrix, test access, navigation record and final decoded-audio checks — QA/NLS counterpart | Before qualified-output claim; missing |
| P1 — Complete-book speech and correction | Short samples conceal omissions, drift and review cost | Held-out passages, complete-book results, defect counts, repair/reviewer effort and voice approval — audio/ML lead | Feasibility samples if actually available now; full prototype gate later; unmeasured |
| P1 — AWS access and security baseline | Environment restrictions can change cost and architecture | Section H, approved account/region/services, boundary/egress and interface decisions — platform/security lead | Clarify now; obtain before deployment commitment; missing |
| P1 — Profile and content scope | Standards ambiguity can invalidate outputs or underprice work | Governing edition matrix, multimedia/language/content classes, synthetic-mastering interpretation — DTB lead + Library | Prioritized RFI questions; unresolved |
| P1 — Commercial audio route | A text-only offer leaves an explicit requirement unanswered | Audio-only and text-assisted fixtures, provenance and reviewed navigation/announcement demonstration — backend/ML leads | Include approach now; demonstrate in prototype; planned |
| P1 — Accessible operator workflow | An inaccessible repair interface undermines usable automation | Keyboard/screen-reader task tests with representative operators, documented fixes — QA/accessibility lead | Plan now; test before acceptance; no UI built |
| P1 — Support and warranty capacity | A prototype team may not cover accepted delivery obligations | 24-hour response process, production/QC workload, on-call ownership, escalation, patch plan and separately budgeted warranty correction — delivery manager | Price and describe before commitment; staffing unconfirmed |
| P2 — Recovery and independent handover | Dependence on the original engineer weakens sustainability | Interrupted-job/restore tests, clean installation by another operator, source/model/profile export — platform lead | Prototype and later-phase gates; planned |
| P2 — Final solicitation instructions | A strong narrative may still be nonresponsive | New instruction/evaluation crosswalk, page/format limits, amendments and submission checklist — proposal manager | Once issued; not available |

## What would make the offer defensible

For each proposed advantage, preserve a compact evidence package: claim, exact scope, date/version, responsible person, reproducible procedure, raw result and limitation. Distinguish bidder past performance from a partner's work and from a newly proposed capability. A reference must not suggest the bidder performed work it did not perform.

Add a named responsible signatory and evidence basis for draft §3.3 written certifications validating reports. The current plan contains no certification and no authority to certify untested output.

At least two independent review questions should be answered before release: **Does every capability claim have the right evidence?** and **Does the proposed effort cover what we promise?** A writer should not approve their own unverified compliance, pricing or past-performance statements.

## Immediate clarification questions

Prioritize questions that materially change feasibility or ROM: governing specification editions; approved encoder/protector and available reference books; player access; synthetic mastering rules; Section H and AWS boundary; source-language/multimedia scope; volume/turnaround and acceptable correction effort; integration interfaces and responsibility; third-party component rights; total POP and support expectations. Ask whether the Library has a preferred response length/format before assuming one. The [draft response](proposal-draft.md#feedback-on-the-draft-sow) consolidates buyer-facing wording.

## Public and private working material

The public wiki can explain a proposed approach and source-grounded gaps. Store real resumes, customer contacts, pricing approvals, teaming terms and any marked proprietary content privately; replace public placeholders only in an authorized submission copy. The [editable draft](proposal-draft.md) currently includes no invented qualifications. No claim in this register is a finding that the bidder is ineligible; company facts have not yet been supplied.