PriceProof

Methodology

This page documents how a figure gets onto PriceProof: where the data comes from, which records are searched, how a product is matched, what has to be true before a page is published, and — importantly — where the method is weak. It is written so that a reader could reproduce the work and check us.

1. The source

Every award figure on this site comes from USAspending.gov, the official public record of US federal spending maintained by the Treasury Department. We query its public award-search API, keyless, at api.usaspending.gov/api/v2/search/spending_by_award/ and read contract awards — award type codes A, B, C and D, which cover definitive contracts, purchase orders and the delivery orders that carry most software purchasing.

The fields we take from each award are: the generated award identifier, the recipient name, the awarding agency and sub-agency, the award amount, the action date, the award description, the Product Service Code, the NAICS code, and any line-item text. Responses are cached to disk and re-used, both because the source asks callers to be gentle with it and because caching makes our own runs reproducible: the same query returns the same rows on a later run.

Every figure we publish carries the generated award identifier, which resolves to a page on USAspending.gov. If you want to check a number, that link is the shortest possible path from our page to the government's own record.

2. What we search

The current category is data and analytics platforms. Its search window runs from 1 October 2021 to 5 October 2026 — the last five federal fiscal years — because older award records are increasingly incomplete in the fields we depend on, and software pricing from a decade ago tells a buyer little.

Two searches are run and their results merged. The first is a keyword sweep: every alias in the product list is searched directly. The second is a classification sweep: awards carrying the category's Product Service Codes are pulled and then filtered by product alias. Neither sweep decides anything on its own — see section 4.

3. Classification codes narrow the universe

We use Product Service Codes (PSC) and NAICS codes to narrow which awards are worth looking at. The codes are taken from the official PSC manual and NAICS documentation, not guessed, and the exact codes used — with their official titles and why each was included — are recorded on the category page and in the project's code register.

Two rules govern their use. First, codes narrow; they never match. Carrying code D305 does not make an award a Snowflake purchase, and no product is ever matched on a code. Second, some codes are excluded — the ones that sweep in office supplies, hand tools, and other non-software purchasing that shares a code family with IT services. Exclusions were derived empirically, by looking at what actually came back and seeing what did not belong.

4. Matching a product, and the hard rule

The product must be explicitly named in the award for it to count. Matching runs against the award description, the line-item text and the award title. Names are normalised for case and punctuation and then matched as whole tokens — "Snowflake" matches "Snowflake" and "Snowflake Computing", but a substring hit inside an unrelated word does not qualify.

Matching on any of the following alone is not sufficient for a page:

Every match records how it was made and a confidence value. Matches below the configured minimum confidence are dropped and counted, never guessed at or promoted by hand. Each product's alias list also carries negative guards — for example, a product whose name collides with an unrelated term in government contracting is excluded from matching when that other term is present — so that a coincidental string match cannot become a published figure.

5. Resellers — attribution, not discovery

Much public-sector software is bought through resellers, and the recipient on the award is then the reseller, not the vendor. Reseller relationships are recorded in a mapping, and where an award names a product but the recipient is a known reseller, the award is attributed accordingly and the attribution is shown.

The direction matters: a reseller relationship narrows, it never creates. Knowing that a company resells a product never turns an award into a match for that product. The product still has to be named in the award text. The reseller mapping only tells the reader who the money went to.

6. What a figure is — four evidence types

Every figure is stored with a type, and its type is printed next to it wherever it appears. Types are not interchangeable, and this site does not compare across them.

TypeWhat it isWhat it is not
contract_total The value of one award, as recorded. Not a unit price, not a licence price, not comparable with another award's total.
unit_price A price per unit stated explicitly in the award text. Not a total, and not applicable to awards that do not state one.
derived_unit_price Computed from an amount and a quantity stated in the same award. Not a vendor price; a derived figure, and labelled as one.
list_price The vendor's own published price, with URL and quote. Not what any buyer paid; comparable only with other list prices.

Contract totals are also screened for what they contain. Where an award's text shows it bundles non-software cost — hardware, training, integration labour — that is recorded and shown, because a total carrying those costs is not a software figure and the reader is entitled to know before comparing it with anything.

7. What the award actually bought — the scope classifier

An award naming a product is not automatically a price for that product. One federal record might be a licence renewal; the next might be three years of implementation labour with the software bundled in; the next might be a funding modification that adds money to a contract signed years earlier without buying anything new. Averaging those together would produce a number that describes none of them.

So every award is classified by what its description says it bought. The classifier is deterministic — a fixed set of textual signals, applied in a fixed order, with no model involved — and it assigns exactly one label:

ScopeWhat it means
licenseThe award buys the right to use the software: licences, subscriptions, seats, users, cores, capacity.
renewalThe award renews or extends something already held — a renewal, an annual subscription, maintenance on an existing entitlement.
supportSupport only: premium support, a technical account manager, maintenance detached from a licence purchase.
trainingTraining, enablement, certification or workshops.
servicesImplementation, migration, integration, development or other labour.
bundleThe description names this product and a product from another vendor, so the amount is not attributable to either alone.
modificationA modification to an existing award, including incremental funding — the amount is an adjustment to a contract, not a purchase.
unknownThe description does not say enough to classify. Not guessed.

