Every number on this site is citable.

The Acquint warehouse covers DoD-funded contract obligations, sub-awards under those contracts, IDV parents, and the document corpus that contextualizes the spend (J-Books, GAO reports, OIG reports, CRS products, Federal Register notices). We distinguish three terms that the field uses interchangeably and we do not:

• DoD-awarded — the awarding toptier agency is 097. The FPDS prime-contract picture most people mean when they say “DoD spending.” Source: silver.contracts, ingested from the USAspending FPDS monthly archive ZIP for agency 097.
• DoD-funded — the funding toptier agency is 097, regardless of who awarded the contract. Includes contracts awarded by civilian agencies (DoE national labs, GSA Schedules, Interior GovWorks, NASA) using DoD money. Source: silver.contracts_civilian_awarded, via the USAspending search API.
• DoD-related — anything in the broader defense-industrial ecosystem (intelligence community, DOE/NNSA, VA medical procurement). We do not cover this. Out of scope.

We ingest exactly five USAspending source slices, registered in pipeline/usaspending/sources.py:

1. DOD_PRIME_CONTRACTS — DoD-awarded prime contracts (FPDS archive ZIP, agency 097)
2. DOD_ASSISTANCE — DoD-awarded grants/cooperative agreements
3. DOD_IDV_PARENTS — DoD-awarded IDV parent records
4. DOD_SUB_AWARDS — sub-awards under DoD-funded primes (search API)
5. DOD_FUNDED_CIVILIAN_AWARDED — DoD-funded prime contracts awarded by civilian agencies

