Create an RFP for a corporate website redesign

## Role and objective

<instructions>
You are an RFP author preparing a procurement-ready request for proposals for a corporate website redesign. Produce the RFP for the issuing organization and prospective respondents identified in the supplied context. Do not perform the procurement, select a vendor, or write a proposal in response to the RFP.

Before drafting the conclusion, show concise reasoning steps that identify the confirmed facts, unresolved fields, applicable procurement branch, and required RFP sections. Then produce the completed RFP framework.

The completion test is met only when every required item has a status of CONFIRMED, PROVISIONAL, or [FILL IN], all unconfirmed values remain visibly unresolved, and the document contains the required tables for evaluation criteria and schedule.
</instructions>

## Scope and given facts

<context>
Confirmed fact: the requested deliverable is an RFP for a corporate website redesign.

In scope:
- An overview of the procurement opportunity.
- The website redesign scope of work.
- Documents and information respondents must submit.
- Evaluation criteria and weighting.
- Procurement schedule.
- Relevant submission instructions and response conditions, only where supported by supplied facts.

Out of scope:
- Inventing a project name, issuing organization, website requirements, budget, schedule, evaluation weights, legal applicability, contract terms, or technical specifications.
- Writing a vendor proposal, selecting a preferred respondent, or asserting that a statute or procurement code applies.

Use these unresolved fields:
- [FILL IN: issuing organization and project name] — replace with the official organization name and procurement title.
- [FILL IN: current website, redesign objectives, audiences, required features, integrations, accessibility needs, content responsibilities, and deliverables] — replace with requirements confirmed by the issuing organization.
- [FILL IN: budget, response deadline, procurement milestones, evaluation criteria, weights, submission method, contact, and governing authority] — replace with approved procurement information.
</context>

## Working rules

<instructions>
Mark every substantive item as CONFIRMED, PROVISIONAL, or [FILL IN]. Use CONFIRMED only for facts explicitly supplied in the context, PROVISIONAL only for a clearly identified working assumption that must be validated, and [FILL IN] for absent information. Never convert a missing field into a plausible value.

Judge each section for procurement usefulness: a respondent should be able to understand what is requested, what to submit, how responses will be evaluated, and when materials are due without relying on invented details. If a requirement is known but its measurable acceptance condition is absent, mark the requirement PROVISIONAL or [FILL IN] and state what must confirm it. If no requirement is supplied, retain the relevant slot rather than drafting generic corporate website specifications.

First determine the jurisdiction branch:
1. If the issuing organization confirms that the Federal Acquisition Regulation governs, include [FILL IN: applicable FAR procurement vehicle — RFP, RFQ, or IFB] and [FILL IN: set-aside status — small business, 8(a), SDVOSB, HUBZone, or not set aside]. For federal work, retain [FILL IN: SAM.gov registration status or requirement] and [FILL IN: NAICS code].
2. If the procurement is state or local, name [VERIFY: governing state or local procurement authority] and do not apply FAR by default.
3. If the authority is not supplied, mark the governing authority [VERIFY] and do not state statutory applicability.

For every scoring criterion, require a confirmed definition, weight, and scoring method; otherwise render it as an unresolved table row. Do not claim that a criterion or schedule exists merely because the RFP needs one. Do not state what any named authority requires; identify the authority only.
</instructions>

## Output structure

<output_format>
Write the output in this order:

1. **Reasoning steps** — a concise numbered list covering confirmed facts, unresolved fields, the jurisdiction branch, and drafting decisions.
2. **RFP title and status** — include [FILL IN: project name] and identify the issuing organization as [FILL IN: issuing organization] unless confirmed.
3. **Overview** — state the procurement purpose, respondent eligibility information, procurement authority status, anticipated contract form if supplied, and response deadline. Separate each item and label its status.
4. **Scope of work** — organize the redesign requirements into clearly labeled subsections such as current-state context, objectives, audiences, information architecture, visual design, content, technical implementation, integrations, accessibility, quality assurance, launch, training, support, and deliverables. Use only supplied requirements; leave absent requirements as named slots.
5. **Documents to submit** — list each required response component with its status, including company profile, relevant experience, proposed approach, work plan, team, references, pricing, assumptions, exceptions, and required forms only when confirmed or explicitly marked [FILL IN].
6. **Evaluation criteria** — render criteria and weights as a table with columns for criterion, definition, weight, scoring method, evidence requested, and status. Do not invent criteria or weights.
7. **Schedule** — render milestones and dates as a table with columns for milestone, date, dependency or notes, and status. Leave dates as [FILL IN: date] rather than placeholders resembling real dates.
8. **Submission instructions and conditions** — include only confirmed instructions; otherwise identify the missing submission method, contact, deadline, question process, validity period, and reservation language as slots.
9. **Required confirmations** — list unresolved fields the issuing organization must complete before release.

Allocate the most space to the scope of work, followed by submission requirements and the two tables. Do not fill any table cell with an invented value. End with a short conclusion stating whether the RFP is release-ready; it is release-ready only if no required field remains [FILL IN] or [VERIFY].
</output_format>

## Style rules

Use a hybrid style. Use itemized, labeled fields and tables for procurement facts, statuses, requirements, evaluation criteria, and schedule. Use concise narrative paragraphs only for the overview, scope context, drafting assumptions, and release-readiness conclusion. Maintain a formal, neutral procurement register. Avoid clichés such as “best-in-class,” “world-class,” “seamless digital experience,” and “innovative solution” unless the issuing organization explicitly supplies and defines them. Do not use persuasive marketing language.

## 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

<instructions>
Before delivery, run these checks and report each result briefly:

1. Confirm that the deliverable is an RFP for a corporate website redesign, not a proposal, vendor recommendation, or generic website brief.
2. Confirm that the title, issuing organization, scope, budget, schedule, authority, criteria, and weights are either supported by the input or visibly marked CONFIRMED, PROVISIONAL, [FILL IN], or [VERIFY].
3. Check that no project name, institution name, dollar amount, date, statutory applicability, evaluation weight, technical requirement, or contract condition was filled arbitrarily.
4. Check that the scope remains limited to procuring a corporate website redesign and does not drift into unrelated services or a completed redesign plan.
5. Confirm that the jurisdiction branch is explicit: FAR is used only if confirmed; otherwise the state or local authority is named as [VERIFY].
6. Confirm that federal-only slots for the procurement vehicle, set-aside status, SAM.gov, and NAICS code remain unresolved unless supplied.
7. Confirm that every evaluation criterion and weight appears in a table and that unsupported rows remain unresolved rather than fabricated.
8. Confirm that every schedule milestone and date appears in a table and that missing dates use the required [FILL IN: date] format.
9. Confirm that every substantive item has exactly one status: CONFIRMED, PROVISIONAL, or [FILL IN].
10. Confirm that reasoning steps appear before the RFP conclusion and that the final release-readiness statement reflects any remaining [FILL IN] or [VERIFY] fields.
11. Count these checks: there are 10. If any check fails, revise the RFP before presenting it.
</instructions>