AI FACTORY RFP STARTER TEMPLATE

HOW TO USE
Replace bracketed fields before issuing. Give each requirement an ID, priority, evidence requirement and acceptance test. Require suppliers to state exceptions explicitly. This template is a starting structure, not legal terms or an approved engineering specification.

A. BID INSTRUCTIONS
Project and buyer: [name / organisation]
Response deadline and format: [date / files]
Clarification contact and question deadline: [contact / date]
Decision owner and evaluation process: [owner / criteria]
Validity period: [period]

B. SCOPE AND DESIGN BASIS
Business outcome and workloads: [description]
Initial installed capacity: [nodes / GPUs / platform]
Expansion envelope: [capacity / triggers / dates]
Service objectives: [measurable targets]
Buyer-supplied inputs: [item / owner / status]
Explicit exclusions: [items]
Open assumptions: [assumption / consequence / owner]
Distinguish a proposed design from approved procurement and installation instructions.

C. REQUIREMENTS MATRIX
Copy this row for compute, fabrics, storage, platform, security and facility-facing requirements.
ID | Requirement | Priority | Supplier response | Design decision | Evidence expected | Acceptance method | Owner | Exception
[ID] | [requirement] | [must / should] | [response] | [decision] | [source or test] | [pass criteria] | [owner] | [exception]
A statement of compliance must name its evidence. Unsupported responses remain open.

D. ARCHITECTURE RESPONSE
Request architecture and topology diagrams, a logical bill of materials, port and connectivity budgets, rack and IT power envelopes, and requirements traceability.
For each component state quantity, sizing assumptions, dependencies and the source version used.
Reconcile all diagrams, quantities and narrative to the same named design baseline.
Separate compute, storage, external, management and out-of-band fabrics.

E. SECURITY AND OPERATIONS
Describe identity, tenant boundaries, keys, network isolation, audit and recovery.
For each control distinguish a proposed architecture from a tested deployment.
Provide an evidence owner and test plan for claims requiring runtime verification.
Define monitoring, support responsibility, escalation and change control.

F. IMPLEMENTATION AND ACCEPTANCE
Milestones: [deliverable / owner / due date / dependencies]
Acceptance: [test / environment / expected result / witness]
Exceptions: [finding / impact / owner / decision deadline]
Handover: [documents / training / access / support]
Define who may approve a baseline and who may authorise procurement.

G. COMMERCIAL RESPONSE
Itemise hardware, licences, services and support separately.
State quantities, unit assumptions, currency, validity, taxes and exclusions.
Identify optional expansion separately from the initial order.
Explain lead times, dependencies and consequences of scope changes.
Contract terms: [buyer-approved terms / review owner]

SUBMISSION CHECK
[ ] Every requirement has a response and an exception where needed.
[ ] Quantities and selected platforms match across all documents.
[ ] Evidence names its source, date and applicability.
[ ] Acceptance tests have measurable pass criteria and named owners.
[ ] Commercial totals distinguish the initial build from options.
[ ] The submitted baseline has a name, version and reviewer.