Write an RFP for adopting a customer data analytics platform

## Role and objective

You are an RFP architect and procurement researcher. Produce a complete, source-grounded request for proposal for adopting a customer data analytics platform, addressed to prospective vendors and usable by the issuing organization. The document must define the procurement opportunity, required vendor response, evaluation method, and procurement schedule without inventing unconfirmed project facts. The output must be a plain Markdown RFP whose every required item is either supported by the input, marked with a confirmation state, or left as a clearly labelled slot. Completion is achieved only when the RFP contains all required item names and filling instructions, with criteria and schedule rendered as tables and no fabricated project details.

## Scope and given facts

In scope:

- Adoption of a customer data analytics platform.
- An RFP structure covering overview, scope of work, documents to submit, evaluation criteria with weights, and schedule.
- Vendor-facing instructions for responding.
- Research needed to identify relevant procurement context, where sources are available and applicable.

The only confirmed project fact is the subject: adopting a customer data analytics platform. Treat the project name, issuing organization, procurement jurisdiction, customer population, data sources, integrations, deployment model, security requirements, implementation timeline, contract term, budget, evaluation weights, submission deadline, and contact details as unconfirmed.

Use these slots and explain how each is completed:

- `[FILL IN: project name]` — supplied by the issuing organization.
- `[FILL IN: issuing organization and point of contact]` — supplied by the procurement owner.
- `[FILL IN: jurisdiction and governing authority]` — confirmed by procurement counsel or the responsible authority.
- `[FILL IN: platform requirements and data sources]` — supplied by the business and technical owners.
- `[FILL IN: budget, schedule, contract term, and evaluation weights]` — confirmed by the authorized procurement team.

Do not fill the customer data analytics platform RFP with plausible values merely to make it appear complete.

## Working rules

1. Mark every substantive item as `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`. Use `CONFIRMED` only for the stated subject or information supported by a cited source. Use `PROVISIONAL` for a proposed structure or wording that requires approval. Use `[FILL IN]` for missing project-specific information.
2. Never guess the budget, schedule, institution name, procurement authority, statutory applicability, contract duration, scoring weights, technical specifications, or vendor obligations. Under each slot, state who must supply or confirm it.
3. Ask whether the Federal Acquisition Regulation governs this procurement. If it does, leave slots for the applicable vehicle—RFP, RFQ, or IFB—and whether the procurement is set aside for small business, 8(a), SDVOSB, or HUBZone. If it does not, identify the state, local, or other governing authority as `[VERIFY: governing procurement authority]`; do not assume FAR applies.
4. For federal work, leave `[FILL IN: SAM.gov registration requirement]` and `[FILL IN: NAICS code]` as slots. For state or local work, leave the applicable authority as `[VERIFY: governing authority]` until confirmed.
5. Define requirements in observable terms. Distinguish mandatory requirements, desirable capabilities, implementation services, data governance, security, privacy, support, training, accessibility, integration, reporting, and acceptance testing only when the issuer confirms they belong in scope or labels them as provisional.
6. If research is needed, use verifiable sources and identify the source, publication date, jurisdiction, and relevance. Do not invent authorities, procurement rules, certifications, platform capabilities, case studies, or compliance requirements.
7. If a requirement is legally or operationally uncertain, present branches: if the named authority governs, include the corresponding confirmation slot; if another authority governs, replace it with that authority’s confirmed process. Do not state what an authority requires unless the requirement is verified.
8. Keep evaluation criteria measurable and traceable to the stated scope. Do not assign weights until `[FILL IN: evaluation weights]` is confirmed. Do not create a schedule until `[FILL IN: procurement dates]` is supplied.

## Output structure

Produce the RFP in this order:

1. **Overview** — include the project name, issuing organization, procurement purpose, procurement authority, procurement vehicle, eligibility, and point of contact. Provide a one-line filling instruction for every unconfirmed item.
2. **Scope of Work** — organize the requested platform adoption into requirements categories. For each category, identify the requirement, its status, the evidence vendors must provide, and the acceptance or confirmation method. Leave platform-specific requirements as slots where the input does not define them.
3. **Documents to Submit** — list the required proposal sections and instruct vendors what each must contain. Include administrative, technical, implementation, security, privacy, pricing, references, exceptions, and required certifications only as confirmed or provisional items.
4. **Evaluation Criteria** — render as a table with columns for criterion, description, evidence requested, status, and weight. Use `[FILL IN: weight]` for every unconfirmed weight and state that the issuing authority must approve the weighting.
5. **Schedule** — render as a table with milestone, date, status, and source of confirmation. Use `[FILL IN: date]` for every missing date; do not infer dates from typical procurement timelines.
6. **Submission and Contract Conditions** — include only confirmed or provisional instructions, with slots for delivery method, deadline, contract terms, negotiation rights, and governing authority.
7. **Definitions and Attachments** — list terms requiring definition and attachments the issuer must provide. Do not fabricate attachment names or contents.

Use tables for the evaluation criteria and schedule. Write item names and instructions for filling them; do not populate unconfirmed project content.

## Style rules

Use a hybrid style: use concise, itemized lists and tables for fields, requirements, submission documents, evaluation criteria, and schedule; use short narrative paragraphs for the procurement purpose, scope framing, vendor instructions, and status explanations. Maintain a formal, neutral procurement register. Avoid promotional language, vague phrases such as “best-in-class,” unsupported claims, unnecessary legal conclusions, and technology buzzwords that do not identify a verifiable requirement.

## 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 adopting a customer data analytics platform, not a platform recommendation, business case, or vendor proposal.
2. Confirm that every required item—overview, scope of work, documents to submit, evaluation criteria with weights, and schedule—is present.
3. Check that every project-specific fact beyond the supplied subject is marked `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`.
4. Check specifically that the project name, issuing organization, budget, dates, procurement vehicle, governing authority, and evaluation weights were not filled with invented values.
5. Confirm that every `[FILL IN]` slot states what information fills it and who should confirm it where relevant.
6. Confirm that FAR applicability was asked, and that vehicle and set-aside slots appear if federal procurement is possible.
7. Confirm that SAM.gov registration and NAICS code remain slots for federal work.
8. Confirm that state or local procurement is not treated as governed by FAR without verification.
9. Confirm that evaluation criteria and schedule are tables and contain no guessed weights or dates.
10. Check that the scope stays within customer data analytics platform adoption and does not silently add unrelated products, services, agencies, or legal obligations.
11. Check that research references, if used, are real, identifiable, relevant, and not presented as proof of requirements they do not establish.
12. Confirm that the hybrid style is applied: tables and lists for structured fields, short narrative paragraphs for framing, and no unsupported promotional claims.