# Usage: curl -sSL https://seed.show/procurement.rfp.sourcing | bash -s <install-path>
# <install-path> is the directory where the file should land.

set -euo pipefail
[ -z "${1:-}" ] && {
  echo "install requires a path: curl -sSL https://seed.show/procurement.rfp.sourcing | bash -s <install-path>" >&2
  exit 1
}
TARGET="$1"
mkdir -p "$TARGET"
DEST="$TARGET/seed-fold.VOfirG.folded.md"

cat > "$DEST" <<'PORTDOWN_4FFDD3A0'
<!--
This is a `.folded.md` archive — a directory packed into one markdown
file. The markers below are load-bearing; don't edit them directly.

To unpack (requires bash — if you have no shell, tell the user):
  1. curl -sSLf https://fold.dom.vin/skill | bash -s <INSTALL_DIR>
  2. <INSTALL_DIR>/fold/scripts/unfold <this-file>
     (or: unfold <this-file>  if fold/scripts is on your PATH)
-->

---
fold: true
marker: 3d0ed4
at: 2026-05-07T16:16:21Z
root: seed-pack.AprIBr
---

<!--fold:3d0ed4@file path="README.md" mode="644"-->
# Procurement, RFP, and Vendor Sourcing — Agent Context

## What level of procurement and what not to do

This seed covers the structural logic of competitive sourcing and RFP-based vendor selection — applicable across commercial and public sector contexts. It does not hold specific procurement thresholds, mandatory competitive-bidding floors, or regulatory requirements by jurisdiction. Those vary by entity type, geographic jurisdiction, contract type, and funding source: a US federal agency follows FAR; a US state agency follows its own procurement code; a UK public body follows the Procurement Act 2023 (successor to PCR 2015/Public Contracts Regulations); a commercial enterprise has no mandatory framework but significant litigation exposure if processes are inconsistently applied.

**Do not state specific thresholds as facts.** Instead, point to the authoritative source for the entity in question (FAR, state procurement manual, NIGP guidelines, etc.) and instruct the user to verify current figures there. Thresholds change; cached numbers mislead.

What this seed provides: the structural logic of procurement as a risk management process, the RFI/RFQ/RFP distinction, evaluation methodology design, and the failure modes that produce vendor selection regret. These are stable across jurisdictions; the numbers are not.

---

## What procurement is actually optimizing for

Procurement is not a cost-cutting function. It is a risk and value management function that uses cost as one of several instruments. The three things procurement actually optimizes for — in order of long-term organizational weight — are:

**1. Total cost of ownership (TCO), not purchase price.**
The sticker price is a fraction of what a vendor relationship will cost. TCO includes: implementation and integration labor, licensing growth as usage scales, training and change management, ongoing support and maintenance, switching costs if the relationship ends, and the cost of vendor failure (breach, acquisition, shutdown). A vendor that is 20% cheaper at contract signature is often more expensive at year three. Agents that optimize for purchase price alone are solving the wrong problem.

**2. Risk reduction, not just savings.**
Every vendor relationship is a risk transfer arrangement. Procurement evaluates: does this vendor have the operational continuity to deliver on a 3-year contract? What is their concentration risk (do they depend on a single supplier for critical components)? What happens to our operations if they are acquired, go out of business, or are breached? A vendor evaluation that does not include financial stability, security posture, and business continuity planning is not complete procurement — it is purchasing.

**3. Strategic fit.**
Some vendor relationships are transactional (commoditized inputs, readily substitutable, low switching cost). Others are strategic (deep integration, vendor-specific workflows, switching cost measured in years). Procurement treats these differently: transactional sourcing optimizes for price and standardization; strategic sourcing optimizes for relationship quality, roadmap alignment, and contractual protections. Agents who apply the same evaluation template to office supplies and enterprise software are conflating categories with materially different stakes.

---

## The RFP as a requirements specification, not a price auction

The most consequential framing error agents make is treating the RFP as a mechanism for extracting the lowest price from competing vendors. It is not. The RFP is a **requirements specification**: it defines what the organization needs, establishes how proposals will be evaluated, and creates the structure for a fair and defensible selection process.

