Adding an AI or data subcontractor to a pursuit is a bet with two outcomes and no middle. A good one writes a section that scores, brings people who show up, and performs the workshare after award without needing management. A bad one produces a draft that has to be rewritten, supplies résumés of people who are not available, prices by guesswork, and becomes a program risk the prime owns entirely. The capture teams that get this right do not rely on chemistry. They ask a fixed set of questions early and read the answers carefully, because the difference between the two kinds of partner shows up in the first hour if you know what to listen for. Here is the question set, what a strong answer sounds like, and which answers end the conversation.
We build AI systems, data platforms, cloud infrastructure and full-stack applications and deliver them into production inside federal agencies, and we sit on the answering side of these conversations regularly. The questions below are the ones we think a capture director should be asking, including the ones that are uncomfortable to ask.
Question one: what have you actually deployed inside a federal agency?
Not what the firm can do. What is running, who uses it, and what happened after it launched. The answer separates firms that build systems from firms that build demonstrations.
A strong answer names the kind of system, the kind of user, the environment it runs in, the path it took through security review or authorization, and what it does now. It includes something that went wrong and what changed as a result. It is specific about scale in whatever terms are non-sensitive. It distinguishes what the firm built from what the firm contributed to.
A weak answer describes capabilities and technologies. It uses the word solutions. When you push for a specific system, it becomes vaguer rather than more concrete, and the vagueness is not confidentiality; a partner who genuinely cannot name a customer can still describe the system, the constraints and the outcome in detail.
Follow up with: what did the government own at the end, and could someone else maintain it. A firm that has genuinely delivered has a clear answer, because it lived through the handover.
What predicts a subcontractor who helps you win
Editorial weighting, illustrative rather than measured. The last row is low because vendor relationships say nothing about delivery.
Question two: show me the evaluation evidence
This is the question that separates AI firms fastest, and very few capture teams ask it. Anyone can describe an approach. The firms that have shipped can show how they knew the system worked.
A strong answer describes how an evaluation set was constructed for a real system: where the questions or cases came from, who validated the correct answers, how the set was kept separate from anything used for tuning, what metrics were chosen and why those rather than others, and what the regression process looked like before each release. It says what the numbers were and what they meant in the customer's terms. It also says where the system was weak, because a firm that measured honestly knows the weak spots.
A weak answer cites public benchmark results, or describes evaluation as a phase that happens at the end. The clearest tell is when the firm cannot say who decided what correct meant. On real programs that decision is a negotiation with the customer, and a firm that has been through it remembers.
Follow up with: how would you evaluate the system in this solicitation, and what would you propose as the acceptance threshold. A strong partner will give you a method within a few minutes and will decline to give you a number before seeing the data. Both halves of that response are correct.
Question three: who exactly does the work, and will they commit?
The staffing answer has three parts and you want all three.
Named individuals, not roles. If the firm proposes to identify people after award, you have a staffing supplier rather than an engineering partner, which may be fine for some scopes and is not fine for a bid where key personnel is scored.
Written commitment. A letter per named person stating the position, the allocation percentage, the availability period after award, and that the individual has reviewed and approved the résumé being submitted. Ask for these at teaming rather than in the final week.
A substitution path. Prior written consent, equal or better qualifications, and a notice obligation if someone becomes unavailable during the pursuit. Ask whether an alternate has been identified internally for each key position. A partner who says yes and can name them has managed a long award cycle before.
The answer that ends the conversation is a bench summary in place of names, or a résumé the firm cannot confirm the person has read.
Question four: how do you handle controlled unclassified information and authorization?
Ask what is in place today, not what is planned. The practical questions are concrete.
Where would government data live during performance, and in whose environment. Who inside the firm would have access to it, and how is that access granted and removed. What happens to the data at the end of the effort. Whether the firm has worked inside a customer-provided environment rather than only its own. What the firm's position is on whether any customer data may be used to train or tune a model, and whether that position is written down anywhere.
That last one deserves emphasis because it is where AI work differs from ordinary software work and where a prime carries real exposure. A partner should have a stated, unprompted position: customer data is not used to train models outside the effort it belongs to, retention is defined, and the terms are in the subcontract. If the firm has to think about the answer, that is your finding.
On authorization, ask what the firm has actually done: contributed to a security package, produced the documentation a control assessor asked for, remediated findings, supported a continuous monitoring process. A firm that has been through an authorization knows how much calendar it consumes and will say so in the estimate. A firm that has not will underestimate it in a way that shows up in your schedule.
Question five: what is your data-rights position?
The prime's deliverable has to be clean, and the assertions have to reconcile before submission. A partner who has done federal work will have four answers ready.
- Background technology, listed. What the firm brings that predates this effort, item by item, with the rights category asserted for each. An empty list is not a good sign; every engineering firm has tooling, and the ones claiming none have not looked.
- Foreground work, assigned or licensed. Whether work produced under the subcontract is assigned to the prime or licensed, and on what terms. A firm that insists on retaining everything it builds and licensing it back narrowly is telling you what maintenance will look like in year three.
- Open source, with licenses. A component list with license identifiers, delivered before the proposal goes out. Copyleft dependencies discovered after award are expensive.
- Markings that match assertions. Whatever is asserted gets marked that way, consistently, in the delivered artifacts. Mismatched markings are the most common data-rights finding and are entirely preventable.
Follow up with: what do you expect the government to be able to do with what you build, five years from now, without you. The answer reveals the firm's actual posture faster than the clause discussion does.
Question six: can you write in our template and our voice?
Underrated and expensive to get wrong. A technically excellent partner who writes in a different register costs your proposal manager a week of rewriting during the worst week of the schedule.
Ask for a writing sample of a technical section, ideally one written to a government evaluation criterion rather than a marketing piece. Read it for three things: whether it addresses a criterion or describes a capability, whether it uses concrete detail or category words, and whether it could be dropped into your volume with light editing.
Then ask about process. Will the firm write in your template from the first draft. Will its engineers attend your color reviews. Who on their side takes review comments and turns them around, and in what time. And the question that tells you the most: who has final say on the content of a section the firm wrote. The right answer is the prime, said without hesitation. A partner who wants to negotiate that is a partner who will spend two days of a compressed schedule defending an architectural preference.
| Question | Strong answer | Answer that ends the conversation |
|---|---|---|
| What have you deployed in an agency | A named kind of system, its users, its authorization path, and what broke | Capability descriptions that get vaguer under follow-up questions |
| Show the evaluation evidence | How the evaluation set was built, who validated it, the metrics and the weak spots | Public benchmark scores, or evaluation described as a final phase |
| Who does the work | Named people, signed commitments with allocations, identified alternates | A bench summary, or resumes the people have not reviewed |
| Controlled data and authorization | What is in place today, a written position on training data, authorization work performed | Plans and intentions, and no position on customer data used for tuning |
| Data rights | Background list, foreground terms, open-source inventory, matching markings | To be negotiated after award, or an empty background list |
| Writing and process | A sample written to an evaluation criterion, and the prime decides content | Marketing prose, and a wish to control the final technical text |
Question seven: what happens after award?
Most vetting stops at the proposal. The questions that matter for the program are different from the ones that matter for the bid, and asking them during capture tells you something about the firm even if the answers are hypothetical.
How quickly can the named people start, and what does mobilization look like in the first two weeks. What is delivered in the first month that the prime can show the customer. How does the firm report progress: what artifact, at what cadence, in what form. What is the escalation path when something slips, and who calls whom.
Then the two that reveal the most. First, how does the firm handle a scope change requested informally by a government technical lead, which is the single most common source of friction on a subcontract. The correct answer is that it goes to the prime, always, and nothing changes without the prime's direction. Second, what does handover look like at the end: source, build pipeline, infrastructure as code, environment configuration, credential rotation, a runbook, and a rehearsal where the receiving team deploys while the firm watches. A partner who describes handover as a document has not done one.
Warning signs, ranked by how much trouble they predict
Editorial weighting, illustrative rather than measured. The last row is low because informed disagreement is usually a good sign.
Two questions to ask yourselves
Vetting runs both directions, and two internal questions predict the outcome as much as anything the sub says.
Can we free an engineer to answer questions within a day? A specialist without a technical counterpart stalls immediately and produces generic text. If nobody on the capture team can be made available, the addition will underperform regardless of how good the firm is.
Are we prepared to give a real, described scope? A subcontractor given named tasks that map to evaluation criteria behaves like a partner. One given a percentage and a promise to define the work later behaves accordingly, and prices accordingly. The scope you write determines the partner you get more than the firm you pick does.
How we answer these questions, and how we work
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile applications, and delivers them into production inside federal agencies. Since the questions above are the ones we would want answered, here is what a prime gets from us without having to chase it.
Within the first week of a nondisclosure agreement and a solicitation package: a written workshare scope with tasks mapped to your work breakdown structure and to the evaluation criteria; named engineers with résumés in your template, signed commitment letters with allocations and availability periods, and alternates identified internally; a data-rights schedule listing our background technology with asserted rights; a written statement of how we handle controlled data, including our position that customer data is not used to train or tune models outside the effort it belongs to; a compliance statement against your anticipated flow-downs; and a basis of estimate with data, evaluation, iteration and compute broken out separately.
During the bid we write in your template and your voice, our engineers attend your color reviews, we take comments without defending the draft, and the prime decides final content. We do not contact the government except through you. Where the pursuit benefits from it, we build a working demonstration on public data so the technical volume can show a measured result rather than describe an intention.
After award, the money is shaped as fixed-price milestones where the scope is defined enough to write acceptance criteria as tests, or a committed team at a stated allocation where the work is discovery or sustained engineering. You keep the customer relationship, the program management, the contract, the code and the data, on the assignment or license terms agreed before submission. Handover is a rehearsal, not a document: your team deploys the system while our engineers watch, before the final invoice.
The first step is one email with a one-page brief: the solicitation or requirement, the technical scope you need covered, the workshare shape you have in mind, and the date that matters. We return a scoped, priced statement of work, a workshare description you can drop into a teaming agreement, and the names of the engineers who will do the work.
Bottom line
Vetting an AI subcontractor is a fixed set of questions, and the answers are audible in the first conversation. Ask what the firm has put into production inside an agency and what happened after. Ask to see how it knew the system worked, because evaluation evidence separates builders from describers faster than anything else. Ask for named people with signed commitments and identified alternates. Ask what is in place today for controlled data, and whether there is a written position on customer data and model tuning. Ask for the background technology list, the foreground terms and the open-source inventory before the proposal goes out. Ask for a writing sample written to an evaluation criterion, and confirm the prime decides final content. Then ask what happens after award, because that is the part you will live with. And give the partner a real described scope, because the scope you write determines the partner you get.
Frequently asked questions
Ask seven questions and read the answers carefully. What has the firm put into production inside an agency, and what happened after launch. How did it know the system worked, meaning the evaluation evidence. Who specifically does the work and will they commit in writing. What is in place today for controlled unclassified information and authorization. What is the data-rights position on background technology, foreground work and open source. Can the firm write to your template and accept that the prime decides content. And what happens after award, including scope-change handling and handover.
A description of how an evaluation set was built for a real system: where the cases came from, who validated the correct answers, how the set stayed separate from anything used for tuning, which metrics were chosen and why, and what regression testing ran before each release. A firm that measured honestly can also say where the system was weak. Public benchmark scores are not evidence of delivery, and evaluation described as a final phase indicates a firm that has not shipped. Asked how they would evaluate your system, a strong partner gives a method quickly and declines to give a number before seeing the data.
Where government data would live during performance and in whose environment, who inside the firm has access and how it is granted and removed, what happens to the data at the end, and whether the firm has worked inside a customer-provided environment rather than only its own. Then the specific one: whether any customer data may be used to train or tune a model outside the effort it belongs to, and whether that position is written down. A partner should state it without being prompted. Hesitation on that question is itself the finding.
An inability to describe any system put into production, with descriptions growing vaguer under follow-up rather than more concrete. Refusal to name engineers or commit them in writing. No position on customer data used for model tuning. Wanting direct contact with the government during capture. And accepting a silent price cut on a fixed scope, which predicts a subcontract nobody can perform. Informed disagreement on a technical point in the first meeting is usually the opposite of a warning sign.
How quickly named people can start and what mobilization looks like in the first two weeks. What gets delivered in the first month that the prime can show the customer. What progress reporting looks like, in what artifact and at what cadence. What the escalation path is when something slips. How the firm handles a scope change requested informally by a government technical lead, where the only correct answer is that it goes to the prime and nothing changes without the prime's direction. And what handover includes, which should be a rehearsal where the receiving team deploys while the firm watches, not a document.