Working inside a DoD software factory as a prime-and-partner team

A software factory is not a hosting environment with better branding. It is an opinionated delivery platform with its own pipeline, its own security gates, its own release cadence and its own idea of what a team is supposed to produce every two weeks. A prime that arrives with a traditional program plan discovers this in month three, usually at a gate review. A prime that understands the platform before the first sprint gets to spend its energy on the mission problem, which is the only place a program is actually won or lost.

This is written for the program manager or chief engineer delivering into one of these environments with a partner team. The question is practical: what changes from a program you have run before, what the platform gives you for free, what it demands in return, and how to split the work between your program organization and a specialist engineering partner so the cadence is met rather than explained.

What the platform actually provides

The value proposition is inheritance. A mature factory holds an authorization for its own platform and its pipeline, which means a large share of the security controls your system would otherwise implement are satisfied by the platform and inherited by anything running on it. Hardened base images, a container registry with scanning, secrets management, identity and access, logging and audit collection, network segmentation and the monitoring that feeds the continuous authorization picture come with the platform rather than with your team.

That inheritance is the largest schedule lever available on a federal software program. The work you do not have to do is measured in months, not weeks. It also comes with a condition, which is that the platform gets to say how software is built and deployed on it. That trade is the whole design.

The second thing a factory provides is a path. Traditional authorization is an event: build the system, assemble the package, get assessed, get a decision, repeat in three years. A factory-style continuous authorization treats the pipeline itself as the control. If the code passes the gates, the deployment is authorized. The consequence for a program is that the gate definitions, not the assessor's calendar, determine your release rate.

What changes from a traditional program

Six differences matter enough to redesign the program plan around them.

The unit of delivery is a deployable increment, not a document. On a traditional program the visible artifact between milestones is a design review package. On a factory program it is running software behind a feature flag. A program plan whose first eight weeks produce only documents will read as behind schedule to everyone on the government side, regardless of what the schedule says.

Security review moves left and becomes continuous. Static analysis, dependency and container scanning, license checks, secret detection and policy evaluation run on every commit. A finding is a build failure at ten in the morning, not a report six months later. Teams that have not worked this way spend the first month fighting the gates. Teams that have spend it configuring them.

The environment is not yours. You get a namespace, a resource quota, a set of allowed base images, an approved dependency source and a policy engine that will reject a deployment manifest for reasons that were not obvious. Architectural choices that assume root, arbitrary egress, a database you install yourself, or a package pulled from the open internet at build time will not survive.

Onboarding is a real work package. Platform access, repository provisioning, pipeline configuration, image accreditation and the first successful deployment take real calendar. Put it in the schedule as a work package with an owner rather than assuming it happens during the kickoff.

Cadence is externally set. The platform, the program office and often a broader release train expect a rhythm. Two-week increments with a demonstration that shows working software is the common shape. A team that cannot demonstrate every increment is a team the program office starts asking about.

Documentation changes form. Less narrative, more artifact. The architecture description, the interface list, the control implementation record and the test evidence all want to live near the code and be regenerated rather than rewritten. A document that is stale at the moment it is signed is worse than no document, because it invites a finding.

Getting a model through the factory's path

This is where prime-and-partner teams most often need depth, because a model is not a normal application and the platform's defaults were designed for normal applications.

A model deployment has four artifacts where an application has one: the serving code, the model weights, the training or fine-tuning pipeline that produced them, and the evaluation suite that says the weights are acceptable. Each needs a place in the pipeline, and the platform will not have opinions about three of them.

Weights are large binaries with provenance requirements. They do not belong in a source repository. They belong in an artifact store with versioning, a checksum, and a record of which training run and which dataset version produced them. The deployment references a specific version, never a moving tag. When the authorizing official asks what is running in production, the answer is a version identifier that resolves to a training run, a dataset snapshot and an evaluation result.

The evaluation suite is the gate. Treat model quality exactly the way the pipeline treats unit tests. A candidate model runs against a held-out set with fixed thresholds on the measures the mission cares about, plus subgroup measures where fairness or coverage matters, plus a check against a frozen regression set of cases the system previously got wrong. Below threshold, the promotion fails. This is what converts "we evaluated the model" from a claim into a control.

Serving is an ordinary application and should look like one. A container that loads weights from the artifact store at startup, exposes health and readiness endpoints, emits structured logs with a request identifier, and reports latency and error rates like anything else. Resisting the temptation to make the model service special is what lets it inherit the platform's monitoring rather than needing its own.

Drift monitoring is a production requirement, not a research nicety. Input distribution, output distribution, and where ground truth eventually arrives, the realized accuracy. Alert on movement, and define in advance what happens on an alert: who looks, what the degraded mode is, and how the rollback to the previous model version works. Rehearse the rollback before you need it.

Pipeline conformance without losing velocity

The most common complaint from teams new to a factory is that the gates slow them down. Usually the gates are fine and the team's practices assumed a permissiveness the platform does not grant. Four adjustments recover most of the lost speed.

• Run the platform's gates locally and in a pre-commit hook. Scanners, policy checks and linting should fail on a developer's machine in seconds, not in the pipeline in twenty minutes. Almost every factory publishes the tooling to make this possible; almost every new team discovers it in month two.
• Pin dependencies and vendor them through the approved source from day one. Retrofitting a dependency policy onto a codebase built against the open internet is a week of unpleasant work at the worst possible moment. Start compliant.
• Design for the resource quota you were given. A model that needs more memory than the namespace allows is an architecture problem discovered at deployment. Ask for the quota, the node types, and any accelerator availability during onboarding, and size the design to them.
• Separate the deployment from the release. Feature flags let code reach production continuously while capability reaches users on the program's schedule. This single practice resolves most of the tension between a factory's cadence and a program office's readiness.