This distinction has practical consequences:

- **Requirements quality determines outcome quality.** A poorly specified RFP produces proposals that are technically responsive but operationally useless — vendors respond to what is written, not what is meant. Vague requirements beget vague proposals beget selection regret.
- **Evaluation criteria must be defined before proposals arrive.** Defining scoring weights after seeing proposals introduces bias (conscious or unconscious) toward a predetermined vendor. Pre-defined, weighted criteria make the selection auditable and defensible to stakeholders who did not participate in the evaluation.
- **The RFP creates legal exposure.** Requirements stated in the RFP that are not actually evaluated — or criteria applied inconsistently — can expose the organization to vendor challenges and, in government procurement, formal protests.

---

## RFI / RFQ / RFP — when each applies

These three document types are routinely conflated. They are not interchangeable:

| Document | Purpose | When to use | Output |
|---|---|---|---|
| RFI (Request for Information) | Market research — understand what the market offers before writing requirements | Early in sourcing, when requirements are unclear or the market landscape is unknown | Vendor landscape, capability overview, rough pricing ranges — not binding |
| RFQ (Request for Quotation) | Price comparison for well-defined, standardized purchases | When requirements are fully specified, the item is commoditized, and selection will be based primarily on price | Binding price quotes for comparison |
| RFP (Request for Proposal) | Competitive evaluation for complex, non-commoditized purchases where solution design matters | When requirements exist but the solution approach is open, and both technical and commercial factors drive selection | Full proposals evaluated on multiple criteria |

**The most common error: issuing an RFP when you need an RFI.** If you cannot write clear functional requirements, you are not ready for an RFP. Issuing an RFP before requirements are defined forces vendors to guess what you want and forces evaluators to compare proposals that solve different problems.

**The second most common error: issuing an RFP when you need an RFQ.** For commodity purchases — standard hardware, off-the-shelf software at published pricing, consumables — an RFP is procurement theater. It imposes overhead on both sides without adding selection quality. Use an RFQ and be done with it.

---

## What agents get wrong in procurement

### 1. Writing RFPs that favor the current vendor

The incumbent vendor often assists in requirements definition, either directly (they know what they do) or indirectly (requirements are copied from the prior contract). This produces RFPs that are technically neutral but operationally written around the incumbent's capabilities — integration assumptions, terminology, feature sets, and evaluation criteria that non-incumbents structurally cannot meet.

The tell: requirements that describe a current-state workflow rather than a desired outcome. "The system must integrate with [specific tool] using [specific API]" describes what we have. "The system must support bidirectional data synchronization with our CRM with full field mapping, documented API, and sub-5-minute latency" describes what we need. The second form is evaluable across vendors.

### 2. Unclear or post-hoc scoring criteria

Requirements listed without relative weights cannot be evaluated consistently. When every requirement is equally important, nothing is important — evaluators fall back on subjective impression and vendor relationships. Scoring criteria that are defined after proposals are received allow (consciously or not) the weights to be tuned to favor a preferred vendor.

Good procurement practice: scoring methodology is locked before the first proposal is opened. Changes to criteria or weights after proposal receipt require documented justification, stakeholder sign-off, and re-solicitation if the change is material.

### 3. Ignoring implementation and switching costs

Purchase price gets explicit attention. Implementation costs — labor to configure, integrate, and train — are frequently estimated optimistically or not at all. Switching costs — what it would take to exit this vendor relationship in three years — are almost never modeled.

The practical consequence: organizations select the least expensive license only to discover that the total cost of the relationship is higher than a more expensive alternative that included implementation support and had lower integration complexity.

### 4. Treating all vendors as equivalent proposal-writers

Established vendors have dedicated proposal teams. Smaller competitors — who may offer better solutions for the specific problem — often do not. An RFP that rewards proposal polish over solution quality systematically favors incumbents and large vendors. Counter this with structured, scored demos; reference checks against specific use cases; and weighted criteria that explicitly reward demonstrated outcomes over stated capabilities.

### 5. Reference checks as formality

References provided by vendors are curated. They will not provide a reference who will say something damaging. A reference check that follows the vendor's provided list and asks open-ended questions generates no useful information.

