Higher score = stronger public fit between an offeror's posture and the SCO software pathway.
The SCO mission in public
The Strategic Capabilities Office, established under OSD and chartered by DoD Directive 5105.86, exists to identify, analyze, and prototype disruptive applications of new systems, unconventional uses of existing systems, and emerging technologies that create operational strategic effects. SCO is a rapid-prototyping organization with a roughly three-to-five-year delivery horizon. For software-first firms, the relevant translation is that SCO is most interested in software that advances an operational concept on a near-term timeline — whether by integrating mature technology, applying an existing system in a new way, or prototyping an emerging capability — rather than software that requires further fundamental research.
Per DoDD 5105.86, SCO operates as a rapid-prototyping organization with a 3-5 year delivery horizon. Software work fits across all three mission legs — disruptive applications, unconventional uses, emerging technologies.
What "existing technology" means for software
The SCO framing of existing technology is broader than commercial-off-the-shelf. Mature open-source projects, government-developed code with appropriate licensing, and proven academic methods all qualify. The methodological emphasis is on integration and operational delivery rather than on novel research. Offerors who position their proposed work as integration-of-mature-components — with the integration itself being the engineering contribution — fit the SCO posture better than offerors positioning themselves as research performers.
The technology-readiness-level (TRL) language defined in DoD Instruction 5000.02 and the related DAU references is helpful here. SCO interest centers on TRL 6 through TRL 8 — components that have been demonstrated in a relevant environment and need integration, hardening, and operational accreditation rather than further fundamental research. TRL 1 through TRL 4 work usually fits other OSD R&E vehicles; TRL 9 work is normally the responsibility of the program of record. The SCO band is the integration band.
For software, the open-source baseline is often more mature than the closed-source baseline. Mature projects under the Apache, BSD, or MIT licenses — and government-developed code released under appropriate distribution authorities — provide the substrate that integration work assembles. Offerors who treat their published-research credibility, their open-source contributions, and their documented integration history as part of the proposal narrative fit the SCO frame; offerors who treat all of those as background and lead with novel-IP claims do not.
Operational concept fit
SCO programs typically have an explicit operational concept they are advancing. The publicly available SCO communications describe a portfolio that has expanded from its original focus on existing-system reapplication to include broader prototyping for emerging operational concepts, consistent with the DoDD 5105.86 charter language. Offerors who can articulate how their software fits a publicly stated concept — and which combatant command or service component is the operational consumer — make stronger cases than offerors who pitch a generic capability.
Naming a CCMD (combatant command) or a service component as the operational consumer is less about credential-flexing than about demonstrating that the offeror understands how a Phase III transition would actually happen. A capability pitched without a downstream operator is, from an SCO perspective, a research project that has not yet identified its customer. The published acquisition literature consistently identifies named-customer alignment as a leading indicator of successful transition.
The CONOPS framing matters as much as the technical framing. A proposal that opens with operator workflow, articulates the operational gap the software closes, and then describes the technical contribution as the means by which the gap is closed reads correctly to SCO reviewers. A proposal that opens with the technical contribution and reverse-engineers an operational use case reads as research-first.
Public SCO and adjacent references
- DoDD 5105.86 — Charter document defining SCO mission and posture.
- Software Acquisition Pathway — DoDI 5000.87 — fast-track software acquisition.
- ATO via RMF — NIST 800-37 risk management framework for accreditation.
- Platform One — DAF DevSecOps reference platform — public stack.
- STIGs — DISA Security Technical Implementation Guides — public baselines.
Pace expectations
SCO is publicly committed to faster timelines than standard programs of record. The charter and supporting documents describe a roughly three-to-five-year delivery horizon and an emphasis on prototyping over study. For SBIR-flavored work in the SCO ecosystem, this means Phase I deliverables that produce measurable operational value, Phase II scopes that scale demonstrated value, and transition pathways with named appropriations.
The cadence shows up in the deliverables. Pace-fit offerors propose monthly or quarterly working artifacts — running prototypes, on-target test results, accreditation-ready documentation — rather than annual reports. Build automation, continuous integration on government-relevant infrastructure (Platform One, dod.afwerx, or analogous DevSecOps stacks), and on-target validation become part of the engineering plan from Phase I day one. The Software Acquisition Pathway under DoDI 5000.87 and the related guidance from the DoD Chief Software Officer codify many of these expectations and are referenced directly in current SCO-adjacent solicitations.
Offerors who pace their work to research-grant rhythms, rather than acquisition rhythms, do not fit the SCO posture. The mismatch shows up early — in milestone definitions, in deliverable cadence, and in the resource plan — and is one of the most common reasons otherwise strong technical proposals do not transition.
Existing technology. Mature open-source projects, appropriately licensed government-developed code, and proven academic methods all qualify; integration is the engineering contribution.
Operational concept fit. A publicly stated concept and a named combatant command or service consumer make a stronger case than a generic capability pitch.
Pace. Phase I deliverables produce measurable operational value; Phase II scales demonstrated value; transition pathways have named appropriations.
Accreditation. ATO, fast-track, and software-acquisition-pathway approaches still apply; Phase I day one is not too early to plan for them.
| Posture signal | Research-grant fit | SCO-acquisition fit |
|---|---|---|
| TRL band | 1-4 | 6-8 |
| Primary deliverable | Findings, papers, models | Running prototypes, integrated systems, accreditation artifacts |
| Cadence | Annual report | Monthly or quarterly working artifacts |
| Customer framing | Generic future user | Named CCMD or service component |
| Accreditation posture | Phase III concern | Phase I day-one planning |
Software accreditation and authority to operate
SCO-flavored software still has to clear the relevant accreditation and authorization processes for the operational context. The published accreditation pathways — ATO under the NIST SP 800-37 RMF, fast-track ATO variants documented by the Air Force CIO and others, the Software Acquisition Pathway artifacts under DoDI 5000.87, and continuous-ATO models from Platform One — apply.
Offerors who plan for accreditation from Phase I day one, including build pipelines that produce the artifacts the accreditation reviewer needs, transition more reliably than offerors who treat accreditation as a Phase III concern. The artifacts in question — SBOMs (software bills of materials per NTIA guidance), control-mapping evidence, vulnerability-scan outputs, hardening evidence against DISA STIGs where applicable — are inexpensive to produce when the build pipeline is set up to emit them and prohibitively expensive to retrofit later.
Data-handling posture is the parallel concern. NIST SP 800-171 and 800-172 for CUI on contractor systems, CMMC framework expectations as they evolve, and DFARS 252.204-7012 obligations all apply. The published guidance is increasingly clear that data handling is part of the deliverable, not a parallel compliance overhead. SCO-fit offerors plan accordingly.
Engagement posture
Engaging the SCO ecosystem productively requires understanding the specific OSD office and the specific operational customer. The publicly available SCO points-of-contact and program descriptions on the public OSD R&E and SCO web presence are starting points; serious engagement runs through documented prior work that aligns with stated SCO interests, through industry-day participation when SCO advertises, and through partner relationships with primes already on contract.
Software-first small businesses with public-research credibility and demonstrable integration work are well-positioned for this kind of engagement. Public reading of the relevant problem class — as articles like this one are an example of — is one of the cheap and high-signal ways for a small firm to demonstrate that the principal investigator thinks carefully about the SCO problem before being asked to.
The published patterns for productive SCO engagement consistently identify three signals: TRL-band alignment, named-customer alignment, and acquisition-pace alignment. Offerors who ground their pitch in those three are positioned to convert.
Common questions on the public-record framing
What public references define the SCO mission?
DoDD 5105.86, public OSD acquisition guidance, and several public BAAs. The SCO posture is rapid prototyping with a 3-5 year delivery horizon, not extended research.
Why does the SCO posture differ from a Program of Record?
PoR cycles measure in years for major modifications. SCO targets 3-5 year delivery from problem identification. Offerors who pace work to research-grant rhythms do not fit.
How does software fit SCO's three mission legs?
Disruptive applications of new systems, unconventional uses of existing systems, and emerging-technology prototyping. Software contributes to all three — most often through integration of mature components.
What does this article not cover?
Specific SCO programs by name, specific operational customer offices in active engagement, or any Precision Federal SCO positioning.
Strategic Capabilities Office
SCO sits within OSD and is chartered by DoD Directive 5105.86. The mission emphasizes disruptive applications of new systems, unconventional uses of existing systems, and emerging-technology prototyping — typically on a 3–5 year delivery horizon. Software contributes across all three legs of the mission, most often through integration of mature components with a clearly identified operational concept and customer.
Frequently asked questions
The Strategic Capabilities Office is an OSD-level rapid-prototyping organization, chartered by DoD Directive 5105.86, that identifies, analyzes, and prototypes disruptive applications of new systems, unconventional uses of existing systems, and emerging technologies producing operational strategic effects. It typically operates on a three-to-five-year delivery horizon.
SCO is publicly committed to faster timelines and emphasizes integration of existing technology against operational concepts rather than long research programs. Programs of record run on longer planning, programming, budgeting, and execution rhythms. Offerors who pace their work to research-grant rhythms do not fit the SCO posture.
Yes, when framed as integration of mature components into an operational concept. Mature open-source, appropriately licensed government code, and proven academic methods all count as existing technology. Software-first offerors who position the integration itself as the engineering contribution fit the SCO posture better than those positioning themselves as research performers.
Phase I day one is not too early. Build pipelines that produce the artifacts an accreditation reviewer needs — RMF documentation, software-acquisition-pathway artifacts, fast-track ATO inputs — make Phase II and Phase III transitions more reliable than treating accreditation as a downstream concern.
Why this work matters to us
Precision Federal is a software-only SBIR firm. The reason articles like this one exist on this site is simple: federal program offices fund teams whose principal investigators have demonstrated, in public, that they think carefully about the problems the program is trying to solve. We write to demonstrate that posture, not to telegraph any particular technical approach. If your office is exploring the problem class above and wants a partner who reads the literature, codes the prototypes, and ships under a Phase I or Direct-to-Phase-II SOW, we are listening.