Every program office running a legacy system is on a clock it did not set. The people who know why the code does what it does are retiring, and most of what they know was never written down or if it was, is now out of date. The rules are still there, encoded in the system itself. What is disappearing is the ability to read them.
The Software Acquisition Pathway (SWP) asks teams to value working software over comprehensive documentation. Yet, documentation is what survives to accelerate the work of future teams, and it is the first thing deferred when delivery is the measure. A program can deliver on cadence for years, and still arrive at a system that no one remaining can explain, secure, or re-compete.
The question is not whether to document. It is whether understanding a system still has to cost what it used to.
What the SWP Requires
Under DoD Instruction 5000.87, the pathway establishes the artifacts a program produces to move from one iteration to the next. Those artifacts are what let subsequent teams secure, maintain, and enhance the software after the current team is gone.
Rather than collecting the artifacts from the people who remember the system, teams can now derive them from the system itself. Karsun’s ReDuX analyzes the codebase and generates the underlying material for these documents with citations back to the specific code that governs each one. The citation is the part that matters. It means an assertion about the system can be checked against the system, by anyone.
Dynamically Generate Requirements
One of the first steps in the pathway is capturing the overarching requirements that feed a Capability Needs Statement (CNS) or User Agreement (UA) or other similar document. As ReDuX analyzes user demos and the codebase, it produces requirements and user flows, each citing the specific legacy code that governs it. The requirements are written as behavior-driven given-when-then (GWTs) statements, a form that is testable by agents and reviewable by the developers and subject matter experts who validate them. Because each statement traces to the source code that produced it, any reviewer can confirm it, not only the teams that were there when the system was built.
Architecture Documents
A Software Acquisition Strategy (SAS) requires documentation of both the legacy architecture and the target. The legacy half is where programs get stuck. The available diagrams were drawn years ago and have drifted from what is actually running, and the people who could correct them are the same people who are leaving. ReDuX Blueprinting Lenses derive the legacy picture from the application’s own code and artifacts, covering data and job flows, schemas, endpoints, and screen flows. Because that picture comes from the system rather than from memory, the strategy rests on what the system does today. It is also the precondition for a modular open systems approach (MOSA). Decomposing a system into modules with defined interfaces requires knowing where the seams actually are, and on a legacy system nobody knows that until it is derived.
Scoping, Estimating and Forecasting Work
The same blueprint also changes what a program can see when it plans. Estimating work on a legacy system usually means estimating against an incomplete picture, and the gap shows up later as cost and/or schedule overruns. Working from a dependency map derived from the application itself, teams can find duplicate functionality, sequence enhancements against what actually depends on what, pay down technical debt deliberately rather than opportunistically, and remove dead code with the evidence to prove it is dead. Committing to an annual capability delivery cadence is easier when the commitment rests on the system as it is.
The pathway asks programs to move fast. The clock asks them to move fast without losing what they know. Those pull against each other only if understanding a system still has to come from the people who built it.
Everything described here belongs to the government. The requirements, the architecture, the constraints, and the traceability are platform-neutral and readable without Karsun tooling, which means a program office can hand them to any team, on any target, including a competitor. That is the point. The documentation the pathway asks for should outlast the vendor that helped produce it, and it is worth capturing now, while the people who best understand their legacy systems are still here to ask.