Dividing the work between prime and partner

The split that works on factory programs follows the same logic as any other program: the prime owns the government-facing surface, the specialist owns the engineering surface. The factory changes what falls into each.

One practice is worth insisting on: whoever writes the technical content sits in the increment planning session. Factory programs move too quickly for a translation layer between the people who decide and the people who build. The prime keeps the decision authority and the customer relationship; it does not need to keep the keyboard.

The documentation a factory expects

Programs waste a great deal of effort here, usually by producing traditional program documentation that the platform neither wants nor reads. What a factory environment generally does want:

An architecture description that matches the deployment manifests, ideally generated from them. A data flow description that says what crosses the boundary and where it rests. An interface register naming every external system, the protocol, the authentication method and the owner. A control implementation record that distinguishes what your code implements, what the platform provides and you inherit, and what a procedure covers. Test evidence produced by the pipeline rather than assembled by hand. And for a model, a document describing what it does, what data trained it, how it was evaluated, what its known limitations are, and how a human stays in the loop for consequential outputs.

All of that is technical writing about a system that exists, which is why it should be produced by the people building the system with editorial ownership by the prime. Documentation written by a separate team against a system they cannot run is the most reliable source of assessment findings on any program.

Data access is the schedule

On nearly every factory program the binding constraint is not code and not the pipeline. It is getting the team access to real data in a place where they are permitted to use it. The approval chain involves a data owner, a privacy or records function, a security officer and often a system owner who has no stake in your schedule.

Three moves shorten it. Start the request in week one, before the engineering plan needs it, and treat it as a tracked dependency with a named owner on the government side. Ask for the minimum that lets the work proceed, with a defined path to more, rather than a maximal request that invites a long review. And build against a synthetic or de-identified dataset with the same schema in the meantime, so that the day access arrives the pipeline is ready to consume it rather than starting to be written.

The third move is worth stating plainly because it is the one teams skip. A schema-faithful synthetic dataset costs a couple of weeks and buys back a couple of months of blocked calendar. It also produces something durable: a test fixture the program keeps, which lets anyone run the system end to end without touching sensitive data.

How we work inside a prime-and-partner factory team

Precision Federal builds AI, data platforms, software and cloud systems and delivers them into production inside federal agencies. On a factory program we come in as the engineering under the prime, on the prime's plan, and the shape is deliberately plain.

The first three weeks. We get onboarded to the platform and produce a green pipeline run with a trivial service deployed to the target namespace. That is the point of the exercise: it proves access, provisioning, image policy, quota and the deployment path all work, before any real code depends on them. Alongside it we write three short documents: a conformance note listing every place the existing or planned design conflicts with the platform's policy, a data access plan with the named owners and lead times, and a proposed pipeline design showing which gates enforce which controls. Those three are useful to the prime whether or not we do the build.

What we deliver after that. Working software every increment, with the demonstration content the program office sees. The evaluation suite and its thresholds. The data pipeline with schema contracts and monitoring. Model artifact versioning and the promotion path. Drift monitoring and the rehearsed rollback. Application-layer control evidence in the form the assessor wants. Runbooks and the deployment automation. The technical content of contract data requirements, which the prime shapes, owns and delivers.

What the prime keeps. The program office relationship and every conversation the prime wants to own. The code, delivered under a written assignment rather than a recital, with our pre-existing tooling named, carved out and licensed for use in the delivered system so no future maintainer is blocked. The data, which was never ours. And the ability to have somebody else maintain the system, which is what the automation and the documentation exist to make true.

How it is priced. Fixed-price milestones where the scope is written, with acceptance stated as measurements rather than adjectives. A committed team at a named allocation where the backlog is negotiated increment to increment, which is the usual shape on a factory program. We do not price a defined outcome as hours and then discover the accountability question at acceptance.

How to start. One email with a one-page brief: which platform, what the capability is, what data it needs and who owns it, the cadence expected, the authorization posture, and who can approve a scope change. We come back with a scoped, priced statement of work.

Five failure modes on factory programs

Onboarding is not in the schedule. It is a work package with a named owner and a real duration. Treating it as a kickoff formality costs four to eight weeks that were never planned for.

The team fights the platform instead of designing to it. Every exception request is a negotiation with a queue in front of it. Designing inside the policy is almost always cheaper than getting the policy changed, and it is always faster.

The model has no gate. If there is no automated evaluation with thresholds in the promotion path, model quality is an opinion. Opinions do not survive an authorization conversation, and they do not survive a bad week in production either.

Documentation is produced by people who cannot run the system. This is the most reliable source of findings on any program, and the cheapest to avoid. Put the technical content with the builders and the editorial ownership with the prime.

Data access is started when the code is ready for it. By then it is on the critical path. Start it in week one and build against a schema-faithful synthetic set until it lands.

Bottom line

A software factory trades control for inheritance, and the trade is a good one if the team designs to it from the first week. Put onboarding in the schedule as real work. Run the platform's gates locally. Design inside the resource quota and the dependency policy rather than around them. Treat model evaluation as a pipeline gate with thresholds, and version weights like the audited artifacts they are. Start data access in week one and build against synthetic data with the real schema until it arrives. Split the work so the prime owns the government-facing surface and the specialist owns the engineering surface, with the builders present at increment planning. Teams that do this spend their program on the mission problem. Teams that do not spend it on the platform.

Frequently asked questions