Published on Mon Aug 24 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

Federal proposal evaluation is comparative. Evaluators do not score your proposal in isolation. They score it against every other proposal in the stack, and they allocate points on the dimensions where proposals differ. Those dimensions are called discriminators. A proposal that matches the field on every discriminator and exceeds it on none will land in the middle of the pack, regardless of how well-written it is. A proposal that exceeds the field on the discriminators that matter most will win.

Two techniques determine whether your proposal exceeds the field or matches it. The first is discriminator analysis: identifying the requirements where proposals will separate, and organizing your response around them. The second is ghosting: writing content that highlights competitor weaknesses without naming the competitors. The two work together. Discriminator analysis tells you where to aim. Ghosting is how you land the shot.

This article explains both, using a real example. We ran our proposal engine against the House of Representatives IT RFP and it identified six discriminator themes. We will walk through what the engine found, how it grouped requirements into themes, and how each theme becomes a ghosted passage in the final proposal. If you want the background on how the engine extracts requirements deterministically before it ever analyzes discriminators, see our piece on deterministic RFP requirement extraction.

What Ghosting Is

Ghosting is a proposal strategy where you describe a capability or approach that highlights a competitor weakness without naming the competitor. The evaluator reads your passage, recognizes that other proposals lack what you describe, and scores yours higher. You never mention a competitor by name. You never say “unlike other vendors.” You simply describe the thing you do that they do not, with enough specificity that the absence in their proposal becomes conspicuous.

The classic example is 24/7 security monitoring. If you know competitors in this procurement offer business-hours monitoring only, you write: “Our 24/7 Security Operations Center provides continuous threat detection and response, with sub-200ms mean time to detection across all monitored assets.” You have not named anyone. You have not said “others stop at 5pm.” But the evaluator, reading this alongside a proposal that says “we provide security monitoring during standard business hours,” will notice the difference. Your passage ghosts the competitor. Their passage ghosts itself.

Ghosting works because evaluators are instructed to compare. Section M of an RFP defines the evaluation criteria, and those criteria are almost always comparative — “the extent to which the offeror demonstrates…” or “the quality of the offeror’s approach to…” These are not pass/fail thresholds. They are relative judgments. Ghosting gives the evaluator the material to make a relative judgment in your favor.

The technique is not new. Shipley and other proposal methodologies have taught it for decades. What is new is doing it systematically — identifying every discriminator in an RFP, mapping each to a known competitor weakness, and threading the ghosted content through every relevant response section. That is what discriminator analysis enables.

Why Ghosting Matters

Evaluators score on discriminators. This is the part many proposal teams misunderstand.

A compliant proposal addresses every requirement. A winning proposal addresses every requirement and exceeds the field on the requirements that determine the outcome. Those requirements are the discriminators. They are the items in Section M where proposals will separate — where one offeror’s approach is demonstrably better than another’s.

If you write a compliant proposal without ghosting, you leave points on the table. You address the requirement. The competitor addresses the requirement. The evaluator sees two proposals that both check the box. On a comparative scale, you tie. On a procurement where only one award is made, a tie is a loss.

Ghosting converts a tie into a win. It does this by making your response to a requirement visibly stronger than the field, in a way the evaluator can score. “We provide security monitoring” ties. “Our 24/7 SOC with sub-200ms detection and a documented escalation runbook reviewed quarterly by our CISO” wins, because it ghosts every competitor who wrote the first version.

The risk of not ghosting is not just losing. It is losing to a proposal that is objectively worse than yours but better at surfacing its advantages. Federal evaluators are not subject matter experts on your company. They know only what your proposal tells them. If your proposal does not make your advantages visible — explicitly, repeatedly, in the language of the evaluation criteria — those advantages do not exist for scoring purposes.

How Discriminator Analysis Works

Discriminator analysis is the process of identifying which requirements in an RFP will separate proposals, grouping them into themes, and mapping each theme to a competitor weakness you can ghost. Done manually, this is a multi-day exercise for a capture manager who knows the competitive landscape. Done with our engine, it is a structured output produced after requirement extraction completes.

The process has three steps.

Step 1: Identify critical requirements. The engine extracts every requirement from the RFP — every “shall,” every “must,” every conditional obligation — and classifies each by criticality. Critical requirements are those that appear in Section M evaluation criteria, that carry mandatory language, or that recur across multiple sections of the RFP. These are the requirements where evaluators will look for differentiation. For a full treatment of how extraction and classification work, see our article on deterministic RFP requirement extraction. Non-critical requirements still must be addressed for compliance, but they are not where proposals win or lose. For how compliance tracking works across the full proposal, see our overview of RF compliance matrix automation.

