De-risking a technical volume with a partner who has shipped inside an agency

The risk section is where technical volumes are lost quietly. It rarely produces a written weakness by itself. What it produces is a reader who stops believing the rest of the volume, because the risks listed are the risks anyone would list and the mitigations are the mitigations anyone would write. Schedule risk, mitigated by an integrated master schedule. Technical risk, mitigated by experienced personnel. Nothing in it could only have been written by a team that has done the work, so nothing in it earns confidence, and confidence is what the section exists to produce.

This is written for the proposal manager or technical volume lead deciding what that section should contain and who should draft it. The argument is that a partner who has deployed a system inside a federal boundary writes risk in a way an evaluator recognizes on sight, and that folding their material into the prime's voice is a mechanical process worth doing deliberately.

How evaluators read a risk section

Three questions run through an experienced evaluator's mind, usually without being written down.

Do they know where this actually goes wrong? Every program type has a small set of things that consume schedule, and people who have run one know them. On a federal artificial intelligence or data delivery, the list is short and consistent: data access approvals, authorization, integration with a system of record that was not designed to be integrated with, accessibility discovered late, and the moment when the model's behavior changes because the world changed. A volume that names these has clearly been written from experience.

Is the mitigation something that costs the offeror anything? A mitigation that costs nothing is not a mitigation. Weekly monitoring, close coordination and early engagement are free and therefore weightless. Building on synthetic data during the access approval window, deploying into an environment with an inherited control baseline, and paying for an accessibility audit before the increment closes all cost money or schedule, and their presence tells the evaluator the offeror has priced the risk rather than described it.

Does the risk have an observable trigger and an owner? A risk without a trigger cannot be managed and a risk without an owner will not be. Naming both, in a sentence, is the difference between a register and a list.

The six risks that are actually specific to federal delivery

These are the ones a partner who has shipped inside an agency writes without being asked, and they are worth going through in engineering detail because the detail is the point.

Data access has a duration and it is not on anyone's schedule. Before a model team touches production data there is usually an agreement to execute, a privacy or records review to complete, and accounts to provision inside the accredited environment. Each of those has a queue. An offeror who states the sequence, attaches a planning duration, and describes the parallel work that proceeds meanwhile has answered the question every technical evaluator has about where the first weeks go. The mitigation that costs something is building the pipeline and the evaluation approach against public or synthetic data with the same schema, so the day access arrives the work is a data swap rather than a start.

Authorization is a design constraint, not a phase. A component that inherits controls from an already-authorized platform faces a different problem from one that needs its own boundary. The inherited set typically covers infrastructure logging, encryption, physical controls and much of configuration management; what remains is application-level access control, audit content, data handling and the system's own continuous monitoring. Writing which controls are inherited, which are the system's own, and what evidence will be produced for each is a plan. Saying security will be addressed in accordance with applicable requirements is not, and evaluators read the difference instantly.

The legacy system exports a file. Agency systems of record frequently do not expose an interface that a modern pipeline would like. What exists is a nightly extract, often fixed width, with codes whose meanings changed during a prior modernization, records that arrive late, and corrections that supersede rows already processed. A pipeline that assumes clean, immutable, on-time records fails in month three. The risk statement names the behavior, and the mitigation is an ingest designed for late arrival and supersession, with a reprocessing path and data quality checks that stop bad records before they reach a model.

Accessibility is discovered late or built in from the first screen. Federal systems are subject to Section 508 requirements, and a review that arrives in the last two weeks of an increment forces rework in the worst possible window. The costly mitigation, and therefore the credible one, is building to the standard from the first interface and testing continuously rather than auditing at the end.

Model governance is asked for and rarely produced well. Documentation of intended use, training data provenance, known limitations, the evaluation method and results, the monitoring plan, the retraining trigger, and the structure of the audit record for every automated decision. Agencies increasingly ask for this material and most teams produce it as an afterthought. Committing to it as a scheduled deliverable with named contents is unusual enough to be a discriminator.

Transition is a risk from day one, not at the end. The question of what happens when this contract ends, or when the government wants the work moved, is answered by artifacts that either exist or do not: assigned source, infrastructure defined as code, documentation, and a rehearsed handover. An offeror who prices a handover rehearsal into every period has removed the risk rather than described it.

What the same risk looks like written both ways

The contrast is the fastest way to see what changes when the drafter has done the work.

The right-hand column is not longer in the volume than the left. It occupies the same lines and does entirely different work.

Folding a partner's material into the prime's voice

The mechanical problem is real: a partner's draft arrives in the partner's register and reads as a foreign object in the volume. Solved deliberately, it takes a day.

Give the partner the template, the headings and the page count, not a request for input. An open request produces an essay. A section heading with a word budget and the two claims the section must support produces text a volume lead can edit.

Give the partner the volume's vocabulary list. Every proposal team has one, formally or not: what the program is called, whether the users are reviewers or adjudicators or analysts, whether the thing is a capability or a system or a service. Handing over that list before drafting eliminates most of the editing.

