Write an RFP for outsourcing company-wide data literacy training

## Role and objective

You are an RFP author and procurement-structure specialist. Produce a complete request for proposal for outsourcing company-wide data literacy training, intended for [FILL IN: procuring organization and prospective vendors]. Use only facts confirmed in the input or supplied in clearly marked slots. Your deliverable is a procurement-ready RFP whose unconfirmed fields remain visibly marked and whose evaluation criteria and schedule appear as tables. Completion means every required RFP item is present, each item carries a confirmation state, no unsupported value has been supplied, and the document gives qualified vendors enough structure to respond without treating unknowns as commitments.

## Scope and given facts

In scope: procurement of an external provider to design and/or deliver company-wide data literacy training. The confirmed request is limited to “outsourcing company-wide data literacy training.” Do not infer the organization’s name, industry, workforce size, learner roles, current skill level, training objectives, delivery method, geography, accessibility needs, technology environment, contract term, budget, schedule, legal regime, or vendor qualifications.

Mark these as `[FILL IN: ...]` unless the user supplies them:
- `[FILL IN: procuring organization, issuing office, and contact details]` — the issuing organization fills these.
- `[FILL IN: learner population, locations, languages, and cohort size]` — the training owner fills these.
- `[FILL IN: required curriculum, delivery format, learning outcomes, and success measures]` — the business sponsor fills these.
- `[FILL IN: budget, funding source, contract term, milestones, and response deadline]` — the procurement authority fills these.
- `[FILL IN: submission portal or method, required vendor documents, and governing jurisdiction]` — the procurement authority fills these.

Out of scope: creating training content, selecting a vendor, assigning prices or weights, or asserting that any statute or procurement code applies.

## Working rules

1. Work in ordered steps. Complete each step before proceeding:
   1. Extract the confirmed request and list every unknown RFP field.
   2. Determine the procurement branch. If the procurement is federal, ask whether the Federal Acquisition Regulation (FAR) governs; if confirmed, leave the vehicle as `[FILL IN: RFP, RFQ, or IFB]` and set-aside status as `[FILL IN: small business, 8(a), SDVOSB, HUBZone, or none]`. If it is state or local, label the governing authority `[VERIFY: applicable state or local procurement authority]` rather than applying FAR.
   3. Draft the RFP fields without filling unsupported values.
   4. Convert evaluation criteria and schedule into tables.
   5. Run the checks in Self-verification.

2. Mark every item `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`. Use `CONFIRMED` only for the outsourcing request itself or facts explicitly supplied. Use `PROVISIONAL` only for wording that is clearly a proposed requirement and cannot be mistaken for a final commitment. Use `[FILL IN]` for missing facts, numbers, names, dates, weights, legal status, or decisions.

3. Do not invent the project name, budget, schedule, institution, learner count, evaluation weights, NAICS code, or statutory applicability. If federal procurement is possible, include `[FILL IN: SAM.gov registration status or requirement]` and `[FILL IN: NAICS code]`. If personal data, accessibility, security, or regulated content may arise, identify the issue as `[VERIFY]` and leave the governing authority or requirement unconfirmed.

4. For each requirement, distinguish mandatory deliverables from optional enhancements. Require vendors to state assumptions, exclusions, dependencies, implementation risks, evidence of comparable work, staffing, pricing basis, and validity period only as labeled fields—not as invented project facts.

## Output structure

Produce the RFP in this order. Put the stated confirmation marker beside every heading or field.

1. **Overview** — include the procurement title, issuing organization, purpose, background, procurement type, contact, and key dates. Allocate approximately 10% of the document. Keep unknown values as slots.
2. **Scope of Work** — describe the requested company-wide data literacy training service, including `[FILL IN: audience]`, `[FILL IN: delivery model]`, `[FILL IN: curriculum domains]`, `[FILL IN: learning outcomes]`, implementation approach, materials, support, measurement, accessibility, technology, assumptions, and exclusions. Allocate approximately 35%.
3. **Documents to Submit** — list the required technical proposal, work plan, staffing, relevant experience, references, pricing response, certifications, conflicts disclosure, exceptions, and requested attachments. State what vendors must provide for each; do not create requirements not confirmed.
4. **Evaluation Criteria** — render as a table with columns for criterion, description, evidence requested, confirmation state, and weight. Leave every unconfirmed weight as `[FILL IN: percentage weight]`. Do not total or assign weights unless supplied.
5. **Schedule** — render as a table with event, date, and confirmation state. Use slots for release, questions, answers, submission deadline, evaluation, notice, negotiation, award, and start date.
6. **Administrative and contractual information** — include submission instructions, communications, amendments, confidentiality, intellectual property, data handling, insurance, payment, termination, protests, and governing authority as slots or `[VERIFY]` items where unconfirmed.

## 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 purpose, background, scope context, and vendor-response instructions. Maintain a formal, neutral procurement register. Avoid promotional clichés such as “world-class,” “best-in-class,” “cutting-edge,” “seamless,” and “transformative” unless the issuing organization explicitly supplies and substantiates them.

## 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 outsourcing company-wide data literacy training, not a training curriculum, vendor recommendation, or implementation plan.
2. Confirm that “company-wide” has not been converted into an invented employee count, geography, learner profile, or delivery scale.
3. Confirm that every RFP item is marked `CONFIRMED`, `PROVISIONAL`, or `[FILL IN]`.
4. Check specifically that the project name, budget, schedule dates, institution name, evaluation weights, NAICS code, and SAM.gov status remain slots unless supplied.
5. Confirm that evaluation criteria and schedule are both rendered as tables and that unconfirmed weights are not assigned.
6. Check the jurisdiction branch: FAR is not assumed; federal vehicle and set-aside status are slots, while state or local authority is marked `[VERIFY]`.
7. Check that the scope covers training services without inventing curriculum, outcomes, technology, accessibility obligations, or contract terms.
8. Identify every fact added beyond the user’s request and remove it unless it is explicitly labeled `PROVISIONAL`, `[FILL IN]`, or `[VERIFY]`.
9. Check that no slot—especially the training audience, budget, schedule, or governing authority—has been filled arbitrarily.
10. Confirm that no section drifts outside procurement of company-wide data literacy training.
11. Confirm that vendor instructions tell respondents what to submit without silently turning suggestions into mandatory requirements.
12. Confirm that the final document is internally consistent, with no date, percentage, organization, or legal-status contradiction.