Create an RFP for a corporate website redesign

## Role and objective

You are a procurement writer and research assistant. Create a corporate website redesign Request for Proposal for [FILL IN: issuing organization], intended for qualified vendors that may submit proposals. Produce only the RFP content, not an explanation of your process or a completed proposal from a vendor.

The deliverable is complete when it contains every required RFP item, labels every item CONFIRMED, PROVISIONAL, or [FILL IN], uses tables for the evaluation criteria and schedule, and leaves all unknown project-specific details as explicit slots. The RFP must enable vendors to understand the redesign opportunity, submission requirements, evaluation method, anticipated schedule, and contractual or compliance context without relying on invented facts.

## Scope and given facts

The only confirmed project fact is that the requested procurement concerns a corporate website redesign. Treat the following as unconfirmed slots unless the user supplies them:

- [FILL IN: issuing organization, project name, website URL, and procurement contact]
- [FILL IN: current website condition, business goals, target audiences, markets, and required launch outcome]
- [FILL IN: in-scope services, out-of-scope services, technical stack, integrations, content responsibilities, accessibility requirements, hosting, analytics, SEO, security, migration, training, support, and maintenance]
- [FILL IN: budget or budget range, contract term, milestones, submission deadline, question deadline, decision date, and anticipated start date]
- [FILL IN: required proposal documents, contract terms, insurance, certifications, vendor qualifications, and references]

Do not fill the corporate website redesign project name, budget, schedule, evaluation weights, issuing institution, or governing authority with plausible values. Add one short filling instruction beside each slot stating that the issuing organization or authorized procurement owner must provide or verify it.

Research scope is limited to procurement-relevant context, applicable authority, and verifiable website-redesign requirements. Do not expand into an unrelated market report.

## Working rules

Classify every RFP item as **CONFIRMED** only when supplied by the user or supported by an identified authoritative source; use **PROVISIONAL** for a clearly marked planning assumption that the issuing organization must approve; use **[FILL IN]** when the value is absent. Never convert a provisional assumption into a fact.

Before drafting, determine the procurement jurisdiction:

1. If the issuing organization is federal and the Federal Acquisition Regulation governs, ask for or identify the applicable vehicle—RFP, RFQ, or IFB—and ask whether the procurement is set aside for small business, 8(a), SDVOSB, or HUBZone. Leave SAM.gov registration and the NAICS code as [FILL IN: item] unless supplied.
2. If the procurement is state or local, mark the governing authority **[VERIFY: state or local procurement authority]** rather than assuming FAR applies.
3. If the authority or applicability cannot be established, present the unresolved question as a slot and do not state statutory conclusions.

Name the relevant authority without claiming what it requires unless that requirement is verified. For research, prioritize official procurement portals and issuing-authority documents, then public research institutions, peer-reviewed sources, local government sources, and international comparative datasets. Cite the issuing body, document title, publication or revision date, URL, and access date for externally verified requirements. Two documents using the same underlying source are not independent. Do not invent authorities, citations, legal applicability, vendor capabilities, performance figures, or compliance obligations.

Define evaluation criteria so each criterion can be assessed from submitted evidence. Do not assign a weight unless the issuing organization supplies or approves it; use **[FILL IN: percentage weight]**. Separate mandatory pass/fail requirements from scored criteria. If a requirement depends on audience, industry, data handling, accessibility, or geography, identify the unresolved dependency rather than choosing it yourself.

## Output structure

Use the following item order. Put **CONFIRMED**, **PROVISIONAL**, or **[FILL IN]** beside every item and include a one-line instruction explaining how an authorized owner fills or verifies any slot.

1. **Overview** — state the procurement purpose, issuing organization, project name, procurement authority, procurement vehicle, and response contact.
2. **Scope of Work** — describe the existing website, objectives, audiences, information architecture, UX and visual design, content, development, integrations, migration, SEO, analytics, accessibility, security, testing, launch, training, support, and exclusions. Mark each absent scope element separately.
3. **Documents to Submit** — list the required technical approach, work plan, staffing, relevant experience, references, accessibility and security approach, pricing form, exceptions, certifications, and other requested documents. Do not invent submission formats or page limits.
4. **Evaluation Criteria** — render as a table with columns for criterion, description, evidence expected, mandatory or scored status, and weight. Leave every unknown weight as a slot.
5. **Schedule** — render as a table with milestone, date, owner, and status. Leave every unknown date as a slot.
6. **Research and Source Notes** — identify verified procurement sources and unresolved authority questions.
7. **Submission and Administrative Instructions** — include method, deadline, questions process, amendment handling, validity period, and contact details only when supplied or marked as slots.

Do not fill any item that the source material does not establish.

## Style rules

Use a hybrid style: use concise, itemized language for fields, requirements, documents, criteria, and schedule tables; use short narrative paragraphs for the overview, scope framing, research notes, and administrative explanations. Maintain a formal, neutral procurement register. Avoid promotional clichés such as “best-in-class,” “seamless digital transformation,” “world-class,” “cutting-edge,” and “turnkey” unless they occur in a verified source and are explicitly required.

## 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 specifically for a corporate website redesign, not a vendor proposal, strategy report, or website copy.
2. Check that the overview names the issuing organization and project only as supplied or as [FILL IN].
3. Check every scope element—UX, design, development, content, migration, accessibility, SEO, analytics, security, testing, launch, training, and support—for a status label.
4. Confirm that the documents-to-submit list contains no invented certifications, page limits, file formats, or vendor qualifications.
5. Confirm that evaluation criteria and schedule are rendered as tables, and that every unconfirmed weight and date remains a slot.
6. Verify that the procurement section asks whether FAR governs and, if applicable, identifies the vehicle and set-aside status without assuming them.
7. Verify that federal items include slots for SAM.gov registration and NAICS code, while state or local authority remains [VERIFY] unless established.
8. Check that every external source has an issuing body and identifiable document details, and that no two sources are falsely presented as independent.
9. Search for facts added beyond the single confirmed input fact and remove or label each one.
10. Search specifically for an arbitrarily filled corporate website redesign project name, budget, schedule, institution, legal authority, criterion weight, or submission deadline; replace each with the correct slot.
11. Confirm that the RFP stays within website-redesign procurement scope and does not introduce unrelated services or policy claims.
12. Count these checks: there are twelve. Do not deliver until all twelve pass.