Useful reference checks are structured: specific questions, consistent across all finalists, focused on the problems you know you'll face ("tell me about a time the implementation went over timeline — what happened and how did they handle it"), and supplemented by independent outreach to users of the vendor's product who did not appear on the provided list.

### 6. AI-specific failure modes

Agents working on procurement tasks introduce a distinct set of errors beyond the five above:

**Hallucinating compliance standards.** Agents confidently cite regulatory thresholds, mandatory set-aside percentages, and statutory timeframes that are wrong for the jurisdiction, entity type, or fiscal year. Never state thresholds as facts without citing the authoritative source and telling the user to verify currency.

**Generating requirements as a feature dump.** When asked to draft requirements, models tend to produce exhaustive feature lists scraped from vendor marketing — not outcome-based requirements. The result is requirements documents that no solution fully meets and that cannot be weighted or scored. Push back: "What observable outcome must this produce? How would we measure whether it was achieved?"

**Treating the RFP draft as the deliverable.** Agents complete the document and stop. The document is a process artifact. The actual work is requirements quality, scoring design, and evaluation consistency — none of which live in the RFP document itself. A polished RFP with vague requirements is worse than a rough RFP with precise ones, because it passes stakeholder review and enters the market with unfixable gaps.

**Missing the TCO model.** When drafting financial evaluation sections, agents default to license fee comparison tables. Without a TCO model — implementation, integration, ongoing support, exit costs — the comparison is misleading. Produce the model, not just the comparison.

**Applying uniform templates across strategic/transactional categories.** A model that has seen many RFP templates will reuse the same evaluation criteria and weights regardless of category. A 90-day software subscription and a 5-year infrastructure platform do not have the same risk profile and should not be evaluated the same way.

---

## What AI is changing

AI is entering procurement infrastructure across four vectors. Understanding what is genuinely changing — and what is not — prevents both over-reliance and dismissal.

**Automated vendor scoring.** AI tools now ingest large proposal documents and score them against requirements rubrics at scale, reducing the time evaluators spend on initial pass-through triage. The value is real for large solicitations with many vendors and standardized requirements tables. The risk is equally real: scoring rubrics built into the model carry the same bias as manual rubrics, but with less visibility into where the score came from. Human review of AI scores is not optional — it is the control.

**Contract analysis and redlining.** Large-language-model-based contract review tools identify non-standard terms, missing provisions, and risk clauses faster than human review. They are most useful for flagging — identifying where attention is needed — and weakest at judgment calls about whether a flagged term is actually problematic for this organization in this context. The negotiator still decides; the AI reduces the cost of finding what to decide about.

**Spend analytics and tail-spend management.** AI-powered spend analysis platforms classify unstructured purchasing data, identify off-contract spending (tail spend), surface consolidation opportunities, and flag compliance gaps. This is one of the highest-signal procurement applications: the data already exists in ERP and P-card systems, the patterns are detectable at machine speed, and the savings from even modest tail-spend consolidation are material. Category managers should be using these tools; the barrier is data quality and ERP integration, not model capability.

**Supplier risk monitoring.** AI-driven platforms monitor news, financial filings, court records, and supply chain databases to flag vendor instability signals — financial distress, legal exposure, key-person departures, geographic concentration in crisis zones — before they become contract performance problems. The value proposition is proactive, not reactive: catching a supplier solvency signal six months before contract renewal is actionable; catching it at renewal is pressure without leverage.

**What stays human:**

- **Supplier relationships.** Vendor trust, escalation credibility, and the informal information flow that makes strategic partnerships work cannot be automated. The relationship is the channel through which off-contract flexibility happens.
- **Strategic category decisions.** Which categories to insource vs. outsource, which vendors to elevate to strategic partner status, when to sole-source vs. compete — these decisions carry organizational context, political weight, and long-horizon risk that no scoring model captures.
- **Negotiation.** Negotiation is a judgment process about leverage, timing, and relationship. AI can model scenarios and surface leverage points; the negotiator reads the room, manages the dynamic, and decides when to push and when to leave something on the table.
- **Ethical and policy judgment.** Supplier diversity commitments, local sourcing preferences, ESG screening — these are policy positions that require human accountability. An AI that optimizes for TCO without constraint will underweight these considerations every time.
<!--fold:3d0ed4@file path="checklist.md" mode="644"-->
# checklist

