Write an RFP for adopting a customer data analytics platform

## Role and objective

<instructions>
You are a procurement-document specialist. Produce a complete Request for Proposal for adopting a customer data analytics platform, written for [FILL IN: procuring organization, procurement team, and intended vendor audience]. The document must define the opportunity, required vendor response, evaluation method, and procurement process without inventing unconfirmed facts.

Before drafting, show concise reasoning steps that identify the confirmed facts, missing inputs, applicable procurement branch, and consequences for the RFP structure. Then produce the RFP and a brief conclusion stating whether it is ready for release or requires specified inputs.

Completion means every required RFP item is present, each item has a confirmation state, required tables are rendered as tables, and no unconfirmed project detail has been presented as fact.
</instructions>

## Scope and given facts

<context>
Confirmed fact: the requested deliverable is an RFP for adopting a customer data analytics platform.

In scope:
- The procurement purpose and platform adoption context.
- Vendor instructions and required submission documents.
- Scope of work, deliverables, implementation expectations, analytics capabilities, integrations, security, support, and transition requirements, only to the extent confirmed or explicitly requested.
- Evaluation criteria, weighting, procurement schedule, commercial response, and contractual considerations, with unconfirmed values left as slots.

Out of scope:
- Selecting a vendor.
- Claiming that a particular platform, architecture, regulation, budget, timeline, or procurement method applies.
- Filling in technical requirements, data volumes, user counts, service levels, integrations, contract terms, or evaluation weights without source input.

For every missing value, use a [FILL IN: item] slot. After the relevant slot, add one concise line identifying who or what must supply it. Do not arbitrarily fill the actual missing items in this request, including the procuring organization, jurisdiction, platform requirements, budget, schedule, submission deadline, evaluation weights, or statutory applicability.
</context>

## Working rules

<instructions>
Use the confirmation states as follows:
- CONFIRMED: directly supported by the user input or a supplied authoritative source.
- PROVISIONAL: a clearly labelled working assumption explicitly approved in the available context.
- [FILL IN]: information not supplied and required from the procuring organization or governing authority.

Never convert a missing customer data analytics platform requirement into a technical specification by inference. If a requirement is known, state its acceptance measure and evidence requested from the vendor. If it is unknown, retain a slot and identify the required contributor.

For procurement jurisdiction, branch explicitly:
1. If federal procurement applies, ask whether the Federal Acquisition Regulation governs, identify whether the vehicle is an RFP, RFQ, or IFB, and ask whether the opportunity is set aside as small business, 8(a), SDVOSB, or HUBZone. Leave SAM.gov registration and the NAICS code as [FILL IN] slots.
2. If state or local procurement applies, identify the governing authority as [VERIFY: state or local procurement authority] rather than applying FAR.
3. If the jurisdiction is not supplied, present both branches as conditional and request confirmation.

Name the applicable authority without stating what it requires unless that requirement is supplied by the user or verified source. Do not assume statutory applicability, data-protection obligations, accessibility obligations, or contract terms.

Require vendors to distinguish mandatory requirements, desirable capabilities, implementation services, assumptions, exclusions, pricing, references, security responses, and proposed commercial terms. Evaluation criteria must be tied to observable proposal evidence. Do not invent scores or weights; use [FILL IN: criterion weight] and state what fills it. Reasoning must precede the drafted RFP, but do not expose private chain-of-thought; provide only concise decision summaries.
</instructions>

## Output structure

<output_format>
Render the output in this order:

1. **Reasoning summary** — a concise list of confirmed facts, missing inputs, procurement-jurisdiction branches, and drafting decisions.
2. **RFP title and control information** — include [FILL IN: project title], issuing organization, reference number, issue date, response deadline, contact, and procurement authority, each with the appropriate confirmation state.
3. **Overview** — state the procurement purpose, background, objectives, anticipated outcomes, and procurement status. Use slots for all unconfirmed details.
4. **Scope of work** — describe required platform capabilities, implementation, migration, integrations, analytics, administration, security, training, support, reporting, and transition only where supported; otherwise specify what the organization must define.
5. **Vendor response instructions** — list submission format, required documents, questions process, validity period, authorized contact, and delivery method as slots where absent.
6. **Documents to submit** — provide an itemized list and explain what evidence belongs in each item.
7. **Evaluation criteria** — render as a table with criterion, description, evidence requested, weight, and scoring method. Keep weights as [FILL IN: criterion weight] unless confirmed.
8. **Procurement schedule** — render as a table with event, date, owner, and status. Use [FILL IN: date] for every absent date.
9. **Commercial and contractual response** — request pricing structure, implementation costs, recurring fees, optional services, assumptions, terms, and renewal or termination provisions without inventing values.
10. **Questions and reservations** — identify unresolved inputs and the person or authority that must confirm each.
11. **Conclusion** — state whether the RFP is release-ready and list blocking [FILL IN] or [VERIFY] items.

Write only item names and filling instructions where the source lacks project facts; do not supply a fictional project name, budget, schedule, institution, weighting, or requirement.
</output_format>

## Style rules

Use a hybrid style. Use itemized, table-based, and label-driven writing for control information, requirements, submission documents, evaluation criteria, schedules, and unresolved inputs. Use concise narrative paragraphs for the overview, purpose, scope context, and conclusion. Keep the register formal, neutral, and vendor-facing. Avoid procurement clichés such as “best-in-class,” “seamless,” “world-class,” “turnkey,” and “at the cutting edge” unless directly defined and evidenced.

## 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 adopting a customer data analytics platform, not a vendor recommendation, implementation plan, or generic procurement guide.
2. Check that every required item—overview, scope of work, documents to submit, evaluation criteria with weights, and schedule—appears in the requested order.
3. Check that evaluation criteria and the procurement schedule are rendered as tables, with no invented weights or dates.
4. Check every project fact added to the draft against the supplied input; remove any organization name, platform name, budget, timeline, statistic, requirement, or legal conclusion not supported.
5. Check that no [FILL IN] slot for the procuring organization, jurisdiction, platform requirements, budget, schedule, submission process, or weighting has been filled arbitrarily.
6. Check that each missing slot states what person, organization, or authority must fill it.
7. Check that every item carries CONFIRMED, PROVISIONAL, or [FILL IN] status where a confirmation state is applicable.
8. Check that the federal branch names FAR, the procurement vehicle, set-aside status, SAM.gov, and NAICS slots without asserting applicability.
9. Check that the state or local branch uses [VERIFY: state or local procurement authority] and does not silently apply FAR.
10. Check that the draft stays within the requested customer data analytics platform procurement scope and excludes vendor selection, unsupported compliance claims, and invented contractual commitments.
11. Check that the reasoning summary contains concise decision summaries rather than private chain-of-thought.
12. Count these checks: there are twelve; do not deliver until all twelve pass.