Step 2: Group critical requirements into themes. Critical requirements rarely stand alone. They cluster. A group of requirements around access control, incident response, continuous monitoring, and vulnerability management forms a cybersecurity theme. A group around system architecture, scalability, integration, and disaster recovery forms a technical architecture theme. The engine groups related critical requirements into discriminator themes — coherent capability areas where the RFP demands depth and where proposals will separate based on the depth of their response.

Step 3: Map each theme to a competitor weakness. For each theme, the engine identifies the competitor weakness most likely to be present in the field. This is where competitive intelligence enters the process. The engine does not invent weaknesses. It maps each theme to a weakness pattern common in the competitive landscape for that procurement — a known gap in the incumbent’s offering, a structural limitation of small-business set-aside competitors, a capability that is expensive to build and therefore rare. Each theme then carries three things: the competitor weakness to ghost, the strengths you should emphasize to exploit that weakness, and the key requirements you must address to make the ghosting credible.

The output is a discriminator map. It tells the proposal team exactly where to invest writing effort, what to emphasize, and what competitor gap each passage targets.

A Real Example: The House of Representatives IT RFP

We ran the engine against the House of Representatives IT RFP. The RFP is a large, multi-section solicitation covering IT operations, cybersecurity, application development, and enterprise services for the House. It contains hundreds of requirements. The engine extracted all of them, classified 140 as critical, and grouped those into six discriminator themes.

Here are the themes, ordered by the number of critical requirements each contains.

Cybersecurity Excellence — 52 critical requirements. This is the dominant discriminator. The RFP contains 52 critical requirements related to access control, continuous monitoring, incident response, vulnerability management, FISMA compliance, and threat detection. This is where proposals will separate most. The competitor weakness to ghost: many competitors offer perimeter-focused security with limited continuous monitoring and slow incident response. The strengths to emphasize: a 24/7 SOC, sub-200ms detection, documented escalation runbooks, FISMA-high experience, and independent audit results. Every cybersecurity response in the proposal should reinforce these strengths and ghost the perimeter-only alternative.

Technical Architecture — 31 critical requirements. The RFP demands a modern, scalable, resilient architecture across on-premises and cloud environments. Thirty-one critical requirements cover system design, integration patterns, scalability, disaster recovery, and service continuity. The competitor weakness to ghost: legacy architectures that require forklift upgrades and cannot scale elastically. The strengths to emphasize: cloud-native design, zero-downtime deployment, horizontal scalability, and a documented modernization roadmap. Ghosting here means describing your architecture in terms the evaluator can contrast against a legacy alternative — “horizontal scaling with no service disruption during capacity expansion” rather than “we scale to meet demand.”

Transparent Reporting — 19 critical requirements. The House requires extensive reporting — performance metrics, security posture, incident summaries, financial transparency, and SLA compliance. Nineteen critical requirements define what must be reported, how often, and in what format. The competitor weakness to ghost: competitors who treat reporting as an afterthought, delivering manual spreadsheets on a lag. The strengths to emphasize: automated real-time dashboards, API-accessible metrics, and configurable reporting that meets each stakeholder’s needs without manual compilation. Ghosting here means showing the evaluator that reporting in your proposal is a system, not a task.

Fair Pricing — 14 critical requirements. The RFP includes 14 critical requirements related to pricing transparency, labor category definitions, rate justification, and cost realism. The competitor weakness to ghost: competitors who win on low bid and underperform, or who bury costs in opaque labor categories. The strengths to emphasize: transparent labor categories, documented rate justification, no hidden pass-through costs, and a pricing model that aligns cost with delivered value. Ghosting in pricing is delicate — you cannot directly attack a competitor’s price. You can, however, describe your pricing transparency in terms that make opaque pricing conspicuous by contrast.

Regulatory Compliance — 14 critical requirements. Fourteen critical requirements cover FISMA, HITECH, House-specific information security policies, and federal records management. The competitor weakness to ghost: competitors who treat compliance as a checklist rather than an operational discipline. The strengths to emphasize: compliance integrated into daily operations, automated control evidence collection, and a track record of clean audits. Ghosting here means describing compliance as something your team does continuously, not something it prepares for periodically.

Small Business — 10 critical requirements. The RFP includes subcontracting and small business participation requirements. Ten critical requirements define small business utilization targets, reporting, and commitment levels. The competitor weakness to ghost: competitors who treat small business participation as a paperwork obligation with minimal actual engagement. The strengths to emphasize: existing mentor-protégé relationships, documented subcontractor performance, and small business partners embedded in the technical solution rather than listed in a plan. Ghosting here means showing that your small business partners do real work, not just appear in a participation matrix.