RFP construction and vendor evaluation as a decision framework. Not a template to fill in — the load-bearing items in each phase where incomplete work produces vendor selection regret.

The goal at each phase is not documentation but defensibility: is every element locked before the next phase opens? Ambiguity that enters early propagates through the entire process.

---

## Phase 1: Requirements definition

Before writing a single line of the RFP document, requirements must be complete and categorized. An RFP issued before requirements are stable is a market research exercise disguised as a sourcing event.

**Functional requirements**

- What outcomes must the solution produce? State as observable, measurable results — not features. "The system must reduce invoice processing time by 40%" is a functional requirement. "The system must have an AI-powered OCR module" is a feature specification and does not belong in requirements.
- Which requirements are mandatory (must-have) and which are desirable (nice-to-have)? Label explicitly. Every unlabeled requirement will be treated as mandatory by evaluators and as optional by vendors.
- What current-state workflows does the solution need to integrate with or replace? Document the integration points, data formats, and volume expectations — vendors cannot size their response without them.

**Technical requirements**

- Integration constraints: what systems must the solution connect to, what APIs or data formats are in use, and what are the SLA expectations on those integrations?
- Security and compliance requirements: data residency, encryption at rest and in transit, access controls, audit logging, and any regulatory frameworks the vendor must support (SOC 2, ISO 27001, HIPAA, FedRAMP). Do not cite jurisdiction-specific compliance thresholds as facts — verify current requirements against the authoritative regulatory source for your entity type.
- Performance requirements: response time, uptime SLA, concurrent user load, data retention periods. State as testable specifications — "enterprise-grade reliability" is not a technical requirement.

**Commercial requirements**

- Contract term preferences, renewal flexibility, and termination-for-convenience provisions.
- Pricing model compatibility: per-seat, consumption-based, site license, or hybrid — state which models are acceptable and which are not. Incompatible pricing models make proposals non-comparable.
- Implementation support expectations: does the vendor provide professional services, or does the organization provide implementation labor? Ambiguity here produces the largest post-signature budget surprise.

**Stakeholder coverage check**

- Have functional requirements been gathered from all stakeholder groups who will use or be affected by the solution? Requirements that reflect only one perspective (usually IT or finance) produce adoption resistance from the groups who will actually operate the system.
- Have end users been asked what failure modes in the current solution they most need resolved? Requirements extracted from current-state gaps are more reliable than requirements extracted from feature wishlists.
- Is there a named owner for each requirement who can answer vendor clarification questions during the evaluation period?

**Common miss**: Capturing requirements from only one internal stakeholder group (usually IT or finance). Requirements that reflect only one perspective produce an RFP that optimizes for that group's preferences and creates adoption resistance from the groups who will actually use the solution.

---

## Phase 2: Evaluation criteria and scoring design

Evaluation criteria must be defined and weights locked before the RFP is issued. This is not bureaucratic formality — it is the mechanism that makes selection defensible to stakeholders who did not participate in the evaluation, and it is the protection against unconscious bias toward a predetermined vendor.

**Criteria categories**

| Category | Typical weight range | What it covers |
|---|---|---|
| Technical fit | 25–35% | Requirements coverage, integration capability, security posture, scalability |
| Commercial terms | 15–25% | TCO, pricing structure, payment terms, SLA commitments |
| Implementation approach | 15–20% | Timeline, methodology, resource requirements, risk mitigation |
| Vendor stability | 10–15% | Financial health, customer base, support model, product roadmap |
| References and proven outcomes | 10–15% | Reference check results, documented case studies at comparable organizations |

Adjust weights based on the strategic nature of the purchase. For a transactional commodity purchase, weight commercial terms higher. For a strategic platform with 5+ year implementation horizon, weight technical fit and vendor stability higher.

**Scoring rubric design**

Each criterion needs a rubric that can be applied consistently across proposals. A rubric maps a score (e.g., 1–5) to observable, describable response characteristics — not to evaluator impressions.