Take the substance and rewrite the connective tissue. The technical assertions, durations, control names and failure modes come from the partner. The topic sentences, the transitions and the references to the program's history are the prime's. Editing this way preserves what only the partner could have written and removes what makes it sound like a different document.

Put the risks into the prime's register structure. The prime's risk board has categories, scoring and a reporting format. The partner's risks should arrive already mapped to that structure, with the same probability and impact language the rest of the volume uses. A separate subcontractor risk annex is a signal to an evaluator that the team is not integrated.

Do a consistency pass across volumes. The technical volume's risks, the management volume's approach to managing them, the schedule's durations and any subcontracting plan's description of who does what should agree. Evaluators check this more often than teams expect, and a disagreement produces a clarification question that costs time and confidence.

Set the internal date two weeks before the real one. Partner material that arrives on the volume's actual deadline can only be inserted, not edited. Two weeks of margin is what turns a partner's draft into the prime's text.

The risks a partner should talk the prime out of

The other half of drafting risk honestly is removing what does not belong, and a partner who has delivered will push back on three things that regularly appear in artificial intelligence volumes.

A promised accuracy number with no measurement behind it. A figure in the technical volume becomes a commitment an evaluator can hold the program to, and a number produced on a sample that does not resemble the agency's records will not survive the base period. The stronger construction states the measurement method, the baseline, and the threshold at which the program makes a decision, so the volume commits to a process the team controls rather than to a result it does not.

A schedule that shows model work starting in week one. Any evaluator who has run one of these programs knows the first weeks belong to access and environment. A schedule showing training in the first sprint reads as unfamiliarity, and it also removes the offeror's ability to say anything interesting about the parallel work that should be happening instead.

An automation claim without a human path. Volumes sometimes promise that the system will handle a stated share of cases without review. Whether that is achievable is unknown at proposal time, and the claim invites a question about accountability for the automated decisions. The stronger position describes the confidence routing, the review queue, the audit record and the way the automated share is allowed to grow as evidence accumulates. It is a better answer at orals and a better system to build.

Pushing back on these is uncomfortable in a proposal room where someone has already shown the customer a slide. It is much less uncomfortable than the program review where the number is missed, and a partner who raises it during drafting is doing the prime a service that is easy to mistake for friction.

What to require from the partner, in writing

• A risk register of ten to fifteen items, each with a trigger and an owner. Specific to this data, this boundary and this integration. Generic entries should be struck rather than padded.
• Durations for every approval-dependent step. Planning durations with a stated basis, not optimistic guesses, and with the parallel work described.
• The control responsibility split. Which controls the partner's components inherit, which they implement, and what evidence each produces.
• The data quality gates. What is checked before a record reaches the model and what happens when a check fails.
• The model governance table of contents. What the documentation set will contain and when each part is delivered.
• The transition artifacts list. Everything that will exist at the end of each period, with the handover rehearsal scheduled.
• Draft text in the prime's template, two weeks early. At the assigned page count, in the volume's vocabulary.

How we write risk for a prime's volume

Precision Federal is a small business engineering firm that builds artificial intelligence, data platforms, software, cloud and full-stack systems and delivers them into production inside federal agencies. On a prime's pursuit we draft the technical risk material for our scope, and we draft it from what has actually gone wrong on deliveries rather than from a category list.

In the first week we return a written technical position: what we would build, where the hard parts are, and the risks with durations attached. That document is short and specific enough to argue with, and most of the risk section grows from it.

Before the volume's internal date, and two weeks ahead of the government's, we deliver the register mapped to the prime's structure with the prime's probability and impact language, the control responsibility split for our components, the data quality gate definitions, the model governance contents, and the transition artifacts list. All of it in the prime's template, at the assigned page count, in the volume's vocabulary rather than ours. Our engineers sit in the color team reviews and answer the chief engineer's questions directly, including the ones that turn into more engineering work.

The prime keeps everything that matters. The customer relationship is the prime's, exclusively. The contract is the prime's. The code, models, pipeline definitions and evaluation programs we write are assigned to the prime consistent with the data rights asserted to the government, with only our named background tooling carved out and licensed back so nothing is ever withheld. Past performance from the effort belongs to the program. A handover rehearsal is priced as a deliverable in each period, so taking the work in-house at any option year is a staffing decision.

Pricing is firm fixed-price milestones for bid-phase work, with acceptance criteria written as numbers, or a committed team at a stated allocation mapped to the contract's labor categories for performance-phase workshare.

The first step is one email with a one-page brief: the solicitation, the date that matters, the technical problem as you see it, and what you need from a partner. We return a scoped, priced statement of work.

Bottom line

An evaluator reading a risk section is deciding whether to believe the rest of the volume. The section earns that belief when the risks are specific to this data, this authorization boundary and this legacy interface, when the mitigations cost the offeror schedule or money, and when each item carries an observable trigger and a named owner. Ten such risks beat forty generic ones. A partner who has deployed inside a federal environment supplies that material naturally, and folding it into the prime's voice is a day of deliberate editing rather than a rewrite, provided the internal date sits two weeks ahead of the real one.

Frequently asked questions