These six themes tell the proposal team where to concentrate. Cybersecurity Excellence, with 52 critical requirements, is where the proposal will be won or lost. Technical Architecture is the second battleground. The remaining four themes are where a solid proposal separates from a good one. A proposal that ghosts effectively on all six themes — and threads those ghosts through every relevant response section — gives the evaluator a clear, consistent basis to score it above the field.

How to Write Ghosted Content

Knowing where to ghost is half the work. Writing the ghosted passage is the other half. The difference between effective ghosting and ineffective ghosting is specificity.

Ineffective ghosting is vague. “We have robust security monitoring” does not ghost anything, because every competitor can write the same sentence. The evaluator reads it, reads the same sentence in three other proposals, and scores them all the same. You have described a capability. You have not created a contrast.

Effective ghosting is specific and quantified. “Our 24/7 SOC provides continuous monitoring with sub-200ms mean time to detection, staffed by certified analysts across three shifts, with escalation to the CISO within 15 minutes for severity-1 incidents.” This passage ghosts every competitor who lacks 24/7 coverage, who cannot quantify detection time, who has no documented escalation timeline, or who staffs a single shift. The evaluator does not need to know which competitors those are. The specificity creates the contrast.

The pattern is consistent across themes. For each discriminator theme, identify the specific capability or metric that separates you from the field, and state it in terms the evaluator can score. “Our architecture supports horizontal scaling with zero service disruption during capacity expansion” ghosts competitors who require downtime to scale. “Our reporting platform provides real-time dashboards accessible via API, with no manual compilation required” ghosts competitors who deliver monthly spreadsheets. “Our compliance program collects control evidence continuously through automated tooling, with our last three audits resulting in zero findings” ghosts competitors who prepare for audits manually.

Three rules govern the writing.

State what you do, not what others do not. Ghosting is never comparative on the surface. You never write “unlike other offerors” or “while some vendors.” You write your capability in specific terms. The contrast is implicit. The evaluator supplies it.

Quantify where possible. “Sub-200ms detection” is stronger than “fast detection.” “Three shifts” is stronger than “continuous coverage.” “Zero findings on three consecutive audits” is stronger than “strong audit performance.” Numbers give the evaluator something to score. Adjectives do not.

Tie every claim to a requirement. A ghosted passage that does not address a specific RFP requirement is wasted words. The engine maps each theme to the critical requirements it contains. Every ghosted passage should address at least one of those requirements, so the evaluator can connect your differentiated response to the criterion they are scoring.

Win Theme Threading

Ghosting operates at the passage level. Win theme threading operates at the proposal level. The two are complementary, and a proposal that does both is stronger than one that does either alone.

A win theme is a single, concise statement of why your proposal should win. It is not a slogan. It is a positioning argument grounded in the discriminators. For the House IT RFP, a win theme might be: “We deliver continuous, transparent, and compliant IT operations that the House can verify in real time.” That theme touches Cybersecurity Excellence (continuous), Transparent Reporting (transparent, verify in real time), and Regulatory Compliance (compliant). It is a thread that runs through the entire proposal.

Win theme threading means every response in the proposal reinforces the win theme. Not by repeating the sentence. By demonstrating the theme in the substance of each response. The cybersecurity response demonstrates continuous monitoring. The reporting response demonstrates real-time transparency. The compliance response demonstrates verifiable compliance. The technical architecture response demonstrates the infrastructure that makes continuity possible. The pricing response demonstrates that the pricing model sustains these capabilities without hidden costs.

When the evaluator reads a proposal with consistent win theme threading, they build a coherent picture of your offering. Every section reinforces the same argument. The proposal reads as a unified case, not a collection of disconnected responses. This is what evaluators mean when they score a proposal as “compelling” rather than merely “acceptable.”

The engine generates win themes from the discriminator analysis. The discriminator themes define the substance. The win theme is the synthesis — the single argument that ties the themes together. Once the win theme is set, every generated response is checked against it. Responses that do not reinforce the theme are revised. Responses that contradict it are rewritten. The result is a proposal where the win theme is not stated once but demonstrated throughout.

The Danger of Over-Ghosting

Ghosting is a powerful technique and a common way to damage a proposal. The failure mode is over-ghosting — writing so many passages that highlight competitor weaknesses that the proposal reads as defensive, desperate, or obsessed with the competition.

If every paragraph contrasts your capability against an unnamed alternative, the evaluator notices. The proposal stops reading as a confident statement of your approach and starts reading as an argument against someone else’s. That shift in tone is fatal. Evaluators score confidence. A proposal that spends its word count explaining why it is better than the field is a proposal that is not spending its word count demonstrating what it does. The demonstration is what scores. The contrast is the mechanism, not the message.

