# Strategy for a competitive offer

**Our proposed case is lower delivery uncertainty with evidence the Library can inspect:** correct protected books, manageable correction effort, both source routes, and a system the Library can operate and maintain under the required rights arrangement. These are proposed themes to prove, not established advantages over an identified bidder. The current RFI asks for capability, market information, ROM pricing and SOW feedback; it supplies no scored evaluation criteria. [Opportunity status](opportunity.md).

## Make each claim earn its place

<!-- diagram:win-evidence -->

A feature becomes useful in a response when it addresses a Library need, explains the proposed mechanism, produces evidence and states the practical benefit. Avoid “best voice,” “fully compliant,” “production ready,” “lowest cost” or “unique” unless the exact claim is supported. No probability-of-win score is justified by the evidence available here.

| Proposed theme | Buyer benefit to substantiate | Evidence that would make it credible | Current position |
|---|---|---|---|
| Correct delivered books | Less acceptance and interoperability risk | Tiny protected book, governing profile, independent validator results and target-player navigation record | Planned; tools/player access unresolved |
| Controlled correction effort | Predictable operator workload and production cost | Full-book defect ledger, before/after repair demonstration and reviewer minutes per accepted hour | Planned; no measurements |
| Both source routes with provenance | Reuse commercial narration while preserving text fidelity | Source-to-output mapping, commercial-audio example, text-origin example, audited announcement handling | Designed; no prototype |
| Operational independence | Continued use and maintenance after handover | Rights inventory, clean installation, offline inference, source/configuration exports and an independent operator rebuild | Proposed; rights and handover unproved |
| AWS integration and accountable delivery | Fit with the existing environment and controlled operational risk | Relevant past performance, approved interface plan, named staff, recovery tests and realistic phased estimate | Bidder evidence not supplied |

The strongest initial message is the combination and its proof. TTS, DAISY output, pronunciation controls and local processing already exist in the market; they are not sufficient novelty claims. [Competitive reference offerings](competition.md).

## Turn the prototype into a bid investment

The [16-week prototype plan](prototype.md) describes proposed execution after resources and dependencies are available. For the RFI window, prioritize evidence already in hand and a limited feasibility artifact only if it can be produced honestly and safely. Do not fund a broad polished UI before establishing the encoder/protector route and relevant delivery capability.

The next incremental investment should answer the hardest buyer question: can this team produce an inspectable protected DTB and explain what it costs to correct and operate? A short test book plus recorded limitations is more credible than a staged voice demo presented as complete compliance. A successful narrow artifact must still be described by its actual scope.

## Team where the evidence is weakest

Evaluate a specialist accessible-book/DTB partner, an audio QA contributor familiar with long-form narration, and an AWS/security integration partner only where the prime lacks demonstrated capability. Choose partners for attributable past work, named available personnel, rights to deliver components, interface ownership and ability to participate in acceptance testing. A logo on a slide or an unconfirmed teaming conversation is not capacity.

The bidder must decide prime versus subcontractor positioning, control of integration and acceptance, workshare, responsibility for defects, and ownership/redistribution arrangements. Preserve the draft's non-subscription and ownership obligations in the proposed solution; a dependency that prevents continuing use after handover undermines the central offer.

## Honest competitive discipline

Compare public capabilities and the evidence we can produce. Do not speculate about unnamed bidders' competence, claim an incumbent relationship without award evidence, or equate an open-source model choice with exclusivity. Do not derive competitors' pricing from our labor assumptions. Use the [gap register](gaps.md) to decide where teaming or proof closes a meaningful disadvantage.

Useful differentiation often lies in acceptance evidence and execution discipline: a common test corpus, exact model/profile provenance, accessible correction flow, bounded repair, source coverage and a reproducible handover. Recommend these measurable, supplier-neutral acceptance methods in SOW feedback because they help the Library compare solutions, not because they exclude another vendor's technology.

## Bid and response decision gates

**RFI participation gate:** a response can proceed once bidder identity, factual capabilities and an authorized ROM are ready, even if the future system has not been built. Disclose proposed work clearly. **Future prime-bid gate:** confirm a qualified PM/Senior Engineer, required rights, a credible protected-output path, suitable past performance or teaming evidence, feasible schedule and supported price. If an essential capability remains unsupported, resolve it through a partner or reconsider prime positioning.

These are our internal business gates, not Government eligibility rules. The actual solicitation will determine mandatory qualifications, evaluation, representations and submission requirements.

## Use this wiki as the evidence workspace

Every technical page now connects its subject to the response claim it supports and the evidence still needed. The [coverage matrix](compliance.md) maps draft requirements to response sections and proof. The [draft](proposal-draft.md) provides buyer-facing language; the [ROM](pricing.md) makes the estimate inspectable. Keep actual proprietary rates, resumes, nonpublic customer details and private bid decisions in access-controlled working files. This published wiki contains public-source analysis and an unpopulated planning draft; it is not a private bid room.
