Agencies buy commercial data constantly. Most of those licences are used lightly, renewed reluctantly, and eventually not renewed at all. The ones that become permanent line items share a property that has nothing to do with the quality of the underlying data: the agency was able to put it inside its own systems and build things on top of it. That is an engineering outcome as much as a commercial one, and it is decided by what the licence permits and what the delivery package contains.
This is written for the person who owns data licensing or partnerships at a company selling private-company information, credit data, market data or any proprietary reference set. The commercial motion you already know. What follows is the part that determines whether the second year happens.
How an agency actually consumes a dataset
A commercial customer often consumes data through your interface. An agency usually cannot. The analyst who needs your data works in a system that was built years ago, sits behind a network boundary, and joins your records to internal records that never leave it. If your product is a portal, the agency buys seats, a handful of people log in occasionally, usage looks thin at renewal, and the contract dies.
The licences that renew are the ones where your data became infrastructure. Someone loaded it into the agency's warehouse, joined it to internal identifiers, and built a report, a screening step or a model on top of it. Once that happens, removing your data breaks something the agency depends on, and renewal stops being a discretionary purchase.
Everything below follows from that single observation. The goal of the licence and the delivery package is to make that integration possible, easy and permitted.
What the licence has to allow
Standard commercial data terms are written for a world where the customer uses the data through your product and few people touch it. Several of those clauses, transplanted into a government agreement, quietly prevent the integration that makes the licence valuable.
- Storage in the customer's systems. Terms that permit access but not retention make a warehouse load a breach. The licence needs to allow the agency to store the data in its own environment for the licence term, because that is the only way it gets used.
- Derived works. Analysts will join your data to internal data and produce scores, flags and reports. If derived outputs are restricted or claimed, the agency's counsel will read that as a claim on internal work product and the deal will stall. Permit derived works for internal purposes explicitly, and if you need to restrict resale, restrict resale rather than derivation.
- Named users versus the enterprise. A per-seat licence in an agency is a mismatch. Work does not stay in one office and the roster changes. A defined-population licence, by component or by mission area, is easier to administer and closer to how the customer actually operates.
- Retention after termination. If a decision was made in year two using your data, the agency may need to reconstruct that decision in year five. A licence that requires deletion on termination collides with the customer's own record obligations. An archival-use carve-out, allowing retention of the data as it existed for reconstruction and audit but not for new analysis, resolves it.
- Support and contractor access. Agencies work with support contractors. A licence limited to government employees is unusable in practice. Define the permitted population functionally, as people working on the agency's behalf under its direction.
- Publication of results. Agencies publish. If the licence forbids any disclosure of anything derived from the data, that is a blocker for many missions. Permit publication of aggregate results while protecting redistribution of the underlying records.
None of these are concessions in substance. They describe what the customer will do anyway if the relationship works, and writing them down early prevents a legal review that runs for months and then produces a narrower deal than either side wanted.
What determines whether a data licence renews
Editorial weighting, illustrative rather than measured. The last row is deliberately low: seat count in year one is the weakest predictor of a year-three renewal.
What the data has to carry
The technical package is where a licensing conversation is usually won or lost, because the buyer's engineers are the people who will say whether this can be used. Their concerns are narrow and predictable.
A stable identifier. The single most important property. Every record needs an identifier that persists across refreshes, survives a name change or a restatement, and never gets reused for a different entity. Without it the agency cannot maintain a join, cannot keep its own annotations attached, and has to rebuild the mapping every load. If your identifiers are derived from source keys that change, fix that before selling into this market. When an entity splits or merges, the identifier history has to be expressible, meaning a record of which identifiers superseded which and when.
Crosswalks to identifiers the buyer already has. Agencies key entities by public registration identifiers of various kinds. Every crosswalk you supply from your identifier to one of theirs removes weeks of work on their side and makes your data joinable on arrival. This is often the highest-value engineering you can do for this market, and it is rarely on a commercial roadmap.
Lineage. For each field, where the value came from and when it was observed. Government users are frequently required to say why they believe something, and a value with no provenance is one they have to independently confirm, which erases the reason they bought the data.
Refresh cadence and change delivery. Full-file delivery on a schedule is workable at small volume and painful at large. A delta feed with explicit adds, changes and deletes, plus a periodic full file for reconciliation, is what a competent data engineering team wants. Every changed field should carry an effective date.
Point-in-time reconstruction. The buyer needs to answer what the data said on a given past date, because decisions get reviewed against what was knowable at the time. Bitemporal storage on your side, with a valid-from and valid-to on each version of each field, makes this a query. Without it, the answer requires archived files and hope.
Coverage statements. Not a marketing claim of total records, but a statement of what proportion of a defined population you cover, by segment, computed by a stated method. Buyers who can quote your coverage in their own documentation defend the purchase internally. Buyers who cannot are exposed every time someone asks whether an entity is missing.
Quality measures. Field-level completeness by segment, a stated refresh lag distribution, and a defined error-reporting path with a committed correction time. These are unglamorous and they are what a sophisticated buyer's technical evaluation actually scores.
Programme licence, enterprise licence, and the space between
The licensing shape matters more in this market than in a commercial one, because the buying entity is layered. A single office may hold the budget while the useful population spans several components, and the boundary you draw determines both the ceiling on the deal and the amount of administration it generates.
| Structure | Who is covered | Where it works | Failure mode |
|---|---|---|---|
| Named seats | Individually listed users | A pilot, or a small analytical office with stable staff | Usage looks thin at renewal; sharing rules get broken informally; roster churn creates administration nobody wants |
| Programme or office licence | A named organizational unit, unlimited internal users | The common first real deal; scope is legible to the buyer | Adjacent offices want in and each expansion is a new negotiation |
| Enterprise licence with tiers | The whole department, priced by a stated population or volume band | Once more than two components use it; simplest to administer | Sold too early it caps the account below what components would have paid separately |
| Licence plus implementation | Any of the above, with engineering to integrate it | Whenever the buyer lacks the engineering capacity to load and join it | Priced as data alone, the implementation is unfunded and the integration never happens |
The last row is the one most often left off the table and it is where renewals are made. A dataset the buyer never integrated is a dataset that does not renew. Selling the integration alongside the licence, as a separate priced element, converts an at-risk subscription into infrastructure. It also gives you visibility into how the data is actually used, which is the best product input you will get from this market.
The technical package that makes the buyer's engineers say yes
Before a technical evaluation, assemble a package that answers the engineer's questions without a meeting. It is a few days of work and it removes the largest source of delay.
- A data dictionary with every field, its type, its permitted values, its source, its update frequency and its completeness by segment. Generated from the system, not maintained by hand, so it cannot drift.
- A representative sample large enough to test a join. Not curated to look good. Engineers evaluating a dataset are looking for the messy cases, and a sample without them signals that the messy cases were hidden.
- Delivery mechanics in writing: the transport, the file format and compression, the naming convention, the schedule with a time zone, the delta semantics, the reconciliation method, and what happens when a load fails.
- Schema change policy: notice period, a compatibility commitment, and how deprecations are announced. A buyer whose pipeline broke once without warning remembers it at every renewal.
- An interface specification if you offer one, with versioning, rate limits and an authentication method compatible with a customer environment rather than a browser session.
- A security description: where the data is generated and stored, how it is transmitted, and what happens to any data the customer sends you. If the answer to the last question is "nothing, because we never receive customer data", say so plainly, because it removes an entire review.
- Accessibility conformance for any interface, based on an assessment rather than an assertion.
The pattern behind all seven: answer the question before it is asked, in writing, from the system rather than from marketing. Technical buyers read a package like this as evidence that the vendor is run by people who have integrated data before, which is the impression that carries the deal.
Where a technical evaluation of a dataset actually spends its attention
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a headline record count tells a technical evaluator almost nothing about coverage of their population.
Pricing shape, not price
The price level is your commercial judgement. The shape is an engineering-adjacent decision and it affects renewal more than the number does.
Price against a stated population or volume band rather than counted seats, because seats generate administration and understate the value. Publish the tier boundaries and the method by which a tier is determined, so the buyer can predict next year's number and defend it internally now. Separate the data licence from implementation and support as distinct priced elements, so that when a budget is tight the customer can flex one without cancelling the other. Price multi-year with option periods rather than a single long term, because that matches how the customer's funding works and it gives you a scheduled conversation rather than a cliff. And state what a price includes in terms of refresh frequency, history depth and correction commitments, because a buyer comparing offers will otherwise assume the cheapest terms.
One thing to hold rather than publish: per-customer discounting logic. Publish structure and tiers, not the concessions. A buyer who discovers an inconsistent structure loses trust in the relationship, and this market talks internally more than a commercial one does.
Delivery into a controlled environment
A share of this market cannot pull data from your infrastructure over the public internet. If your only delivery mechanism is an interface on your servers, those customers are unreachable, and they are frequently the ones with the largest budgets.
Design delivery so the data can land in a place the customer controls. That means a transfer mechanism into a storage location the customer owns, with the customer's own encryption and access controls, and a manifest with checksums for every delivery so the customer can verify completeness without contacting you. It means a loader the customer can run rather than a pipeline that must reach out to your systems. It means licensing and entitlement enforced by contract rather than by a runtime callback, because a callback that cannot reach you turns into an outage inside a network that was never going to permit it.
None of this is technically hard. It is a set of assumptions that have to be removed, and removing them late costs a procurement cycle.
How we work with a data company selling into this market
Precision Federal builds data platforms and delivers them into production, including inside federal agencies. On a licensing programme we build the technical side of what you are selling: the identifier and crosswalk layer, the delta feed, the bitemporal history, the coverage and quality measurement, the delivery mechanics into controlled environments, and the documentation package the buyer's engineers read.
The first three weeks produce a written assessment of your dataset against the properties a government buyer evaluates, field by field, with the gaps named; a specification for the identifier and crosswalk layer, including how identifier history is expressed when entities merge or split; a delivery design covering full, delta and controlled-environment paths with the manifest and reconciliation method specified; and a working delta feed for one slice of the data, running end to end, so the mechanics are demonstrated rather than described.
After that the work runs in fixed increments with acceptance criteria agreed before each begins: the crosswalk build and its measurement, bitemporal storage and the point-in-time query surface, generated data dictionary and coverage statements, the delivery and loader package, and the security and accessibility documentation.
You keep everything. Code in your source control under a written assignment, data in your environment, documentation as your asset. Your engineers work in the codebase with ours so the system is operable by your team from the first week. Your customer relationships stay yours, and we stay unnamed unless you want us named.
Pricing is fixed-price by milestone where scope is defined, or a committed team at a fixed monthly rate where you want capacity you direct. Not hourly.
The first step is one email with a one-page brief: what the dataset covers, how it is delivered today, which identifiers it carries, and what a buyer has already asked for that you could not answer. We return a scoped, priced statement of work with the increments and acceptance criteria written out.
Bottom line
A government data licence renews when the data became part of the customer's own systems, and it becomes part of those systems only if three things are true: the licence permits storage, derived works and access by people working on the agency's behalf; the data carries a stable identifier with crosswalks to identifiers the buyer already keys on, plus lineage, delta delivery and point-in-time history; and the delivery mechanism can land the data in an environment the customer controls without calling back to yours. Sell seats and you get a pilot. Sell something a competent data engineering team can integrate in a fortnight and you get a line item that survives budget review.
Frequently asked questions
Storage of the data inside the customer's own systems for the term, because access without retention prevents the warehouse load that makes the data useful. Derived works for internal purposes, since analysts will join your records to internal records and produce their own outputs. Access by support contractors working under the agency's direction, defined functionally rather than limited to government employees. Retention after termination for reconstruction and audit of past decisions, distinct from continued analytical use. And publication of aggregate results, while restricting redistribution of the underlying records.
Because the data never got integrated. If consumption happens through a vendor portal, a small number of people log in occasionally, usage looks thin at renewal and the line item is easy to cut. Licences that renew are the ones where the data was loaded into the customer's warehouse and joined to internal records, so removing it would break a report, a screening step or a model something else depends on. That outcome is decided by the identifier design, the delivery mechanics and the licence terms far more than by the quality of the underlying records.
A stable identifier that persists across refreshes, survives name changes and restatements, is never reused for a different entity, and carries a history expressing which identifiers superseded which when entities merged or split. Alongside it, crosswalks from your identifier to the public registration identifiers the buyer already keys on, which removes weeks of matching work on their side. Then field-level lineage, a delta feed with explicit adds, changes and deletes plus a periodic full file for reconciliation, and effective dates on changed fields.
Named seats suit a pilot or one small analytical office with stable staff, and little else. Work in an agency does not stay in one office and the roster changes, so seats generate administration and understate the value. A programme or office licence covering a named organizational unit is the usual first real deal. An enterprise licence with published tiers based on a stated population or volume band is simplest once more than two components use the data, though selling it too early can cap the account below what components would have paid separately.
Whether it can be joined to what the buyer already has and stay joined through refreshes. What happens to their pipeline when your schema changes, which means the notice period and compatibility commitment. Field-level completeness on the specific segment they care about, not a total record count. Whether they can reconstruct what the data said on a past date. And how corrections are reported and how quickly they land. Supply a generated data dictionary, an uncurated sample large enough to test a join, and written delivery mechanics, and most of the evaluation answers itself.