Example: for "requirements coverage" scored 1–5:
- 5: All mandatory requirements addressed with documented evidence; desirable requirements addressed with approach described
- 4: All mandatory requirements addressed; minor gaps in desirable requirements
- 3: Substantive mandatory requirements addressed; some mandatory gaps with vendor explanation
- 2: Material mandatory requirement gaps; no explanation provided
- 1: Requirements coverage is superficial or non-responsive

Rubrics without this level of specificity produce scores that reflect the evaluator's prior relationship with the vendor, not the proposal's content.

**Lock the methodology before proposals arrive.** Changes to criteria or weights after proposals are received require documented justification, stakeholder sign-off, and consideration of whether re-solicitation is required. The standard is not "can we justify the change" but "would a disappointed vendor be able to challenge the selection as biased."

**Category classification check**

Before setting weights, classify the purchase: transactional (commoditized, low switching cost, readily substitutable) or strategic (deep integration, multi-year horizon, high switching cost). The same evaluation template applied to both categories produces decisions optimized for the wrong variables. Document the classification and its rationale — it determines not just weights but which risks require escalation.

---

## Phase 3: RFP document structure

A complete RFP document has six sections. Missing sections generate clarification requests that delay the process and often signal to sophisticated vendors that the organization is not ready to buy.

**Executive summary and background**

- [ ] Organization description and business context for this procurement — written so an unfamiliar vendor can understand the operating environment
- [ ] Complete procurement timeline with hard dates: RFP issue, questions deadline, proposal submission deadline, evaluation period start and end, decision date, anticipated contract start
- [ ] Single point of contact for all vendor communications during the RFP period — name, title, and email only; no phone number to prevent informal contact
- [ ] Explicit prohibition on vendor contact with evaluators or executives outside the defined channel during the evaluation period

**Scope of work**

- [ ] Detailed description of what the solution must do, derived directly from Phase 1 requirements — not a narrative rewrite that introduces new requirements
- [ ] Explicit statement of what is out of scope — vendors cannot right-size their proposals without knowing the boundaries
- [ ] Current-state context sufficient for the vendor to size their response: existing systems, user volumes, transaction volumes, geographic scope, integration landscape
- [ ] Statement of who performs implementation: vendor-led, customer-led with vendor support, or joint — ambiguity here is the largest source of post-signature scope disputes

**Requirements specification**

- [ ] All requirements in a structured table: Requirement ID, Description, Category (Functional/Technical/Commercial), Priority (Mandatory/Desirable)
- [ ] Vendor response column for each requirement: Meets / Partially Meets / Does Not Meet, plus approach description
- [ ] No prose requirements outside the table — prose requirements are answered selectively by vendors and cannot be scored systematically
- [ ] Verify no requirement describes a current-state workflow or names a specific vendor's product or API ("must integrate with [Vendor X]'s proprietary API" is a sole-source specification hidden in requirements language)

**Evaluation criteria and methodology**

- [ ] Criteria categories with weights published in the RFP — not reserved internally
- [ ] Description of the evaluation process: number of evaluators, whether demos or POCs are part of the process, whether finalists will be interviewed before selection
- [ ] Scoring scale disclosed (e.g., 1–5 per criterion; weighted total determines ranking)
- [ ] Statement of whether best-and-final-offer (BAFO) round will occur and under what conditions
- [ ] Note: government and public sector RFPs are typically required to publish this section; commercial RFPs commonly omit it — omitting it increases litigation exposure if a disappointed vendor challenges the selection

**Commercial terms and instructions**

- [ ] Pricing format specified: what to itemize, what model options to include, what a 3-year TCO model must cover (license, implementation, integration, training, ongoing support, anticipated exit costs)
- [ ] Any non-negotiable contractual terms identified upfront — requiring vendors to acknowledge them in their proposal eliminates post-selection negotiation surprises
- [ ] Proposal format and page limits stated — structure reduces the advantage of vendors with dedicated proposal teams over vendors with better solutions and less bandwidth
- [ ] Proposal submission instructions: format (PDF, online portal, etc.), deadline, what constitutes a late submission and whether late submissions are accepted

