Building a Federal-Contractor Intelligence Engine

The federal-contractor intelligence platform I built started as a single Python script that hit a public procurement API every morning and dumped the results to a spreadsheet. That version worked for about a week. Then the API rate-limited me, the spreadsheet hit its row ceiling, and I understood the real lesson: the interesting part of a federal intelligence engine is not the query. It is the wiring between systems that were never designed to talk to each other.

I have argued elsewhere that the public data is a commodity and the edge is what you compute on top of it. This post is the plumbing underneath that claim. The engine joins live opportunity data to company enrichment to authenticated outreach. Each seam is its own reliability problem, and the value lives entirely in the joins.

The four systems

• Public federal award data — opportunity notices and historical awards. The raw federal signal, free to anyone.
• A B2B contact-enrichment provider — turns a notice into a company into a named human with a real email.
• An enterprise identity and graph API — authenticated outreach from an actual mailbox, with a full audit trail.
• A persistence layer — Postgres, where derived signals live so I am not recomputing from raw feeds on every request.

A notice alone is trivia. A notice tied to its incumbent, tied to the program office’s buyer, tied to a verified contact, tied to a sent-and-logged message: that is a pipeline.

Lesson one: the public APIs are honest but fragile

Government APIs are correct, slow, and occasionally just down. My first mistake was treating one like a database I could query on demand. It is not. The right model is a nightly ingest into your own store, with the live API used only for spot-checks.

The rate limits are real and they do not negotiate. I settled on a schedule that has held up:

02:00  full opportunities pull (paged, backoff on 429)
03:00  award deltas (changed since last run)
03:30  reconcile + recompute derived signals
06:00  enrichment pass on net-new qualified rows

Everything downstream reads from my store, never from the public API in the request path. The day I stopped querying the source API live, p95 latency on the dashboard dropped from roughly 4 seconds to under 300ms, and the mysterious late-afternoon outages disappeared. They were never my bug. They were the government’s afternoon.

Lesson two: enrichment is where you bleed money and trust

A good enrichment provider will happily charge you for garbage if you let it. Enriching every opportunity is the naive move and it is expensive. A single notice can map to dozens of candidate companies, most of which you have no business contacting.

The fix was ordering. Enrich last, never first. I run the deterministic gates from the public data — eligibility, set-aside, NAICS, recompete relevance — and only the surviving rows get an enrichment call. In the systems I’ve built, that tends to cut enrichment volume by something like 80%, and more importantly it cuts the volume of confidently-wrong contacts, which is the thing that actually destroys sender reputation.

Enriching a contact you should never email is worse than not enriching at all. You paid for the privilege of damaging your domain.

Enrichment also lies sometimes. A “verified” email bounces. So enrichment writes a confidence score, not a fact, and anything below threshold never reaches the outreach stage automatically.

Lesson three: authenticated outreach buys you accountability

I could have sent mail through any SMTP relay. I went through an enterprise identity and graph API specifically because federal-adjacent outreach has to be auditable, and that path gives me a sent-items record, message IDs, and OAuth-scoped identity for free. Every message the engine sends exists in a real mailbox with a real trail. I wrote a separate piece on outreach that survives an audit, because “fast” and “accountable” are usually in tension and federal work demands both.

The integration taught me one hard thing: token lifecycle is the whole game. Access tokens expire, refresh tokens get revoked when an admin changes a policy, and consent can be pulled out from under you. My first version assumed a token was a token. The fix was a small token broker that refreshes proactively, detects revocation, and fails loud rather than silently dropping messages into the void. A dropped federal outreach message is not retry-and-forget. Someone was supposed to hear from you and did not.

The reliability seams, ranked

After a year of running this, here is where the failures actually came from, roughly in order:

Seam	Failure mode	Mitigation
Source-feed ingest	429s, afternoon downtime	nightly batch, backoff, own store
Contact enrichment	wrong/stale contacts	gate-then-enrich, confidence scores
Outreach auth	token/consent revocation	proactive refresh, loud failure
Derived-signal recompute	stale recompete windows	idempotent nightly reconcile

None of those are glamorous. None of them show up in a demo. All of them are the difference between a tool a capture manager trusts at 7am and one they quietly stop opening.

What reliability actually meant

The thing I underestimated is that an intelligence engine fails by being subtly wrong, not by crashing. A crash you notice. A recompete window that silently went stale, or an enriched contact that quietly went to the wrong person, those erode trust without a single error in the logs.

So the real work was not the integrations. It was making each seam observable: every signal carrying its provenance, every enrichment carrying its confidence, every sent message carrying its trail. This is the same instinct I’m now building into Vontra — provenance is a first-class column, not an afterthought. The integrations were a weekend. Making them trustworthy was the year.

That is the part nobody puts in the demo, and it is the only part that decides whether the thing survives contact with a real pipeline.