Draft an RFP for cloud migration consulting of our on-premise systems

## Role and objective

<instructions>
You are an RFP author for an organization seeking cloud migration consulting for its on-premise systems. Produce a procurement-ready RFP for prospective consulting vendors and the organization’s evaluators. Mark every item as CONFIRMED, PROVISIONAL, or [FILL IN]; use [FILL IN] for every value not supplied in the context, and add one short line stating what information must replace each slot. Do not invent a project name, budget, schedule, organization name, system inventory, evaluation weight, legal status, or governing authority.

The completion test is satisfied only when the RFP contains every required item listed in <output_format>, preserves the supplied scope, exposes all material unknowns as slots, and does not present unverified assumptions as facts.
</instructions>

## Scope and given facts

<context>
Confirmed facts:
- The requested deliverable is an RFP.
- The subject is cloud migration consulting.
- The systems currently operate on-premise.
- The target AI must write the RFP, not perform the migration analysis or propose a vendor.
- No project name, issuing organization, procurement contact, system inventory, cloud platform, migration approach, business objectives, budget, funding source, deadline, contract term, security requirements, compliance regime, incumbent environment, deliverables, qualifications, evaluation weights, or procurement authority has been provided.

In scope:
- Soliciting consulting services for planning and/or executing migration of the organization’s on-premise systems to cloud infrastructure, subject to confirmation of the actual scope.
- Defining vendor response requirements, evaluation structure, submission schedule, and requested consulting outputs.

Out of scope unless the RFP marks them [FILL IN] and the organization confirms them:
- Selecting a cloud provider, specifying architecture, promising a migration outcome, or asserting legal applicability.
- Filling missing procurement facts with plausible values.

For each [FILL IN] slot, state what the issuing organization must provide. In particular, the slot for “[FILL IN: systems, workloads, and migration scope]” must be replaced with the actual in-scope systems, dependencies, environments, and migration boundaries—not a generic cloud-migration description.
</context>

## Working rules

<instructions>
Before drafting, show concise reasoning steps that identify the supplied facts, unresolved decisions, and the dependency between each missing fact and the relevant RFP section. Do not expose private chain-of-thought; provide only a brief decision summary.

Apply these rules:
1. Mark each substantive item CONFIRMED when directly supplied, PROVISIONAL when explicitly framed as a proposal requiring approval, or [FILL IN] when the organization must supply it. Never silently convert a provisional proposal into a requirement.
2. Ask whether the Federal Acquisition Regulation (FAR) governs this procurement. If yes, leave the applicable vehicle as [FILL IN: FAR vehicle—RFP, RFQ, or IFB] and the set-aside status as [FILL IN: set-aside, if any—small business, 8(a), SDVOSB, or HUBZone]. If no, identify the non-federal governing authority as [VERIFY: governing state or local procurement authority]; do not assume FAR applies.
3. If federal procurement is confirmed, leave “[FILL IN: SAM.gov registration status or requirement]” and “[FILL IN: NAICS code]” for the issuing organization to complete. If federal status is not confirmed, do not imply that either item applies.
4. Define the consulting scope through observable outputs, assumptions, dependencies, acceptance conditions, and vendor responsibilities. Where planning-only and implementation-support scopes differ, present them as separate branches: include planning deliverables only if planning is requested; include implementation support only if that responsibility is confirmed.
5. Do not create evaluation criteria or weights. Leave each unknown as “[FILL IN: evaluation criterion]” and “[FILL IN: weight]”, with a line specifying that the procurement team supplies the criterion and approved percentage.
6. Do not create dates or deadlines. Use “[FILL IN: date or deadline]” slots and state that the procurement team supplies the governing date.
</instructions>

## Output structure

<output_format>
Write the RFP using the following item names and instructions. Do not fill the items yourself.

1. **Overview** — State the procurement purpose, issuing organization, procurement contact, procurement authority, applicable vehicle, anticipated contract form, and high-level objectives. Mark each field separately.
2. **Scope of Work** — Describe the on-premise environment, systems and workloads, discovery activities, migration planning, target cloud scope, security and operational considerations, required deliverables, assumptions, dependencies, exclusions, and optional services. Use [FILL IN] slots where the organization has not supplied details.
3. **Documents to Submit** — List the proposal letter, technical approach, work plan, staffing and qualifications, relevant experience, references, pricing format, assumptions, exceptions, certifications, and any required forms. Mark every document requirement as CONFIRMED, PROVISIONAL, or [FILL IN].
4. **Evaluation Criteria with Weights** — Render a table with columns for criterion, description, weight, evidence requested, and confirmation state. Leave unknown criteria and weights as slots; do not invent or allocate percentages.
5. **Schedule** — Render a table with columns for milestone, date, time zone, submission method, and confirmation state. Include only milestones supported by the input; otherwise use slots for the procurement team to complete.
6. **Vendor Instructions and Contractual Considerations** — Include questions, communications protocol, proposal validity, pricing assumptions, confidentiality, intellectual property, data access, security obligations, insurance, conflicts, subcontracting, contract term, options, and termination only as confirmed requirements or labeled slots. Name any applicable authority without stating what it requires unless that requirement is provided.
7. **Response Template** — Give vendors headings matching the requested documents and require them to answer every stated requirement, identify exceptions, and distinguish assumptions from commitments.
</output_format>

## Style rules

Use a hybrid style. Use itemized, table-oriented writing for fields, submission requirements, evaluation criteria, schedules, statuses, and vendor response instructions. Use concise narrative paragraphs for the purpose, scope overview, assumptions, and transition between sections. Maintain a neutral, formal procurement register; avoid vague promotional clichés such as “best-in-class,” “seamless migration,” “revolutionary,” and “turnkey solution” unless a defined, evidenced requirement uses that wording.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is an RFP for cloud migration consulting, not a migration plan, architecture document, or vendor recommendation.
2. Confirm that the only supplied facts treated as confirmed are the RFP format, cloud migration consulting subject, and on-premise systems.
3. Check that the actual slot “[FILL IN: systems, workloads, and migration scope]” remains unfilled and includes instructions for replacing it with the organization’s real inventory and boundaries.
4. Check every substantive item for exactly one status: CONFIRMED, PROVISIONAL, or [FILL IN].
5. Check that no project name, organization name, budget, date, contract term, evaluation weight, system detail, or legal conclusion was added beyond the context.
6. Check that FAR applicability is posed as a decision and that the vehicle and set-aside fields remain slots until confirmed.
7. Check that SAM.gov and NAICS fields appear only as conditional federal-procurement slots.
8. Check that the required item names—overview, scope of work, documents to submit, evaluation criteria with weights, and schedule—are present.
9. Check that evaluation criteria and schedule are rendered as tables and contain no invented weights or dates.
10. Check that scope boundaries distinguish planning from implementation support rather than assuming both.
11. Check that the output stays within cloud migration consulting procurement and does not drift into unrelated technology procurement.
12. Check that the response contains concise reasoning steps before the conclusion, followed by the RFP in the requested XML-delimited format.