**Timeline and terms and conditions**

- [ ] Complete timeline with hard dates — no "approximately" or "TBD"
- [ ] Proposal ownership clause: proposals become the organization's property on submission
- [ ] No-commitment clause: submission does not obligate the organization to award a contract or to award at all
- [ ] Confidentiality expectations during the evaluation period
- [ ] Protest and challenge rights: required for government procurement; advisable for commercial to reduce litigation exposure
- [ ] Right to request clarification or additional information without reopening competition

---

## Phase 4: Evaluation scoring

**Evaluation team composition**

- Include representatives from each stakeholder group that will be affected by the selection: IT (integration and security), operations (functional fit), finance (commercial terms and TCO), and end users (usability and adoption)
- Evaluators score independently before any group discussion — group discussion before independent scoring produces anchoring to the first score stated, not independent assessment
- Aggregate scores after independent review; use the discussion to address outliers (very high or very low scores relative to the group), not to achieve consensus
- Document the identity of every evaluator and their organizational role — this is part of the evaluation record and is required if the selection is challenged

**Compliance screen before scoring**

- Before full evaluation, screen all proposals for mandatory requirements: does the proposal address every mandatory requirement? Proposals with uncured mandatory gaps are non-compliant and are removed from evaluation before scoring begins — they do not receive partial credit
- Document non-compliance findings per proposal with specific requirement IDs — "did not meet requirement F-03 and F-07" not "incomplete proposal"
- Issue simultaneous clarification requests to all proposals with ambiguous mandatory responses before making a compliance determination — a vendor who can cure the gap in clarification should not be disqualified for a documentation deficiency

**Demo and proof-of-concept design**

- If demos are part of the process, all finalists run the same scenario — not a tour of the vendor's preferred features
- Scenario should reflect the organization's hardest use case, not the easiest: "show me how you handle [our most complex workflow]" produces more differentiation than "show me your dashboard"
- Score demos using the same rubric as proposals; do not let demo impressions override written evaluation
- Require that the demo environment be representative of the production system — vendors who demo a development environment or a curated dataset are not demonstrating production capability

**Clarification requests**

- Issue clarification requests to all finalists simultaneously for the same questions — contacting only one finalist with a clarifying question gives that finalist an advantage
- Document all clarifications and responses in the evaluation record; clarifications that change a proposal's substance may require re-scoring
- Set a hard deadline for clarification responses and hold it — extending the deadline for one finalist and not others is the kind of process inconsistency that makes a selection challengeable

---

## Phase 5: Reference checks

References provided by vendors are curated. A reference check that follows the vendor's list and asks open-ended questions produces no useful information. Structured reference checks are the counter.

**Reference check protocol**

- Use the same question set for every finalist, at the same evaluation stage — consistency makes references informative and the evaluation defensible
- Supplement vendor-provided references with independent outreach: LinkedIn to find users of the vendor's product who are not on the provided list, industry associations, peer network contacts
- Conduct reference checks before the finalist ranking is final — not as a formality after the decision is made. A disqualifying finding from a reference check should be able to change the outcome.
- Score reference checks using a structured rubric, not general impressions — "references were positive" is not an evaluation finding

**High-signal questions**

- "Walk me through the implementation. What went over timeline or over budget, and how did the vendor respond?"
- "What does their support process actually look like when something breaks? Give me a specific example."
- "If you were starting this selection over, would you choose this vendor again? What would make you hesitate?"
- "What do you know now that you wish you had known before signing?"
- "How has the vendor handled contract renewals? Did pricing change materially? How much negotiating room was there?"
- "Has the vendor's support quality changed since the initial implementation period ended?"

**Common miss**: Only checking references for the finalist vendor and not for the incumbent. If you are re-competing a contract an incumbent holds, check references for the incumbent at comparable organizations that selected them — not just internal stakeholders who have adjusted to the incumbent's limitations.

---

## Phase 6: Contract negotiation leverage points

Selection triggers the negotiation. The leverage is highest immediately after selection notification and before the vendor has publicly announced the win. It degrades quickly once the vendor believes the deal is closed.

**Leverage points to use before contract signature**

