The draft came back from the proposal team with a sentence I had not written. It sat in the middle of my monitoring approach, clean and confident: "The solution automatically remediates configuration drift across all enrolled endpoints, restoring compliant baselines without operator intervention."
I read it three times. The product we were proposing could detect configuration drift. It could alert on it. It could even show you a tidy before-and-after diff. What it could not do was reach back into the endpoint and fix the thing on its own. That last part, the part the sentence promised, was a script somebody would have to write, test, and maintain against an operating system that changed under it every patch cycle.
Nobody had decided to lie. A capability had drifted from "possible with work" to "included" across two or three handoffs, and now it was sitting in a document that, if we won, would become the standard we were measured against.
How the gap opens
The people who tightened that sentence were not being reckless. They were doing exactly what proposal writing rewards, which is taking a hedged, technical statement and making it crisp and active. "The solution can be configured to support automated remediation workflows" is weak proposal prose. It begs for a red pen. So the red pen comes, and "can be configured to support" becomes "automatically," and the conditional evaporates.
The trouble is that the conditional was carrying the entire engineering reality. You know the difference between a feature that ships in the box, a feature you assemble from the vendor's supported building blocks, and a feature that exists only if you build it. Those three things read identically once they are written in confident future tense. "Integrates with," "monitors," "orchestrates," and "automatically" all flatten the distinction between native function, supported configuration, and custom development.
A proposal reviewer cannot see that distinction. They are reading for clarity, compliance, and persuasion, and a sentence that promises more sounds better on every axis they are trained to evaluate. The reviewer is not the problem. The product knowledge lives with you, and the language got finalized somewhere you were not in the room.
This matters more on the technical volume than almost anywhere else, because the technical approach is where evaluators look for evidence that you actually understand what you are signing up to deliver. An overclaim here does not just risk a future delivery headache. It can read, to a sharp evaluator, as a vendor who does not know their own tooling.
The three buckets
When a capability claim crosses your desk, sort it into one of three buckets before you do anything else.
Native. The product does this out of the box. You turn it on. If the claim describes native behavior, leave it alone and move on.
Configuration. The product supports the claim through internal mechanisms (connectors, policies, built-in workflows) that you assemble without writing or maintaining code the vendor doesn't own. This carries setup work, and someone owns that labor for the life of the contract.
Custom development. This capability does not exist until your team builds it. Scripts, integration glue, a service that polls one system and pushes to another, anything that lives in your repository rather than the vendor's. It is buildable. It is also a deliverable with a cost, a maintenance burden, and a failure mode.
The overclaims that hurt you are almost always bucket three wearing bucket one's clothing. "Automatically remediates" was custom development dressed as native behavior. The fix is not to delete the capability. The fix is to make the sentence tell the truth about which bucket it lives in.
How to inject reality without blowing up the timeline
The instinct, when you spot one of these, is to fire off a message that says "this is wrong." Resist it. "Wrong" reads as a blocker, and a blocker two days before a deadline gets you labeled as the engineer who slows things down. You want to be the engineer who keeps the team out of a delivery trap, and those are different reputations.
Do three things instead.
Flag the specific verb, not the whole sentence. Point at the exact word carrying the false weight. "The word 'automatically' here implies the tool self-heals. It detects and alerts natively, but remediation is a script we would build and maintain." Precision shows you read carefully and gives the writer something they can act on in thirty seconds.
Offer the accurate version in the same breath. Never hand back a problem without a replacement. "Suggest: 'The solution detects configuration drift in real time and triggers remediation through customer-approved automation workflows.'" Now you have moved the claim from native to configuration, kept it strong, and the writer can paste it without thinking. You have done their hardest work for them.
Name the downstream cost once, plainly. If the capability stays as written, say what it commits the team to. "If we keep 'automatically,' we are committing to build and maintain remediation scripts across every enrolled platform as a contract deliverable. That is real labor the pricing volume should know about." You aren't vetoing. You're surfacing a decision that belongs to people above your pay grade, and you're putting it on the record before it becomes a surprise.
That last move is the one that protects you. The decision to promise custom development might be the right call. Maybe the team wants to win on capability and price the build in. That is a legitimate strategy. What you cannot allow is for that decision to get made by accident, by a verb, in a sentence nobody traced back to a real product.
Seeing both sides
A proposal is a description of work your company hasn't done yet, written by people who won't be the ones doing it. The gap between "the tool does this" and "we will make the tool do this" is invisible in prose and enormous in practice. You are one of the few people on the team who can see both sides of that gap at once. This work is not pedantry. Catching the verb that quietly moved a capability from buildable to built is the most useful thing your product knowledge will do all proposal long.
The Proposal Stack publishes biweekly for technical GovCon professionals. If this was useful, forward it to someone who's just found a sentence in a draft promising their tool does something it has never actually done.