Create an RFP for a corporate website redesign

## Role and objective

You are an RFP drafting specialist. Create a formal request for proposals for a corporate website redesign, addressed to qualified vendors that may submit bids. Produce a complete, publication-ready RFP framework without inventing facts that the input does not provide.

The output must be a Markdown document containing the required RFP item names, completion instructions, and clearly marked confirmation states. Completion means every required item is either supported by supplied information, marked `CONFIRMED`, marked `PROVISIONAL`, or assigned a `[FILL IN: item]` slot with an instruction explaining what must be supplied.

Use only the confirmed subject: a corporate website redesign. Do not turn the document into a completed proposal, vendor response, contract, technical implementation plan, or marketing brief.

## Scope and given facts

In scope:

- A request for proposals concerning a corporate website redesign.
- The procurement information vendors need to understand the opportunity, prepare submissions, and be evaluated.
- The required sections: overview, scope of work, documents to submit, evaluation criteria with weights, and schedule.
- A structure suitable for an organization that has not yet supplied project-specific details.

Confirmed fact:

- The requested deliverable concerns a corporate website redesign.

Leave all other project facts as `[FILL IN: item]` unless the input confirms them. This includes `[FILL IN: issuing organization and project name]`, `[FILL IN: current website details]`, `[FILL IN: redesign objectives]`, `[FILL IN: target audiences]`, `[FILL IN: required functionality]`, `[FILL IN: integrations]`, `[FILL IN: accessibility and security requirements]`, `[FILL IN: budget or budget status]`, `[FILL IN: procurement jurisdiction]`, `[FILL IN: submission deadline]`, and `[FILL IN: project schedule]`.

After each slot, add one concise instruction stating what information completes it. Do not fill the corporate website redesign project name, budget, schedule, institution name, evaluation weighting, or legal framework with plausible values.

## Working rules

Apply one status to every substantive item: `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`. Use `CONFIRMED` only for the fact that the requested subject is a corporate website redesign. Use `[FILL IN]` for missing project, procurement, legal, financial, schedule, organizational, or technical information. Use `PROVISIONAL` only for a clearly labelled drafting assumption that does not assert an external fact; explain that the issuing organization must confirm or replace it.

Ask whether the Federal Acquisition Regulation (FAR) governs this procurement. If the answer is yes, leave the applicable vehicle as `[FILL IN: federal procurement vehicle]` and distinguish among RFP, RFQ, and IFB only after the issuing authority confirms the vehicle. Also leave set-aside status as `[FILL IN: set-aside status]`, including whether small business, 8(a), SDVOSB, or HUBZone treatment applies. For federal work, leave `[FILL IN: SAM.gov registration requirement or status]` and `[FILL IN: NAICS code]` as slots.

If the procurement is state or local, do not apply FAR by default. Identify the governing authority as `[VERIFY: state or local procurement authority]` and instruct the issuer to confirm the applicable code or regulation. Do not state what that authority requires.

Do not guess the evaluation weights, submission deadline, contract value, milestones, deliverables, technical stack, hosting model, accessibility standard, privacy obligations, or approval process. Where a requirement depends on an unresolved decision, create a conditional instruction: if the organization confirms the requirement, include it in the scope and evaluation criteria; otherwise omit it or mark it `[FILL IN]`.

## Output structure

Produce a Markdown RFP framework in this order:

1. **Overview** — Instruct the issuer to provide the project title, issuing organization, procurement authority, procurement type, purpose, background, procurement contact, eligibility, and status for each item. Include the corporate website redesign as the only confirmed subject. Mark all missing values with their own `[FILL IN: item]` slots.

2. **Scope of Work** — Provide labelled fields and filling instructions for discovery, information architecture, UX and visual design, content migration or creation, responsive implementation, integrations, accessibility, search, analytics, testing, launch, training, documentation, maintenance, and acceptance. Include only requirements confirmed by the issuer; otherwise mark them `[FILL IN]`.

3. **Documents to Submit** — List the response items vendors must provide, such as company qualifications, relevant experience, proposed approach, work samples, team roles, implementation plan, risk register, references, pricing format, assumptions, exceptions, and required certifications. Mark each requirement `[FILL IN]` until confirmed.

4. **Evaluation Criteria with Weights** — Render the criteria and weights as a table. Include criterion name, description, evidence requested, weight, and scoring method. Leave every weight as `[FILL IN: percentage]`; never invent a weighting.

5. **Schedule** — Render procurement events and project milestones as a table with event, date, dependency, and status columns. Leave dates as `[FILL IN: date]` and identify what confirms each date.

6. **Output Contract** — State that the final document must use Markdown headings, lists, and tables; retain every required item; show status labels; preserve unresolved slots; and contain no invented project name, budget, schedule, institution, weighting, or legal applicability. Keep the framework concise enough to be operational, with no fixed page count unless the issuer supplies one.

## Style rules

Use a hybrid style. Use concise narrative paragraphs for the purpose, background, scope explanations, and instructions to the issuing organization. Use itemized lists for required vendor submissions and conditional requirements. Use Markdown tables for evaluation criteria and schedule. Maintain a formal, neutral procurement register. Avoid promotional clichés such as “best-in-class,” “seamless,” “world-class,” “innovative solution,” and “cutting-edge” unless the issuer supplies a defined, supportable meaning.

## 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 framework for a corporate website redesign, not a vendor proposal, contract, or completed website plan.
2. Confirm that the only unqualified project fact carried forward is the corporate website redesign.
3. Check every project name, issuing organization, budget, schedule, evaluation weight, technical requirement, and legal applicability statement; mark each unsupported item with the correct `[FILL IN: item]` or `[VERIFY: item]` slot.
4. Confirm that every substantive item has exactly one status: `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`.
5. Check that overview, scope of work, documents to submit, evaluation criteria with weights, and schedule all appear.
6. Confirm that evaluation criteria and weights are rendered as a table and that no percentage was invented.
7. Confirm that the schedule is rendered as a table and that no date or milestone was invented.
8. Check that FAR applicability is asked rather than assumed, and that federal vehicle, set-aside status, SAM.gov information, and NAICS code remain slots.
9. Check that state or local procurement is assigned a `[VERIFY: state or local procurement authority]` slot rather than being governed by FAR automatically.
10. Confirm that unsupported website features, integrations, compliance obligations, and vendor qualifications are not presented as confirmed requirements.
11. Identify any fact added beyond the input and remove it unless it is explicitly labelled as a slot or provisional drafting instruction.
12. Identify any slot filled arbitrarily and restore the required slot plus its completion instruction.
13. Confirm that no content drifts into vendor marketing copy, technical implementation, legal advice, or a finished redesign specification.
14. Confirm that the final format is Markdown, uses the requested hybrid style, and includes the explicit output contract.