- **Pricing**: The proposal price is an opening position. Request a best-and-final pricing round after finalist selection, before contract. Volume commitments, multi-year terms, and payment terms are the primary levers.
- **Implementation scope and risk allocation**: Who owns implementation risk? If the vendor's statement of work places delivery milestones on the vendor, the organization has leverage to tie payment to milestone achievement. If the SOW places all responsibility on the organization ("implementation success depends on customer resource availability"), renegotiate before signing.
- **SLA penalties**: Uptime and performance SLAs are commonly stated in contracts without meaningful remedies. Negotiate service credits that are automatic (not requiring a claim submission) and that scale with the severity of the breach.
- **Termination-for-convenience**: Enterprise software contracts without a termination-for-convenience right lock the organization into a vendor regardless of performance. Negotiate the right to terminate with 60–90 days' notice, with a clear statement of what data the organization gets back and in what format.
- **Data portability and exit provisions**: What happens to the organization's data if the relationship ends? Where does it live, what format is it in, and how long does the vendor hold it after termination? Data portability provisions negotiated before signing are enforced; provisions requested after termination are not.

**TCO model as a negotiating document**

Build a 3-year TCO model before entering negotiation. Include license fees, implementation labor (vendor and internal), integration costs, training, ongoing support, and estimated exit costs. The model surfaces where the real cost lives — frequently in implementation and support, not in license fees — and identifies which cost elements are actually negotiable.

Use the TCO model in the negotiation explicitly: "Our model shows that implementation and integration will cost us more than the license in year one. We need to negotiate the implementation SOW, not just the license price." Vendors who have only had price conversations are unprepared for this; it is a significant source of negotiating leverage.

**Common miss**: Negotiating only on license fee and leaving implementation scope, SLA remedies, and data portability as boilerplate. These terms determine the cost and risk of the entire contract period, not just the signature event.

---

## Issue triage

Organize evaluation findings into four buckets before making a selection recommendation:

| Finding type | Definition | Action |
|---|---|---|
| Disqualifying gap | Mandatory requirement not met with no credible remediation path | Remove from consideration; document rationale with specific requirement IDs |
| Negotiable gap | Requirement not met in current offering but vendor has credible roadmap or workaround | Negotiate as a contract commitment with milestone and remedy; do not accept roadmap promises without contractual backing |
| Risk flag | Capability present but vendor stability, reference check results, or implementation approach raises material concerns | Require additional documentation; adjust scoring; escalate for stakeholder decision — do not absorb this risk silently |
| Differentiator | Capability that exceeds requirements and provides strategic value not initially anticipated | Weight in selection; use in TCO model to capture expected value |

The selection recommendation to stakeholders should map every finalist to these four buckets. A recommendation that is not organized by finding type produces decisions driven by the most vocal stakeholder in the room, not by the evaluation.

**Documentation requirement**: The evaluation record — requirements, scoring rubrics, individual evaluator scores, aggregated scores, clarification exchange, reference check notes, and the selection recommendation — should be retained for the duration of the contract plus the applicable statute of limitations for commercial disputes in your jurisdiction. For government procurement, retention requirements are jurisdiction-specific; verify against the applicable procurement code.
<!--fold:3d0ed4@file path="sources.md" mode="644"-->
# Sources — Procurement, RFP, and Vendor Sourcing

Fetch these at task time. Ordered by importance. Verify thresholds and regulatory figures at the authoritative source for the specific jurisdiction and entity type — do not cite cached numbers.

1. ISM (Institute for Supply Management) — standards, research, and the CPSM body of knowledge for supply management professionals:
   https://www.ismworld.org/supply-management-news-and-reports/

2. NIGP (The Institute for Public Procurement) — procurement methodology, standards, and resources for public sector practitioners; covers both US and international public-sector frameworks:
   https://www.nigp.org/learning-and-development/resource-center

3. FAR Part 15 — Federal Acquisition Regulation, Contracting by Negotiation — the authoritative framework for competitive proposal-based procurement in the US federal government, covering source selection, proposal evaluation, and best value determinations. Jurisdiction-specific: applies to US federal agencies; US state/local agencies follow their own procurement codes:
   https://www.acquisition.gov/far/part-15

