Methodology — Defense Contract Vehicles

Data as of —. Live configuration values are loaded from the config.yaml that drove the last build.

What this dashboard shows

Active defense contract vehicles — IDIQs, BPAs, GWACs, and FSS schedules — with scope, ceiling, obligations, and remaining capacity. Built to help program offices find existing vehicles to place orders on instead of starting a new procurement.

Each row on the dashboard is one parent IDV. Click its PIID to drill down to the top orders that have been placed under it.

Standalone one-off contracts (buys that aren't under a vehicle) and individual task orders aren't shown as their own rows — they're rolled up into the vehicle's summary stats. Including them separately would double-count the same ceiling money against both the vehicle and its orders.

Data sources

USASpending bulk archives — transaction-level contract records, full column set.
SAM.gov monthly entity extract — supplements contractor details (UEI, legal name, registration date, location).

Scope: toptier agency — (DoD), last — fiscal years of transactions, rebuilt monthly.

What counts as "live"

The dashboard shows only contracts and vehicles that are currently in force. Every row falls into one of two buckets:

Active — effective end is more than — days out.
Expiring Soon — effective end within the next — days.

The "effective end" is the latest of the following source fields — whichever is populated wins, and we take the max:

effective_end = max(
    —
)

Why the max? The plain period_of_performance_current_end_date misses unexercised options, and it's often absent on IDV masters — where ordering_period_end_date is the real "can you still order against this" date. Combining all three gets the most generous true end.

What we drop (and why)

Two buckets exist in the raw data but don't appear in the dashboard:

Expired (effective end before today) — you can't place new orders on a lapsed contract. Dropped: —.
Unknown (no parseable date in any of the effective-end fields) — can't tell if it's live without cross-checking SAM.gov. Dropped: —.

Both are noise for the "find me a vehicle I can order against" use case, so the default build drops them entirely.

Vehicle rollup

Each vehicle row is built from two kinds of input:

The IDV master record itself (when USASpending has one) — supplies the vehicle's own vehicle_ceiling, own vehicle_obligated, and its ordering_period_end_date (the best signal for status).
Task orders under the IDV (joined on parent_award_id_piid) — supply order_count, active_orders, total_ceiling and total_obligated summed across orders, and unique sets of contractors, NAICS codes, PoP states.

Two ceiling numbers, on purpose. vehicle_ceiling is the IDV master's own potential_total_value_of_award — the authorized cap on the vehicle. total_ceiling is the sum of what's been ordered so far at their individual ceilings. They won't match, and either can be the more useful number depending on what you're looking for.

Other caveats

ceiling_remaining = potential_total_value_of_award − total_dollars_obligated. USASpending's potential_total_value_of_award reflects the latest modification and may lag real ceiling changes.
award_description is often terse ("IT SERVICES"). For real scope, check the solicitation on SAM.gov.
Geographic coverage is place-of-performance state, not the vehicle's authorized geographic scope.
Aggregation keeps only the latest transaction's values per contract (by action_date); federal_action_obligation is summed across all mods as a fallback when total_dollars_obligated is missing.

Live config

Pulled from the config.json that was emitted by the last build.

expiring_soon_days	—
effective_end_fields	—
drop_expired	—
drop_unknown	—
fetch.agency_code	—
fetch.fiscal_years_back	—

Source

Pipeline code lives on GitHub. Full config at config.yaml.