The rule is to ghost sparingly and substantively. Not every requirement is a discriminator. Not every discriminator needs a ghosted passage. The discriminator analysis tells you which themes matter most. Concentrate ghosting in those themes — Cybersecurity Excellence and Technical Architecture in the House IT example — and write straightforward, compliant responses elsewhere. A proposal that ghosts on 20% of its content, in the right 20%, will outscore a proposal that ghosts on 80% of its content and exhausts the evaluator.

Substantive ghosting means every ghosted passage is backed by a specific, verifiable capability. “Sub-200ms detection” is substantive if you can prove it. It is a liability if you cannot. Ghosting a capability you do not have is not strategy. It is misrepresentation, and in a federal proposal, it is a False Claims Act risk. Every ghosted claim must be supportable by your past performance, your technical solution, or your operational data. The engine does not generate ghosted claims it cannot ground in your capability library. A human writer should hold the same standard.

How the Engine Ties It Together

The engine’s workflow for ghosting and discriminator analysis is deterministic at the extraction layer and guided at the generation layer. This is the same architecture we describe in our comparison of GovCon AI proposal tools rated for 2026 — deterministic extraction first, generation second, generation always subordinate to verified requirements.

The engine extracts every requirement from the RFP using rule-based parsing. It classifies each requirement by criticality. It groups critical requirements into discriminator themes. It maps each theme to a competitor weakness pattern drawn from the competitive intelligence input. It generates a win theme from the themes. It then generates response drafts that address the verified requirements, reinforce the win theme, and ghost competitor weaknesses where the discriminator analysis indicates ghosting is warranted.

The output is not a finished proposal. It is a structured draft where every response is grounded in a verified requirement, threaded to a win theme, and ghosted where the analysis supports it. A human proposal team reviews, revises, and finalizes. The engine does the work that is deterministic — extraction, classification, grouping, mapping — and accelerates the work that is generative — drafting, threading, ghosting — while leaving the judgment calls to the people who sign the cover letter.

This is the practical application of discriminator analysis. You do not ghost by instinct. You ghost by analysis. You identify the discriminators, map them to weaknesses, write to them with specificity, thread the win theme through every section, and resist the urge to ghost where it does not belong. The proposal that does this consistently is the proposal the evaluator scores highest — not because it is louder, but because it is precise.

Frequently Asked Questions

What is ghosting in proposal writing?

Ghosting is a proposal technique where you describe your capability in specific terms that highlight a competitor weakness without naming the competitor. For example, “Our 24/7 SOC provides continuous monitoring with sub-200ms detection” ghosts every competitor who lacks 24/7 coverage or cannot quantify detection time. The evaluator reads your passage, recognizes the absence in other proposals, and scores yours higher. You never mention a competitor by name. The contrast is implicit.

What is a discriminator in federal proposal evaluation?

A discriminator is a requirement or capability area where proposals will separate during evaluation. Evaluators score comparatively — they rank proposals against each other on the criteria in Section M. The requirements where proposals differ in quality or depth are the discriminators. A proposal that matches the field on every discriminator ties. On a single-award procurement, a tie is a loss. Discriminator analysis identifies these requirements so you can concentrate your writing effort where it affects the outcome.

How does discriminator analysis identify which requirements matter most?

The engine extracts every requirement from the RFP, classifies each by criticality based on Section M evaluation criteria, mandatory language, and cross-section recurrence, and groups critical requirements into themes. Themes with more critical requirements are higher-priority discriminators. In the House IT RFP, Cybersecurity Excellence contained 52 critical requirements and was the dominant discriminator. Technical Architecture contained 31. These two themes are where the proposal would be won or lost, and where ghosting effort should concentrate.

How do you write ghosted content without sounding desperate?

Ghost sparingly and substantively. Not every requirement needs a ghosted passage. Concentrate ghosting in the top discriminator themes and write straightforward compliant responses elsewhere. Every ghosted claim must be backed by a specific, verifiable capability — a metric, a certification, a past performance result. State what you do in specific terms, never what others do not. If every paragraph contrasts your offering against an unnamed alternative, the proposal reads as defensive. The evaluator scores confidence and demonstration, not argument.

What is win theme threading and how does it differ from ghosting?

Ghosting operates at the passage level — a single response that highlights a competitor weakness. Win theme threading operates at the proposal level — a single argument that ties every response together. A win theme is a concise statement of why your proposal should win, grounded in the discriminators. Threading means every response in the proposal demonstrates the win theme in its substance, not by repeating the sentence. Ghosting creates contrast on individual discriminators. Win theme threading creates a coherent case across the entire proposal. A strong proposal does both.

Written by Jacob Cavazos