How a Continuing Resolution Works
A continuing resolution is a joint resolution of Congress that funds government operations when appropriations bills have not been enacted. Obligation limits are enforced through the Anti-Deficiency Act (31 U.S.C. §§ 1341–1342), and OMB apportions funds within those limits. CRs typically do two consequential things for defense programs.
First, they set an obligation rate. Most CRs authorize spending at the prior year's enacted rate, pro-rated by the number of days the CR covers. A program that spent $120 million in FY2025 can obligate roughly $10 million per month under a 30-day CR, regardless of its FY2026 President's Budget request. If the program planned a large contract award early in the year, that award is either deferred or restructured.
Second, they prohibit new starts. Under a CR, a program may not initiate a new program of record, begin a new phase, or award a new contract that was not anticipated and funded in the prior year's appropriations. "New start" is defined and applied by OMB and the service comptrollers, and the boundary is not always obvious, but the practical effect is clear: anything the program intended to launch as FY2026 business is held until the CR ends.
The federal government has operated under CR authority for some part of every fiscal year since FY2011. In several years, CRs have extended for half the fiscal year or longer, and a small number of programs have faced full-year CRs. Defense program managers who assume October 1 represents the beginning of a fully funded year are planning against the historical exception, not the rule.
Where AI and Software Programs Feel It Differently
Traditional defense hardware programs — a vessel, a ground vehicle, an aircraft platform — have development schedules measured in years and production rates that are relatively insensitive to a 30- or 60-day funding interruption. The production line does not stop; the workforce does not disband; the contractor absorbs the delay and adjusts the schedule. The cost is real but bounded.
AI and software programs are structurally different in three ways that interact badly with CR mechanics.
Development cadence is not bufferable the same way. Software acquisition under the DoD Software Acquisition Pathway (DoDI 5000.87, issued October 2, 2020 under the authority of Section 800 of the FY2020 NDAA, Pub. L. No. 116-92) is structured around continuous two- to four-week development cycles that build iteratively toward capability delivery. A two-month funding interruption does not simply delay delivery by two months; it disrupts active sprints, forces the contractor team into a holding pattern, fragments institutional context built up across months of work, and frequently triggers personnel turnover as commercial-market engineers find other engagements. When the CR lifts, the program does not resume from where it stopped — it reorients.
New starts include OTA phase transitions. Other Transaction Authority agreements under 10 U.S.C. § 4022 are structured as prototyping agreements and follow-on production arrangements, not as indefinite-delivery vehicles that renew automatically. A prototype OTA that completes Phase 1 and is ready to transition to a follow-on production contract or a Phase 2 prototype needs a new award. Under a CR, that award cannot be made if the new phase was not anticipated in prior-year funding. The OTA handshake — fast and flexible in normal appropriations — becomes a waiting game during a CR, and the contractor's team and test environment may not hold.
Cloud and data contracts require early-year obligation. AI programs increasingly depend on commercial cloud hosting, training compute, and data pipeline infrastructure provisioned through contracts with variable obligation requirements. Major cloud enterprise agreements — AWS, Azure, and Google Cloud arrangements that underpin the CDAO's impact layer and service-level agreements — need early-year obligation authority to maintain continuity of licensing and to expand capacity ahead of fielding milestones. A CR that caps obligation at the prior-year rate without a prior-year precedent for that specific contract type can leave program offices in an ambiguous position about whether an annual renewal or expansion is a "new start."
Three Failure Modes Under a CR
Experience across programs that have navigated CRs with AI or software-intensive work reveals three recurring failure modes.
The "pause-then-sprint" miscalculation. A program office, anticipating that the CR will lift by December, shifts all major planned activities to the back half of the fiscal year. When the CR runs longer than expected — or when full-year appropriations arrive but with conditions that require re-planning — the program compresses eight months of work into six. Sprint-based teams under compressed timelines make different quality tradeoffs than teams with realistic schedules. This is not a hypothetical pathology; it is a described outcome in multiple Government Accountability Office reviews of software-intensive defense programs. (To be explicit: identifying specific GAO report numbers for this pattern requires access to their search catalog; the characterization reflects publicly documented CR impacts across the defense acquisition portfolio.)
OTA team dissolution. For programs using OTAs, contractor teams assembled for a prototype phase are often composed partly of specialists hired specifically for that engagement. If a CR-induced pause extends past 90 days, contractors in the defense technology industrial base — particularly smaller firms and non-traditional vendors — face a choice between holding unproductive staff and releasing them. The talent goes elsewhere. The program may formally restart on time after the CR ends, but with a meaningfully different team than the one that built the Phase 1 capability.
Missed testing windows. AI systems integrated into platform programs — targeting systems, ISR processing layers, logistics optimization tools — typically have test event windows tied to platform schedules, range availability, and operational unit availability. A CR delay of 60 days does not move a test window by 60 days; it may move it by a year, to the next available range slot that aligns with all the required constraints. Programs that fall out of their testing windows often restructure delivery schedules in ways that cascade into subsequent milestones.
What Program Offices Can Do Before October 1
The CR is not fully preventable, but much of its impact on AI and software programs can be mitigated with pre-year-end actions.
Obligate what can be obligated. Before September 30, stage contract modifications, task orders, and option exercises that represent known upcoming work. Obligations made before the CR takes effect are not subject to CR rate restrictions — they are already committed. A well-structured program that anticipates its first-quarter needs and pre-stages modifications in Q4 preserves its development cadence through the CR period at minimal overhead.
Negotiate bridge provisions into OTA structures. When structuring prototype OTAs, include explicit bridge funding and continuation authority for defined transition scenarios. OMB and the service comptrollers have interpreted transition activity between phases differently across programs; the safest approach is to make the transition a formal option in the existing agreement rather than requiring a new award.
Document new-start thresholds explicitly. Work with the program's legal counsel and comptroller to establish a written agreement with the service on which upcoming actions qualify as new starts and which are continuations. This agreement has no legal effect on the CR itself, but it provides the administrative record needed to move quickly when the CR lifts — and it surfaces ambiguities early enough to address them.
Maintain contractor technical teams. For programs with non-traditional vendor teams, build CR continuation provisions into the contract as firm base work rather than unexercised options. A team that has been retained and oriented can execute from the day the CR ends. A team that has disbanded requires two to three months to reconstitute, regardless of the technical requirements of the restart.
Develop a CR playbook. Programs that enter each October with a documented, rehearsed CR management plan — pre-staged obligations, identified bridge provisions, cleared ambiguities — navigate the transition significantly more smoothly than programs that treat each CR as novel. The playbook should be owned by the program executive and reviewed with the contractor at the end of each fiscal year.
The Structural Problem Behind the Annual Pattern
The root issue is not complexity in any specific rule but a mismatch between the federal budget process — designed for hardware programs with production schedules measured in years — and software acquisition architectures that require consistent funding to maintain velocity. Congressional direction through successive NDAA cycles established and expanded the Software Acquisition Pathway — now codified at 10 U.S.C. § 3603 — precisely because traditional acquisition frameworks were poorly adapted to modern software delivery. The CR problem is one of several places where that mismatch shows up most clearly.
Until congressional appropriations processes align more closely with continuous development cadences — which would require authorities and mechanisms that do not currently exist at scale — defense AI and software programs will continue to absorb disproportionate CR damage relative to traditional programs. The mitigation approaches above reduce that damage; they do not eliminate it.
Spartan X's work supporting program execution in acquisition-constrained environments has reinforced how much of the CR impact is attributable to planning gaps rather than the restriction itself. Programs that treat budget uncertainty as a design input — and structure their contracts, OTAs, and teams accordingly — consistently outperform those that plan for continuous appropriations and react to CRs as surprises.
Sources and further reading
- Anti-Deficiency Act, 31 U.S.C. §§ 1341–1342 (restrictions on obligations and expenditures)
- Department of Defense Instruction 5000.87, "Operation of the Software Acquisition Pathway," October 2, 2020
- National Defense Authorization Act for Fiscal Year 2020, § 800, Pub. L. No. 116-92 (Software Acquisition Pathway authority)
- 10 U.S.C. § 3603 (Software Acquisition Pathway, as codified through successive NDAA cycles)
- 10 U.S.C. § 4022 (Other Transaction Authority for prototype projects)
- Office of Management and Budget, Circular No. A-11 (Preparation, Submission, and Execution of the Budget), Part 3 (budget execution under apportionment)
- Government Accountability Office, defense acquisition and continuing resolution impact reviews (available at gao.gov/products)