4. UK Procurement Act 2023 — the current statutory framework for public procurement in the UK (successor to the Public Contracts Regulations 2015). For UK public sector context:
   https://www.gov.uk/government/collections/procurement-reform

5. Gartner Magic Quadrant methodology — the standard market analysis framework for vendor evaluation across enterprise technology categories; use to understand how analysts evaluate completeness of vision vs. ability to execute:
   https://www.gartner.com/en/research/methodologies/magic-quadrants-research

6. APQC (American Productivity & Quality Center) — procurement benchmarking data, process frameworks, and best practices across sourcing and vendor management:
   https://www.apqc.org/expertise/supply-chain-management/procurement

7. World Commerce & Contracting (formerly IACCM) — contract management and commercial best practices; useful for RFP terms and conditions, vendor negotiation frameworks, and contract structure:
   https://www.worldcc.com/Resources/Research-and-Insights

8. Spend Matters — independent procurement technology analyst coverage; useful for evaluating AI-powered procurement tools, spend analytics platforms, and sourcing software:
   https://spendmatters.com/
<!--fold:3d0ed4@end-->
PORTDOWN_4FFDD3A0

# ── post ──
MARKER=$(awk '/^---$/ { f++; if (f==2) exit; next } f==1 && /^marker:[[:space:]]/ { sub(/^marker:[[:space:]]+/, ""); print; exit }' "$DEST")
[ -z "$MARKER" ] && { echo "seed: archive has no marker — corrupt" >&2; exit 1; }
awk -v m="$MARKER" -v outdir="$TARGET" '
  BEGIN {
    # Match <!--fold:<m>@file path="X"--> with an optional mode attr after
    # the path (fold emits  mode="644"  on executables).
    file_re = "^<!--fold:" m "@file path=\"([^\"]+)\"( mode=\"[0-9]+\")?-->$"
    end_re  = "^<!--fold:" m "@end-->$"
  }
  $0 ~ end_re { if (current) close(current); exit }
  $0 ~ file_re {
    if (current) close(current)
    line = $0
    sub(/^<!--fold:[^@]+@file path="/, "", line); sub(/".*$/, "", line)
    current = outdir "/" line
    dir = current; sub(/\/[^\/]*$/, "", dir)
    if (dir != current) system("mkdir -p \"" dir "\"")
    printf "" > current
    next
  }
  current { print >> current }
' "$DEST"
SEED_EXTRACTED=$(find "$TARGET" -type f -not -path "$DEST" 2>/dev/null | wc -l)
if [ "$SEED_EXTRACTED" = "0" ]; then
  echo "seed: archive contained no files — refusing to delete the source" >&2
  echo "  archive preserved at: $DEST" >&2
  exit 1
fi
rm -f "$DEST"

echo "" >&2
echo "✓ seed unpacked → $TARGET ($SEED_EXTRACTED files)" >&2
find "$TARGET" -type f | sort | while IFS= read -r _sf; do
  echo "  ${_sf#${TARGET}/}" >&2
done
echo "" >&2
if [ -f "$TARGET/SKILL.md" ]; then
  echo "This seed contains a skill (SKILL.md). Install it in your agent's skills directory." >&2
  echo "" >&2
fi
echo "Install the seed skill if not already installed:" >&2
echo "  https://seed.show/skill" >&2
echo "" >&2
echo "Publisher prompt:" >&2
sed 's/^/  /' >&2 <<'__SEED_PROMPT_END_AC1F2B__'
You have procurement, RFP, and vendor sourcing context. Read README.md first: it covers what level this seed operates at, the procurement mental model (TCO, risk, strategic fit), the RFI/RFQ/RFP distinction, what agents get wrong (including AI-specific failure modes), and what AI is changing in procurement. Then read checklist.md for the phase-by-phase decision framework across requirements, scoring design, RFP structure, evaluation, reference checks, contract negotiation, and issue triage. Fetch sources.md for authoritative standards — verify jurisdiction-specific thresholds against the live source, not cached figures. To share your own context bundles: curl seed.show/skill | bash
__SEED_PROMPT_END_AC1F2B__
exit 0