What we explicitly do not cover: classified spending (no publisher exposes it); foreign-government awards; civilian-agency contracting unrelated to DoD; military pay and civilian salary equivalents; and anything that would require sub-tier supply-chain disclosure beyond level-2 (see #cascade).

The federal fiscal year runs October 1 of the previous calendar year through September 30 of the named year. FY2024 = 2023-10-01 through 2024-09-30. We use the federal definition exclusively — never calendar year, contractor fiscal year, or congressional appropriations cycles.

FPDS archive ZIPs carry an authoritative fiscal_year column we pass through unchanged. USAspending search-API rows often do not — for sub-awards and civilian-channel awards we derive FY from action_date: if the month is October–December, FY = calendar year + 1; otherwise FY = calendar year. This matches OMB / Treasury / GAO / CBO conventions.

Action date in the future. Cancellations and corrections sometimes carry a future action_date. We do not filter them — they appear in the FY of the published action date. FPDS publishes them; we surface them.

Lag.DoD has a 90-day FPDS publication lag. The most recent fiscal quarter's numbers continue to firm up for ~90 days post-action. Every contract metric carries DOD_LAG_CAVEAT. The monthly snapshot cadence (Spec 002.5 FR-1) preserves the trajectory so a journalist can see how a quarter firmed up.

“Overhead” has no single legal or accounting definition in federal contracting. DCAA / FAR 31.203 means indirect costs allocated to a cost objective. The OMB Object Class taxonomy means certain OC codes capture overhead-like spending. Journalists usually mean “money spent on bureaucracy and consultants instead of warfighting.” A defensible product offers multiple definitions, lets the user pick, and explains the difference.

We compute three tiers, all PSC-only as of v0.3 (the OC clause was dropped — see #data-act-clause). The definitions live in dbt/models/silver/contracts.sql:

c.product_or_service_code = 'R408' AS is_overhead_conservative,
c.product_or_service_code IN ('R408','R499','R425','D302','D399') AS is_overhead_mainstream,
starts_with(coalesce(c.product_or_service_code, ''), 'R')
    OR starts_with(coalesce(c.product_or_service_code, ''), 'D') AS is_overhead_aggressive

Conglomerates register multiple UEIs. Lockheed Martin Corporation has at least 10 active UEIs (LM Aeronautics, LM Space, Sikorsky, etc.). A naive GROUP BY recipient_ueiquery of “top vendors FY24” will scatter Lockheed across 10 rows. This is the #1 thing every incumbent dashboard gets wrong.

We collapse subsidiary UEIs into their parent UEI via silver.entity_lineage, built from the USAspending recipient API:

COALESCE(el.parent_uei, c.recipient_uei) AS rollup_uei,
COALESCE(el.parent_name, upper(trim(c.recipient_name))) AS rollup_name,

silver.sub_awards mirrors the pattern with subawardee_rollup_uei / subawardee_rollup_name. The _rollup metric variants GROUP BY rollup_uei; non-rollup variants are preserved for backwards compatibility.

Coverage caveat. Backfill is partial — approximately 17% of UEIs have a resolved parent. The COALESCE means unresolved UEIs fall back to their raw UEI (graceful degradation), not NULL. Backfill priority is row-volume-DESC, so Lockheed, Boeing, Raytheon/RTX, Northrop, Booz Allen, and General Dynamics resolve first. Every _rollup metric carries UEI_ROLLUP_PARTIAL_CAVEAT.

Why it matters: in FY24, the raw-UEI top-vendors view scatters Lockheed across roughly 10 rows totaling ~$50B; the rollup view collapses these into a single ~$50B row, surfacing the actual concentration ranking that matters for HHI and antitrust analysis.

A non-trivial fraction of DoD obligations flow through awards made by civilianagencies. DoE national labs (Oak Ridge, LLNL, Los Alamos, Sandia) execute substantial DoD-funded research. GSA awards on behalf of DoD via Multiple Award Schedules. Interior's GovWorks operates as an interagency awarding shop. NASA executes joint programs.

These awards are funded by DoD but not awarded by DoD. They never appear in the DoD FPDS archive ZIP (filtered to awarding_toptier_agency_code = 097). An incumbent dashboard that shows only the DoD archive misses them. We estimate ~$13B/year of DoD obligations flow through these civilian channels in recent fiscal years.

We ingest this slice via the search API with filters.agencies = [{type: funding, name: DoD}] and the awarding-agency filter intentionally not constrained. The result lands in silver.contracts_civilian_awarded with a schema that mirrors silver.contracts exactly so the two UNION cleanly:

WITH combined AS (
    SELECT fiscal_year, federal_action_obligation, 'dod_awarded' AS channel
    FROM main.contracts
    UNION ALL
    SELECT fiscal_year, federal_action_obligation, 'civilian_awarded' AS channel
    FROM main.contracts_civilian_awarded
)

Why this matters editorially:services-coded overhead concentration in the civilian-awarded channel runs 30–50% of obligations, vs ~10–15% in the DoD-awarded channel. Civilian-agency vehicles (especially GSA Schedules) are where consulting flows. A DoD-only view of “overhead” undercounts consulting spend by a multiple.

Sub-awards are the FFATA File F layer: amounts that prime contractors disburse to lower-tier vendors under the prime award. We ingest via the search API with sub_award_types = [procurement, grant] and agencies.funding = DoD. Output: silver.sub_awards.

PSC codes arrive from the search API as a JSON-blob string like '{"code":"R408","description":"…"}' rather than the bare PSC code FPDS uses. We decode in the silver model (commit 293d48a):

COALESCE(
    json_extract_string(s.product_or_service_code, '$.code'),
    nullif(s.product_or_service_code, '')
) AS psc_code_decoded

After decoding, the same is_overhead_conservative / mainstream / aggressive flags from the prime-contract layer apply, so sub-awards roll up alongside primes in any cross-grain analysis.

Filters. We drop rows where subaward_amount > $1B as known data-entry errors. Empirical probes found rows of $39B+ that are obviously misformatted. The threshold is generous; legitimate single sub-award actions of that size are vanishingly rare.

The cascade — /api/v1/cascade/{uei} — is the iceberg view, parent-collapsed. For a single vendor (rolled up to its parent UEI), it returns:

1. dod_direct_prime— DoD-awarded prime contracts where any of the parent's UEIs is the recipient.
2. civilian_channel_awards— DoD-funded contracts awarded by civilian agencies where any of the parent's UEIs is the recipient.
3. sub_awards_received— sub-awards where any of the parent's UEIs is the subawardee (money flowing in).
4. sub_awards_paid_out— sub-awards where any of the parent's UEIs is the prime (money flowing out; includes the top 5 subawardees).

total_dod_funded_exposure_usd = (1) + (2). Sub-award flows (3) and (4) are not addedto the total because they are already inside the prime aggregates — adding them double-counts. Surfacing them separately is the point: it shows where the prime's money lands.

The deep-cascade endpoint (/api/v1/cascade/{uei}/deep) drills one more level: for each top-N level-1 subawardee, return that level-1 vendor's total outgoing-sub flow plus their top-N level-2 subs.

Critical caveat:level-2 outgoing flows are NOT scoped to the original prime's funding. FFATA/FSRS does not propagate prime provenance through hops, so once you go from prime → sub, you cannot ask “of this sub's outgoing flow, what fraction traces back to the original prime?” The level-1 sub's TOTAL outgoing is what we surface. The cascade response makes this explicit.

We cap depth at 2 in v0.1 to match data quality. Adding level-3+ would compound the provenance-loss problem and produce numbers that look authoritative but aren't. When a publisher shipping level-3 disclosures emerges, we'll add it.

The Digital Accountability and Transparency Act of 2014 (Pub. L. 113-101) requires every federal award to be linked to the financial accounts (Treasury Account Symbol, Object Class) that funded it. The linkage is published on USAspending in the object_classes_funding_this_award field, which carries entries like "25.1: Advisory services; 31.0: Equipment".

DoD's compliance has regressed dramatically:

dod_oc_linkage_compliance_pct (and the per-sub-agency variant dod_oc_linkage_compliance_by_sub_agency) surface this trajectory directly. The metric is itself a finding, not a footnote. It is the single most legible signal of DATA Act non-compliance currently visible.

This regression is also why v0.3 overhead is PSC-only. The v0.2 mainstream definition included an OC in ('25.1','25.2')clause as a logical OR with the PSC clause. As OC compliance dropped through FY20–FY24, the OC clause's contribution became increasingly noisy: rows that should have included the OC component had NULL object_classes_funding_this_award, so they fell out of “overhead.” We dropped the OC clause in v0.3 (Spec 002 FR-7) so the metric trajectory reflects actual contracting patterns rather than a publisher data-quality regression.

Every contract topline metric is dbt-tested against a published comparable within ±0.5%. The test name is reconcile_per_fy_topline. Failure blocks the dbt build; a metric whose number cannot be reconciled to within 0.5% of the publisher's own topline does not ship.

The comparable values live in dbt/seeds/gao_topline_dod_contracts.csv:

fiscal_year,gao_topline_usd,source_url,source_note
2024,445100000000,https://www.gao.gov/blog/snapshot-government-wide-contracting-fy-2024-interactive-dashboard,GAO FY2024 Snapshot...
2025,491600000000,https://www.usaspending.gov/agency/department-of-defense,USAspending agency profile FY2025...

The seed is the source of truth. When GAO publishes a new Snapshot or updates an FY estimate, we update the seed and the dbt test re-runs. The Source model on every metric response includes a typed tolerance_test entry pointing back here so a journalist can see which test protects the figure.

The 0.5% tolerance is calibrated to the publisher's own re-statement noise. The current FY24 reconciliation runs at ~0.19% (we report $445.95B against GAO's $445.1B). Anything > 0.5% blocks the build.

The API populates ReconciliationStatus inline on every metric response narrowed to a single FY with a known comparable. The journalist sees our_value, comparable_value, delta_pct, tolerance_pct, tolerance_test, and the publisher URL — all on the response, no extra clicks.

Real ones, named:

Every API response carries a typed Source[] array. Each Source has a role that tells the journalist whywe cited it. The roles are typed, finite, and load-bearing: an editor can ask “does this metric have a tolerance_testsource?” and the answer is always yes/no, never “sort of.”

DATA Act §3 requires DoD obligations to link to an object-class code. Coverage was ~85% in FY2019 and is ~28% in FY2025 — a 57-point regression in six years. The dod_oc_linkage_compliance_pct metric tracks the trajectory; the per-sub-agency variant dod_oc_linkage_compliance_by_sub_agency shows where the regression is concentrated.

Full chart support lands in a later iteration. Until then, the metric endpoint is queryable directly:

This is v1.0 of the methodology. Changes to active definitions ship as new versions (v1.1, v2.0) — never silent rewrites. Anchored URL fragments (#scope, #overhead-v03, etc.) are stable; renaming an anchor is a breaking change for every downstream consumer that linked to it.

The dbt semantic layer is the source of truth for SQL; this document is the source of truth for definitional intent. When the two diverge, this page is wrong and gets updated; the SQL is what runs.