Every federal contractor I have ever talked to opens the conversation the same way. They tell me they have a “proprietary database of opportunities.” Then I ask where it comes from, and the answer is always the same public federal procurement and spending sources, plus a government export or two — the exact same feeds their competitor down the street is pulling from. The data is not proprietary. It was never proprietary. It is a public API with a rate limit.
This is the first thing I had to internalize when I built my federal-contractor intelligence engine. The raw material is a commodity. Anyone with an API key and a weekend can ingest the entire active-opportunities feed. If your pitch is “we have the data,” you have nothing, because the contracting officer published that data on purpose, to everyone, by law.
The edge is downstream of ingestion. It is in what you compute.
What “public” actually means
Let me be precise about the corpus, because the shape of it explains where the value hides.
| Source | What it gives you | What it does not |
|---|---|---|
| Active opportunity feed | Notices, NAICS, set-asides, response dates | Whether you can actually win |
| Federal spending data | Historical awards, dollar amounts, recipients | Why the incumbent won |
| Contract action detail | Vehicle, PSC, action history | Relationship context |
| Small-business profiles | Certifications, declared capabilities | Real capacity vs. claimed |
Every one of those columns is free. The schema is documented. The bulk files are downloadable. A contracting officer and a one-person SDVOSB are looking at the same JSON.
So what separates the contractor who books millions off this feed from the one who refreshes the opportunity portal twice a week and feels busy? It is not access. It is the function they run over the access.
The data tells you what was bought. The signal tells you what is about to be bought again, by whom, and whether you have any business showing up.
The four computations that actually matter
When I designed the engine, I stopped thinking about “search” and started thinking about derived signals. A search returns rows. A signal returns a judgment with a reason attached. Here are the four that carry almost all the weight.
1. Recompete prediction
The single most valuable thing buried in federal spending data is the period of performance. A five-year IDIQ awarded in 2021 is a recompete in 2025. Nobody publishes a “this is expiring soon” feed, but you can derive it. Join the award record to its base-plus-options structure, project the end date, and you have a pipeline of recompetes 12 to 18 months before they hit the opportunity portal as a notice.
That is the whole game. By the time it is a solicitation, the incumbent has been shaping it for a year. The signal is in computing the expiration, not in reading the post.
# illustrative: derive recompete windows from award history
def recompete_window(award):
base_end = award.start_date + relativedelta(months=award.base_months)
full_end = base_end + relativedelta(months=award.option_months)
# capture window opens ~18mo before full PoP end
return (full_end - relativedelta(months=18), full_end)No external data. Just arithmetic over public columns that almost nobody bothers to run.
2. Incumbent strength
When a notice posts, the question is never “can I do this work.” It is “can I beat whoever already has it.” The spending data tells you who held the predecessor contract, how many modifications it accrued, and whether the dollar value crept up over time. A contract that doubled in value through mods is a happy customer. A contract that got re-competed early is an unhappy one. That delta is computable, and it changes a bid/no-bid decision more than any single field on the notice itself.
3. Agency buying rhythm
Federal money has a heartbeat. Q4 of the fiscal year — the September spend-down — is real and measurable. If you aggregate an agency’s obligations by month over three years, you can see exactly when a given sub-office actually moves money. That tells your business development team when to be in the building, not when the portal happens to have a notice up.
4. Fit scoring that survives scrutiny
This is where most “AI for GovCon” tools fall apart. They embed the solicitation, embed your capability statement, cosine-similarity the two, and call it a match score. It demos beautifully and it is nearly useless, because semantic similarity does not understand a size standard or a mandatory certification. A 0.91 cosine match on a contract you are legally barred from bidding is noise dressed as signal.
Real fit is a gate stack: hard filters first (NAICS eligibility, set-aside eligibility, clearance requirements, registration status), then soft ranking second. I cover the retrieval side of this in the work on agentic RAG over solicitations, because answering “is this worth bidding” is genuinely a multi-hop problem. But the principle starts here: the LLM is the last step, not the first. You filter on the deterministic public data, then you let the model reason over what survives.
Why everybody computes the wrong thing
The reason this edge persists is that computing the right signal is unglamorous and computing the wrong one is easy.
It is easy to build a keyword alert. It is easy to wire an embedding search. It is easy to throw the whole solicitation at a model and ask “summarize this.” Those things produce a screen full of activity, and activity feels like intelligence. But none of them answer the only questions a capture manager actually has: should I spend money chasing this, and what is my real probability of winning?
The valuable computations are the ones that require you to model federal procurement as a system that moves in predictable cycles, not as a stream of independent documents. Recompete timing, incumbent fatigue, agency rhythm, eligibility gates. None of those are in any single row. All of them are derivable from rows everyone has.
The discipline this forces
Once you accept that the data is a commodity, your engineering priorities invert.
You stop optimizing for coverage. Pulling more sources is a trap; everyone has the sources. You optimize for the quality of your derived fields. One well-computed recompete-window column is worth more than three new feeds.
You stop trusting demos. A tool that returns a beautiful ranked list of “matching opportunities” is showing you search. Ask it why a specific notice ranked third, and whether you are even eligible to bid it. If it cannot answer, it computed nothing.
And you instrument everything. When the engine surfaces an opportunity, it carries the reason: the expiring contract that triggered it, the incumbent it identified, the eligibility checks it passed. A signal without a traceable reason is just a guess with good UI, and in federal work a guess costs you a $50K bid-and-proposal budget. This is the same conviction I’m building into Vontra — every surfaced judgment ships with the math that produced it.
What I tell contractors now
When a contractor tells me about their proprietary database, I ask one question: what do you compute that your competitor does not? If the answer is a list of sources, we are done. If the answer is something like “we know which of our agency’s contracts expire in the next 18 months and which incumbents are vulnerable,” now we are talking about an actual advantage, because that is a function, and functions can be better than someone else’s.
The public feed will be public forever. That is not a problem to route around. It is the entire premise. The contractors who win are not the ones with secret data. They are the ones who run a sharper computation over the same public rows everyone else is staring at and not reading.
Built for missions means building the math, not hoarding the inputs.