Only license and renewal awards move the headline figures. The band at the top of a product page, its median, its range and its total are computed from those two scopes alone. Every other award is still published, still listed in the evidence table with its scope, and still counted — but it does not enter the arithmetic. Where a product has fewer than three licence or renewal awards, the page says so and falls back to every recorded award, labelling the figures as a range rather than a rate.

Two consequences worth stating plainly. First, the headline band is a band of contract totals: it says what agencies were awarded, not what a licence costs. Second, this classifier reads text, and text is written by contracting officers with no obligation to be legible to us. It will be wrong sometimes, in both directions. The label is shown for every row so that a reader who disagrees can see exactly which awards we put where.

8. The threshold for publishing

A product earns a page only if it clears a fixed bar:

Every award behind a page must carry an award identifier, a recipient, an awarding agency, an amount, an action date and a resolving source URL. A product that falls short gets no page — not a shorter page, not a page with a caveat. It is recorded in the rejected set with the reason it failed, and the count of rejections is shown on the index so that the threshold is visible rather than hidden.

This is a fail-closed design and it is the point of the site. A page built on a single award is a page that tells a buyer nothing they can rely on, and it is the kind of page this publication exists to avoid.

9. How the prose is written and checked

Figures are computed by code. A language model writes a limited part of the prose — the opening sentences, the renewal notes and the FAQ answers — from that product's evidence file alone. It may not introduce any number, vendor, agency or award not already in the file. Every number it writes is extracted and matched against the file; an unmatched number fails the page. Every qualitative sentence is checked against the awards it cites, and a sentence that fails is rewritten and then dropped. The model never selects products, awards or figures. The full disclosure is on the editorial policy page.

That is the boundary for product pages. The newsroom is the one place where a model is shown text this site did not compute, and it is shown it under stricter conditions rather than looser ones: a fact from the web is admitted only if its own wording can be quoted back from the page it came from, verified in code. Section 10 sets out how that works and what it refuses.

10. How a desk piece is made, and what is refused

The newsroom publishes two kinds of piece: pieces a person wrote and signed, and pieces written and published by the PriceProof Records Desk, an automated desk. Nothing below applies to the first kind. A desk piece is published with no human review, which is stated here and in the editorial policy. A desk piece is also marked as one on its own page, under a desk byline rather than a person's name.

What starts a piece. Not a model's judgement. A deterministic stage scores new awards from the official record against thresholds fixed in advance — the size of the obligation, whether the award drew a single offer, whether it is the product's first purchase by that agency, whether the ceiling on the vehicle is large. An award is written about only if its score clears the bar, at most a few pieces are written per run, and an award already covered is not covered again unless its obligation moved materially. A ledger records every award that has been considered and what happened to it. The same evidence always selects the same awards in the same order, so a rebuild cannot reshuffle the feed.

What a piece is built from. Three things, and nothing else. The record facts: the award's own fields from USAspending, read by code — the vehicle it was placed under, whether it was competed and how many offers came in, the pricing type, the obligated amount against the ceiling, the recipient's public business categories, the place of performance, the Product Service Code title. The award's evidence: the same computed figures the product pages use. And the researched facts: claims taken from public pages — the agency's and recipient's own published records, the vendor's public pages, government and press coverage, reference works.

How a researched fact is admitted. This is the part that matters. The drafting model is not asked to summarise or paraphrase. It is asked to return, for each claim, the verbatim quotation it is relying on, the number the claim asserts if any, and the URL it came from. Code then re-fetches that URL and tests the quotation as a literal substring of the text that was actually fetched. A fact whose quotation is not present is discarded; a number that does not appear inside that quotation is discarded with it. Because the model writes no prose at that step, it cannot rephrase its way past the test — an invented fact simply does not survive to the writing stage. The fetched text is stored alongside the extracted facts, so what the model was working from can be audited after the fact.

Those pages are untrusted input, so they are treated as data and never as instruction: they are passed in a delimited block labelled as untrusted, never placed in the system prompt, never allowed to influence control flow — no URL, filename, threshold or config value is ever read out of fetched text — and lines that read as instructions addressed to an assistant are stripped before use.

What fails a desk piece. The gate that checks hand-written articles checks these too, and refuses publication on any of:

A piece that fails is not published and the failure is recorded. Quiet runs produce nothing. That is the designed behaviour, not a fault: the alternative is filler.

11. Where this method is weak

An honest method section has to name its own failure modes. Ours are:

Products with the weakest evidence are visible as such: they are the ones with the fewest awards, and their pages say how many awards they rest on. We would rather publish a well-labelled page on thin evidence and say so than quietly pad it.

12. Checking us

Every award figure links to its record on USAspending.gov. The fastest way to audit any page is to follow those links and compare. If a figure does not match its record, write to [email protected] — the editorial policy explains how corrections are handled, and a correction is applied at the source of the computation so that every page drawing on that record is fixed at once.