How the US Space Force Is Changing Systems Engineering for Commercial Space
Space Force acquisition is doing something that years of commercial pressure and investor demands never quite managed: forcing a generation of space startups to do real systems engineering.
The mechanism is not a mandate. It is money. Programs like SpaceWERX, STRATFI, and TACFI are funneling Defense Department dollars into commercial space at a scale that makes formal process worth the pain. For founders who spent their early years moving fast on venture capital and iterating hardware in a warehouse, the encounter with government technical requirements is jarring. For the programs of record they are competing to feed into, the commercial sector’s engineering documentation practices have historically been a liability.
This piece covers how that tension is playing out — what the programs actually require, where startups are stumbling, and what the transition from prototype culture to defense-grade systems engineering looks like in practice.
The Acquisition Ladder and What Each Rung Demands
SpaceWERX is the Space Force’s innovation arm, modeled on AFWERX and designed to pull commercial technology into government programs faster than traditional acquisition. The ladder it manages has three main rungs:
Phase II SBIR/STTR contracts are the entry point for most startups. Dollar values are typically in the $1–2M range. Documentation requirements at this stage are real but forgiving — a Statement of Work, some technical reporting, and a loosely structured plan. Most startups can handle this with existing engineering documentation, even if it lives in Google Docs and Confluence.
STRATFI (Strategic Financing) is where the requirements escalate. STRATFI awards range from $15M to over $100M, often with a matching private investment component. At this tier, the government expects to see a requirements management baseline, evidence of traceability between system requirements and subsystem specs, and a test and verification plan that maps back to that baseline. The technical review process tightens. A Preliminary Design Review (PDR) or Critical Design Review (CDR) may be required or strongly implied. Companies that have never run a formal PDR are suddenly preparing for one under contract.
TACFI (Tactical Financing) operates similarly but is oriented toward nearer-term operational capability. The timelines are compressed and the technical scrutiny can be higher, because the government is evaluating readiness for integration into actual mission architectures. At TACFI, systems engineering documentation is not a deliverable — it is a prerequisite for surviving government technical interchange meetings.
The common thread is traceability. As you move up the ladder, the government’s ability to trust your design depends increasingly on whether you can demonstrate that requirements are allocated, verified, and linked to hardware or software artifacts. A prototype that flies impressively in a demo is not sufficient evidence at STRATFI. The question the government is asking is: can we understand this system well enough to integrate it, modify it, and sustain it?
What “Traceability” Means When the Government Asks for It
Traceability gets used loosely in startup engineering conversations. In the context of a Space Force acquisition program, it has a specific operational meaning.
A requirements baseline is traceable when every system-level requirement can be linked, bidirectionally, to:
- Its source (a customer need, an interface requirement, a standard, or a derived requirement from architecture analysis)
- Its allocation (which subsystem or component is responsible for satisfying it)
- Its verification method (test, analysis, inspection, or demonstration)
- Its verification status (planned, in work, complete, or waived)
When a government program manager or a DCSA reviewer asks for a traceability matrix, they are asking for evidence that this network of links exists and is current. A spreadsheet with requirements in rows and verification methods in columns satisfies the minimum. It does not satisfy a CDR board that wants to understand how a change to a propulsion subsystem propagates through the system-level performance budget.
The deeper issue is that traditional document-based requirements management — whether in Word, Excel, or even IBM DOORS if it is being used as a glorified database — produces traceability as a snapshot. The documents describe the system as it was when someone last updated them. Defense programs have lived with this limitation for decades because their systems change slowly and their primes have large sustaining engineering teams. Commercial space startups change their systems constantly and have no sustaining engineering team at all. The documentation debt accumulates fast.
The Inflection Point: When the Gap Becomes Visible
The moment most startups describe as the inflection point is not contract award — it is the first government technical review after contract award.
A typical pattern: a company wins a STRATFI award. The team is talented, the hardware is real, and the system concept is sound. Then the government schedules a technical interchange meeting or a PDR equivalent. The program office sends a data item description list. The startup’s chief engineer, who has been managing requirements in a combination of Notion, a few Confluence pages, and personal expertise, sits down to produce the requested documentation and realizes that the traceability does not actually exist in a form the government can review.
What follows is a documentation sprint that is expensive, demoralizing, and often only partially successful. Engineers who should be working on hardware are writing requirements documents. The documents, produced under time pressure, are not traceable to the architecture — they describe the system approximately but do not form an auditable baseline. The PDR gets deferred or passes with significant risk items.
The startups that navigate this better share a few characteristics. First, they started some form of requirements management before the STRATFI award, even informally. Second, at least one person on their engineering team has a prior life in aerospace primes or defense programs and has sat through enough PDRs to know what the reviewers are actually looking for. Third, they treat the documentation process as an opportunity to find problems in their design rather than a compliance tax to minimize.
That third point is worth expanding. Experienced systems engineers will tell you that the discipline of writing verifiable requirements — requirements with clear acceptance criteria, allocated to responsible hardware or software owners — consistently surfaces ambiguities and conflicts in the underlying design. Startups that rush through requirements documentation to satisfy a deliverable date miss this benefit entirely. They produce traceable paperwork for a design that still contains the same structural problems.
What Startups Are Actually Doing
The adaptations vary, and not all of them are healthy.
The prime subcontract route. Some commercial space startups attach themselves to a large prime as a subcontractor for their first STRATFI or TACFI award. The prime handles the systems engineering overhead and interfaces with the government’s technical review process. The startup delivers technology. This works for winning contracts but creates a ceiling: the startup never builds the internal systems engineering capability it needs to compete as a prime contractor, and the prime retains the customer relationship.
The compliance consultant route. Other startups hire a defense consulting firm or a retired government systems engineer to produce documentation on demand. This is expensive, produces documentation that engineers do not own and cannot maintain, and often fails at technical reviews because the consultants are not integrated with the design process.
The internal investment route. The startups that are building durable defense business are treating the STRATFI moment as an organizational inflection point. They are hiring systems engineers with defense backgrounds, establishing a requirements management baseline before it is required, and choosing tooling that can grow with them. This takes six to twelve months of organizational change and is hard to do while also building flight hardware. But the companies doing it are consistently better positioned at their second and third government technical reviews.
How Modern Tooling Changes the Equation
One of the structural problems with the prime subcontract and compliance consultant routes is that they rely on tooling ecosystems — typically IBM DOORS or Jama Connect — that are built for large organizations with dedicated requirements management staff. DOORS in particular requires significant expertise to set up and maintain. A startup that adopts DOORS to satisfy a government deliverable requirement often finds that the tool creates more process overhead than it eliminates, and that engineers avoid using it.
This is not a critique of DOORS as a tool for its intended use case. In a large program office with a dedicated systems engineering team managing thousands of requirements across multiple prime contractors and subcontractors, DOORS’s hierarchy and change control mechanisms are appropriate. The problem is the fit: it is a tool designed for a different organizational context.
Newer requirements management platforms built for modern engineering teams have changed the calculus for startups entering the defense market. Flow Engineering, for example, is built on a graph-based model rather than a document hierarchy, which means the bidirectional traceability that government reviewers need is native to the data model rather than retrofitted through manual cross-references. A startup can build a compliant requirements baseline in Flow Engineering without needing a DOORS administrator, and the system’s AI-assisted features help smaller teams manage the documentation workload without a dedicated RM staff.
The specific value for STRATFI-stage companies is the ability to maintain a living baseline — one that actually reflects the current design rather than the design as of the last document update — without requiring engineers to spend half their time on documentation maintenance. When a propulsion requirement changes because the thermal team revised the budget, the traceability links update, the affected verification records flag as impacted, and the program manager can see the scope of the change before it becomes a CDR surprise.
Flow Engineering’s focus on hardware and systems engineering teams means it is not trying to solve every PLM or ALM problem — companies with deep software-hardware integration needs will still need to think carefully about tool architecture. But for the core systems engineering workflow that STRATFI and TACFI programs demand, the fit is direct.
The Honest Assessment
Space Force acquisition programs are genuinely changing commercial space for the better, in the systems engineering dimension. The companies that go through STRATFI and emerge with a real requirements baseline and a team that understands formal technical reviews are stronger organizations than they were before the contract. The discipline makes the hardware better.
But the on-ramp is poorly supported. SpaceWERX does not offer meaningful systems engineering coaching as part of its transition support. The Phase II to STRATFI jump is large, and most startups make it with inadequate preparation. The government’s own interest in pulling commercial technology into programs of record would be better served by investing in engineering process support — not to mandate a specific toolchain, but to help startups understand what a compliant baseline actually looks like before they are sitting across from a CDR review board.
The commercial space companies that will own the defense market in five years are not necessarily the ones with the best hardware today. They are the ones that learned to do systems engineering early enough to make it part of how they build, rather than a paper exercise they perform for government reviewers. That distinction is becoming visible in program performance right now.