Track contract end dates with current and potential periods kept separate.

Government contract expiration tracking needs an explicit date rule. The current period-of-performance end date and the potential end date answer different questions. Choosing one without recording which field you used can change the research list even when every other filter stays the same.

We compared both fields across 32,313 federal award summaries in a pinned public release. For the inclusive September 1–November 30, 2026 window, current end dates select 10,663 awards; potential end dates select 10,475. 308 awards appear under only one of those rules.

The download contains the full date projection, comparison script, candidate CSV and disagreement file. This is an analysis of an August 29 edition generated August 30, not a live September watchlist. The candidates are not confirmed recompetes.

Distinguish current and potential end dates

In FPDS terminology, current completion reflects the scheduled base contract period plus options already exercised. Ultimate completion includes options whether or not they have been exercised. For orders, the ultimate completion date concerns the order itself, rather than the parent vehicle. These distinctions are documented in the FPDS glossary and ultimate completion definition.

Our normalized award file exposes the two research fields separately:

| Field | Use in this comparison | Avoid inferring | | --- | --- | --- | | performance_current_end_date | Identify awards whose reported current performance period ends inside the window | That a competition will follow on that date | | performance_potential_end_date | Identify awards whose reported potential performance horizon ends inside the window | That every possible option will be exercised |

Keep both values visible. A gap can help prioritize investigation, but it does not establish which options remain available, the buyer's acquisition plan or the cause of a date change. Identical dates also do not prove that a recompete is scheduled.

API names deserve the same care. Tango documents pop_end_date_gte / pop_end_date_lte for current end dates and expiring_gte / expiring_lte for ultimate completion. That illustrates why an “expiring” filter should not be assumed to mean the current end date. We consulted the documented contract filters; no authenticated Tango query was run for this study.

Pin the award cohort and research window

The input is the public August 29 federal-award release, generated at 2026-08-30 13:59:47 UTC. We verified the CSV, manifest and schema hashes against the existing pinned history recipe before projecting the date fields.

The manifest defines a rolling August 27–29 last-modified cohort of prime award summaries, covering award type codes A, B, C and D. It excludes IDVs, transactions and subawards, and excludes awards whose base action date is before April 4, 2022 or cannot be established. The example applies no additional agency or NAICS filter.

That means 32,313 is the input cohort size, not all federal contracts. Awards outside this changed-record edition may also end in the research window. A production watchlist needs a suitable baseline plus updates, rather than interpreting one daily release as a complete inventory.

We chose a fixed window from September 1 through November 30, inclusive, and applied it separately to each end-date field. The script does not move the window according to the computer's current date. This makes the result reproducible and keeps its historical basis visible.

For the full dataset's schema and loading workflow, see U.S. federal contract awards in Python.

Compare the same window under both fields

The comparison produces four mutually exclusive groups:

| Current end date in window? | Potential end date in window? | Awards | | --- | --- | ---: | | Yes | Yes | 10,415 | | Yes | No | 248 | | No | Yes | 60 | | No | No | 21,590 |

Selecting by current date gives 10,415 + 248 = 10,663 rows. Selecting by potential date gives 10,415 + 60 = 10,475. Keeping either field gives 10,723 unique award summaries, with a reason attached to each selection.

The difference between the two totals is only 188, but that is not the number of changed members. There are 248 + 60 = 308 selection disagreements. Comparing only headline counts would hide that turnover.

Across the full input, 2,192 awards have different current and potential dates. Most of those differences do not change membership in this particular window. Date inequality and filter disagreement are distinct measurements.

Both date fields contain syntactically valid values in all 32,313 input rows, with no potential date earlier than the current date. That is a result for this edition, not a promise about every release or confirmation that each reported date is still correct. The helper retains missing, invalid or reversed values in a separate quality-review output when they occur.

Inspect two awards that change selection

The following values are copied from the pinned source file and retained in the downloadable disagreement CSV:

| Award PIID | Current end | Potential end | Result for September–November | | --- | --- | --- | --- | | 11316025F0056OAS | September 29, 2026 | September 29, 2030 | Current only | | 140A2324P0025 | November 8, 2025 | November 8, 2026 | Potential only |

The first is an AVESHKA, INC. award summary. Its current date places it in the window while its potential horizon lies four years later. A potential-only query would omit this current-period research candidate. The source award link is preserved for checking subsequent records.

For the second award, the reported current date is already before the window, while the potential date falls inside it. The source award link provides the next research step. Its inclusion under the potential rule does not resolve whether the earlier current date reflects an unexercised option, an outdated report or another circumstance.

These are verified differences in the archived file, not claims that we reviewed the underlying contract documents or confirmed the latest live status. Keep the source key and URL alongside the dates so an analyst can check the record before acting.

Reproduce the candidate files

Extract the download and run:

python3 -B compare_dates.py --start 2026-09-01 --end 2026-11-30 --output reproduced
python3 -B -m unittest test_compare_dates.py

The bundle contains a twelve-field projection of every input award, not just the matches. It preserves award identity, recipient, agency, NAICS, performance dates, source modification time and source URL. The helper checks the projection hash and expected row count before analysis and rejects missing or duplicate award keys.

Each date is parsed independently. The core rule is:

current_in_window = current is not None and start <= current <= end
potential_in_window = potential is not None and start <= potential <= end
candidate = current_in_window or potential_in_window

The script exports candidates, selection disagreements, date-quality cases, the measured report and a versioned selection policy. A missing current date is not silently replaced by the potential date. If the other field is valid and matches, the row can still enter the candidate list with its quality status intact.

All five outputs were reproduced from both the bundled projection and the original verified CSV. To repeat the latter check, download the source asset listed in source-receipt.json, then pass it with --source-csv. The script verifies the full-file hash before projecting it. Nine automated checks cover boundaries, field-specific selection, missing and malformed dates, reversed dates, duplicate keys and an inverted window.

Treat expiration candidates as research leads

An end-date match is a reason to investigate an award, not evidence of a future solicitation. Before treating a record as contract recompete data, check later modifications, relevant opportunity or forecast notices, scope and the acquisition route. A task-order end date should not be relabelled as the parent vehicle's expiration or ordering deadline.

The CSV therefore uses unverified_candidate as its research status. It does not attach a probability, invented solicitation date or presumed buyer intention. An analyst can add a reviewed status, evidence URL and review timestamp after checking the relevant sources.

For the wider monitoring process, see the government contract tracker guide. This article's contribution is the reproducible field comparison and the exact changes in candidate membership.

Maintain the chosen date logic over time

A maintained feed should record both source dates, their previous values and why a row entered or left the window. A moved date and the ordinary passage of time are different reasons for a watchlist change. Retain the window definition and evaluation date so those effects can be separated.

Start with an agreed historical baseline, then apply updates using stable source identifiers. Refreshing only this three-day cohort cannot maintain awards absent from subsequent changed-record files. Define the correction policy, source coverage, refresh cadence and quality-review queue alongside the business filters.

The downloadable script compares one snapshot; it does not implement that recurring monitor. Its selection policy provides a concrete starting point for specifying one.

Frequently asked questions