The Software Acquisition Pathway Gap Is Still People
The Software Acquisition Pathway is now preferred policy for many software components, but GAO found that few major weapons programs used it. The gap is not only policy; it is skill, staffing, and execution.
Polyrhythm was built for the gap between software policy and the people meant to execute it. The software acquisition pathway gap is not mainly a memo problem. It is a skill problem.
GAO put numbers on that gap in its weapon systems annual assessment. Of 53 software-intensive acquisition programs reviewed, GAO found that only one program reported using the Software Acquisition Pathway, and even that program had moved off it. The GAO weapon systems assessment also reported that the DoD software cadre consisted of one federal employee with limited assistance as of March 2024.
Those facts explain why adoption can lag policy. The pathway can be preferred, and programs can still lack the people needed to use it well. Program managers need to understand agile delivery, user feedback, software metrics, and incremental capability. Contracting officers need to understand OTAs, Commercial Solutions Openings, intellectual property, data rights, and technical evaluation criteria.
Engineers need the same translation skill from the other side. They have to build release plans that produce evidence for program offices, authorizing officials, testers, and users. They have to explain how each increment will be tested, what the acceptance criteria are, and how the architecture stays open for the next release.
Without that shared fluency, the pathway becomes a label. A program can call itself software-first while still writing hardware-style requirements, scheduling late integration, and treating user feedback as a milestone artifact. The shape changed in policy, but the work did not change in practice.
The people problem also shows up in staffing. A single cadre employee cannot coach dozens of major programs into modern software acquisition. Even with support, the scale mismatch is obvious. The department needs more people who can move between acquisition, software engineering, cybersecurity, test, and sustainment without losing the thread.
This is especially important for weapon systems. Software acquisition is not just a procurement mechanism. It changes how programs plan increments, manage interfaces, run tests, and accept risk. A weapon system may have software that changes weekly and hardware that changes over years. The pathway has to reconcile both.
The gap also affects vendors. A small software company may be able to deliver quickly, but still need clear government product ownership, fast feedback, and access to representative environments. If those are missing, the pathway can bring in better software talent and still leave that talent blocked outside the real system.
That is why adoption should be measured by delivered capability, not pathway selection alone. A program can choose the right pathway and still fail to build the team, environment, and evidence flow that make it work. The people system has to mature with the policy.
Mandating the shape of a software program does not produce the shape. The shape requires people who know how to hold it, on both sides of the contract. They need enough experience to resist fake agile, vague demos, and late evidence collection.
Polyrhythm fits that gap because we bring senior software and systems judgment into the execution layer. The policy direction is right. The adoption problem will not clear until programs have enough people who know how software acquisition works when it touches real mission systems.