A federal program office does not buy a data feed. It buys an answer that appears inside a system its people already sign into, with a record of where every number came from. That distinction explains most of what goes wrong when a ratings, risk-data or analytics company decides to sell to government. The commercial motion is a licence: negotiate seats, deliver an API key or an SFTP drop, renew annually. The federal motion is a program: the data has to land inside an accredited environment, join to identifiers the agency already uses, survive a security review, and produce something an analyst can defend to an inspector general. A licence alone stalls at the program office because nobody there has the engineering budget or the calendar to turn a feed into a working capability.
This is written for the person who owns public-sector revenue at a data company and has watched a promising conversation go quiet after the technical review. The problem is almost never the data. It is that the buyer was asked to do the integration, and the buyer cannot.
What the agency is actually trying to do
Start with the work, not the product. A contracting officer screening a new vendor wants to know, in the same session, whether that vendor is the same legal entity as one already suspended, who owns it, whether its financial condition suggests it will still exist in eighteen months, and whether any of that has changed since last quarter. An analyst at a financial regulator wants to see an entity's exposure across affiliates, not a list of names that look similar. A grants office wants to know whether a nonprofit applicant is financially able to carry the match. A program integrity team wants an alert when a supplier's ownership changes shortly before a large award.
Every one of those is a question about a specific entity at a specific moment, answered inside a workflow the agency already has. None of them is satisfied by a file. The gap between the file and the answer is engineering work: identifier reconciliation, a place to put the data, a query layer, a user interface or an API the agency's own system can call, logging that shows who saw what, and a security posture that lets the whole thing exist on a government network.
Data companies often assume the agency will supply that engineering. Sometimes an integrator does. Far more often the program office has one technically fluent person, a queue of higher-priority work, and no appetite to become the systems integrator for a vendor's product. The deal dies quietly and gets recorded as a budget problem.
What decides whether a data offering becomes a program of record
Editorial weighting, illustrative rather than measured. The last row is deliberately low: catalogue breadth is what the seller talks about and rarely what the program office decides on.
Entity keys are the whole first conversation
A commercial customer will happily map a vendor's internal company identifier to its own. A federal customer usually cannot, because its identifiers are set by policy and shared across systems. Agencies key contractor records on the Unique Entity ID issued through the federal registration system, and older records still carry legacy nine-character codes. Financial regulators work with Legal Entity Identifiers and with filing identifiers assigned by the relevant registry. Grant recipients carry their own registration numbers. Tax-related processing keys on employer identification numbers the agency may hold but cannot share outward.
A data company whose spine is its own proprietary company key has, from the agency's side, a translation problem rather than a data product. The first engineering question in any federal deal is therefore concrete: what fraction of the agency's population of entities can we resolve to our key, with what confidence, and what happens to the remainder?
That question has a measurable answer, and producing it early is the single most effective thing a data company can do to move a stalled deal. The method is unglamorous. Take a sample of the agency's own entity list, run it through resolution, and report four numbers: exact matches on a shared identifier, high-confidence probabilistic matches, low-confidence matches needing review, and no match. Then show what the unmatched tail looks like, because the tail is usually where the agency's actual interest lives: newly formed entities, foreign parents, small suppliers, and organizations that changed names.
An agency that sees those four numbers on its own data is having a different conversation than one being shown a catalogue. It can now compute what the product is worth. Provide it, and the technical review becomes a design session instead of an interrogation.
Provenance is a product feature, not documentation
Commercial buyers accept a number. Federal users have to defend one. When an analyst recommends withholding an award, denying a grant, or opening a review, someone eventually asks where the fact came from. If the answer is that a vendor's platform said so, the analyst is exposed and will stop using the product for anything consequential.
What that means in engineering terms is that every value the system displays has to carry, at minimum: the source it came from, the date the source published it, the date the platform ingested it, the transformation applied, and the confidence attached to any inference. Not in an appendix. In the row, retrievable through the same API call that returned the value, and renderable in the interface next to the number.
This is a data-model decision made at the beginning or paid for painfully later. A schema that stores a company's revenue as a single column with a timestamp cannot answer where it came from. One that stores each observation as a fact with a source, an as-of date, an ingestion date and a method, then computes a current view over those facts, can answer everything, including what the system believed on a given date last year. That last capability matters more than it sounds: audits and reviews ask what was known at the time of the decision, not what is known today.
Point-in-time reconstruction is also what makes analytics defensible. A model that scores supplier risk is worth little to a federal user unless the score can be reproduced from the inputs available on the date it was issued. Build the fact store first and the reproducibility comes free. Retrofit it and it is a rewrite.
The deployment question that decides the deal
Federal buyers vary widely in what they can consume. The pattern that fails most often is the one that works everywhere else: a multi-tenant commercial cloud application accessed over the public internet with the vendor holding the credentials.
There are four workable shapes, and knowing which one an agency needs before the first meeting saves a quarter.
| Delivery shape | What the agency gets | What it demands of the data company | Where it fits |
|---|---|---|---|
| Authorized cloud service | The vendor's own application, accessed as a service, inside a federal authorization boundary | A government cloud region, a control set implemented and assessed, continuous monitoring, a sponsor | Broad use across many agencies; highest cost, highest reuse |
| Data delivered into the agency's platform | Curated data landing in the agency's own warehouse or lakehouse, refreshed on a schedule | A pipeline, a documented schema, provenance columns, delivery monitoring, a support path | Agencies with a real data platform and a team to use it |
| Analytics deployed in the agency environment | Query layer, scoring and screens running inside the agency boundary on the agency's hardware or tenancy | Deployable artifacts, infrastructure as code, an offline install path, documented dependencies | Sensitive missions; the fastest route past a data-egress objection |
| Embedded in a program's system | The vendor's answers appearing inside a system the agency already runs | A stable API, identifier mapping, latency commitments, versioning that does not break the host | The stickiest position; hardest to displace once live |
Most data companies attempt the first shape because it looks like their existing business. It is the slowest and most expensive route, and it is often the wrong one, because the mission that most wants the data is frequently the one that least wants the data leaving its boundary.
What an accredited deployment actually requires
Selling into a federal environment means the system will be assessed against a control catalogue before it carries real data, and the assessment looks at the system as built rather than at the company's policies. The controls that surprise commercial engineering teams are consistent.
- Identity that is not yours. The agency's users authenticate with the agency's identity provider and their government credentials. Password-based accounts issued by the vendor will not pass. Plan for federated sign-in and for role mapping driven by group membership the agency controls.
- Audit logging that answers questions about people. Not application logs. A record of which named user viewed which entity's record at what time, retained on the agency's schedule and exportable in a form a reviewer can read.
- Separation of duties inside the product. The person who can change a scoring rule should not be the person who can approve its use. Commercial products often collapse those roles into one administrator.
- Encryption with the agency's keys where required. Some environments require customer-managed keys and will ask who can access the key material. A design where the vendor can decrypt customer data is a finding.
- Accessibility as an acceptance condition. Federal software must meet accessibility requirements, and it is checked with real assistive technology, not a scanner. Data-dense interfaces with custom tables and charts are where products fail. Fix it in the component library once rather than per screen.
- A supply chain you can describe. A software bill of materials, a statement of where components come from, and a patch commitment with stated timelines.
- Records and retention. Government records rules may apply to what the system stores, including analyst annotations. Deletion behaviour that is fine commercially can be a compliance problem here.
None of these is exotic, and each is a place where a product built for commercial customers has a specific, findable gap.
Why the licence alone stalls
Consider the sequence from the program office's side. A vendor offers a licence at a price the office can nearly afford. Accepting it creates work the office must fund separately: an integration, a security assessment, a place to run it, a support model, and a training plan. That second budget usually does not exist, and requesting it means a new justification, a new approval and a new schedule. The path of least resistance is to keep talking and never buy.
The same office will move quickly on a proposal that arrives complete: the data, the layer that makes it usable, the deployment into their environment, the security artifacts, and a named party accountable for it working. That is one procurement instead of three, and one accountable party instead of a vendor pointing at an integrator pointing back.
This is why a data company's federal strategy is really an engineering strategy. The catalogue is the raw material. The product is the deployed capability.
The analytics layer that turns data into a program
Between the raw data and the agency's question sits a layer most data companies have only partly built, because commercial customers built it themselves. Its parts are specific.
A resolution service. Given the identifiers and names an agency holds, return the vendor's entity key with a confidence and an explanation. Exposed as an API, so the agency's systems can call it during their own processing rather than exchanging files.
A hierarchy service. Given an entity, return its parents, subsidiaries and affiliates as of a date, with the source of each relationship. Ownership questions are where federal interest concentrates, and ownership is the part of corporate data that changes most and ages worst.
A scoring service with governance. Any derived score needs a documented method, a versioned model, recorded inputs, a monitoring plan and a human override path with a reason code. Regulated financial institutions expect this because model risk management guidance requires it. Federal buyers expect the same discipline for the same reason: someone will eventually ask why the number moved.
A screening and alerting service. Watch lists of entities, evaluate on each refresh, emit an event when a defined condition changes. This is where a licence becomes a subscription with real switching costs, because the agency builds its workflow on the alerts.
An evidence service. Capture what an analyst saw, when, and what they concluded, in a package that can be attached to a case file. It sounds like a small feature. It is the difference between a tool people try and a tool people rely on.
Building those five turns a catalogue into a platform. Each one is also independently sellable to large commercial customers, which is the argument for funding the work regardless of how the federal channel develops.
Where a federal deal is most often lost, by stage
Editorial weighting, illustrative rather than measured. The last row is deliberately low: price is rarely the reason a data deal stops.
An illustrative shape of the first eighteen months
The following is a worked example rather than a claim about any particular agency. A data company with a strong commercial franchise and no federal revenue wants a program of record.
- Months one to two. Pick one mission and one question. Build the resolution report against a sample of that agency's public entity population and put four numbers in front of the program office.
- Months two to five. Build a working analytics layer over the vendor's own data answering that one question end to end, deployable as containers with infrastructure as code, federated sign-in, provenance in the interface, and accessibility built into the components. Fund it internally. It is a product asset, not a proposal cost.
- Months four to eight. Deploy it into a government cloud region as a demonstration environment with synthetic or public data, and produce the security documentation as artifacts rather than promises. Let the agency's security staff read the real thing.
- Months six to twelve. Run a paid pilot inside the agency boundary with a defined scope, measured acceptance criteria, and an exit that leaves the agency with something working.
- Months twelve to eighteen. Convert to a program: a sized contract with a defined user population, a support model, and a roadmap the program office had a hand in writing.
The expensive lesson embedded in that sequence is that the demonstration environment comes before the procurement conversation, not after it. Federal buyers reward a working thing they can touch far more than they reward a proposal describing one.
How we work inside a data company
Precision Federal is an engineering firm. We build AI systems, data platforms, APIs and full-stack applications, and we deploy them into production, including inside federal agencies. For a data company, that combination is the point: we have built the analytics layer, and we have taken systems through the security and accessibility gates that decide whether a federal deployment happens.
What the first weeks look like. We read the data model and the existing delivery paths, then we build the resolution report described above against a real sample so the entity-coverage question has a number attached to it. In parallel we produce an architecture for the deployable analytics layer: the services, the storage design with provenance as a first-class concept, the identity integration, the deployment topology for a government cloud region, and the control mapping that the security assessment will follow. That is typically four to six weeks and it ends with a document your engineering leadership and your public-sector team can both act on.
Then we build. Our engineers work as a committed team inside your development process, using your repositories, your standards and your review gates, or we take a fixed-price milestone with written acceptance criteria if the scope is well bounded. Both shapes are ordinary for us. What we do not do is deliver a slide deck and leave the implementation as an exercise.
What you keep. All of it. The code is yours, assigned in writing, in your repositories from the first commit. Your data stays in your environment and is never used to train anything of ours. The customer relationship is yours; we can be named as your engineering partner where that helps in a federal setting, or work entirely behind your brand. Our pre-existing tooling is named and carved out, and you get a perpetual licence to use it inside what we deliver, so nothing we bring can strand a future maintainer.
Pricing takes one of two shapes. Fixed-price milestones with measurable acceptance criteria when the scope is definable, which is usually the case for an architecture, a resolution service, or a deployment package. A committed team at a monthly rate when the work is a sustained build and priorities will move. We will tell you which one fits before you ask.
The first step is one email with a one-page brief: the mission or agency you are aiming at, the data assets involved, the identifiers your platform keys on, where you want the system to run, and the date that matters. We return a scoped, priced statement of work.
Failure modes we see repeatedly
Selling the catalogue instead of the answer. A capability briefing about coverage and update frequency answers a question the program office is not asking. Show one screen answering one mission question and the conversation changes.
Treating entity resolution as a detail. It is the deal. An unquantified match rate against the buyer's own population is the most common reason a technical review ends without a next step.
Building the pilot where it can never be deployed. A demonstration on a commercial account with a public endpoint has to be rebuilt before it can carry real data. Build it in a government cloud region from the first sprint, even for a demonstration.
Leaving accessibility to the end. Data-dense products fail accessibility review in the table and chart components. Discovered at acceptance, it delays a launch by months. Fixed in the component library, it costs weeks once.
Letting the model be a black box. A score without a documented method, a version, recorded inputs and an override path is unusable for consequential decisions. The governance is the feature.
Assuming the integrator will do the engineering. Sometimes true. Often the integrator has its own product and no incentive to make yours indispensable. Own the layer that makes your data usable.
Bottom line
Federal agencies buy capabilities, not feeds. A data company that arrives with a catalogue and a licence is asking the buyer to supply the missing engineering, and the buyer usually cannot. A data company that arrives with a resolution report against the agency's own entities, an analytics layer that answers one mission question end to end, a deployment that runs inside the agency's boundary, provenance visible next to every number, and security and accessibility artifacts that exist rather than being promised, is selling something the program office can actually buy. That gap is engineering work, it is finite, and every piece of it also makes the commercial product stronger.
Frequently asked questions
Because a feed creates work the program office must fund separately: integration with the identifiers the agency keys on, a place to run it inside an accredited environment, a security assessment, an interface or API its people can use, and a support model. That second budget usually does not exist, so the licence conversation stalls. A proposal that arrives complete, with the data and the layer that makes it usable and the deployment, is one procurement instead of three and one accountable party instead of several.
Entity resolution is the process of deciding that two records naming a company are the same company. It matters because agencies key their records on identifiers set by policy, not on a vendor's internal company key, so the vendor's data has to be joined to the agency's population before it answers anything. The practical test is a coverage report against a real sample of the agency's entities showing exact matches, high-confidence matches, matches needing review, and no match, plus a description of what the unmatched tail contains.
A government cloud region, sign-in federated to the agency's identity provider using government credentials, audit logging that records which named user saw which record, separation of duties inside the application, encryption arrangements the agency accepts, accessibility that passes with real assistive technology, a software bill of materials with a patch commitment, and records retention behaviour that matches government rules. Each is far cheaper designed in than retrofitted, and each is a common gap in products built for commercial customers.
Store each observation as a fact carrying its source, the source's publication date, the ingestion date, the transformation applied and any confidence, then compute the current view over those facts. That design lets the system answer where a value came from, show it in the interface next to the number, and reconstruct what was known on the date a decision was made. Point-in-time reconstruction is what makes derived scores defensible when someone reviews the decision later.
Plan on twelve to eighteen months and stage it. Quantify entity coverage against the target agency's population first. Build a deployable analytics layer that answers one mission question end to end, funded internally as a product asset. Stand up a demonstration environment in a government cloud region with real security artifacts before the procurement conversation. Then a paid pilot inside the agency boundary with measured acceptance criteria, then conversion to a sized contract with a support model and a roadmap the program office helped write.