Why we qualify before we quote
Most engineering work that fails does not fail in the engineering. It fails because nobody wrote down what the result was supposed to change, nobody measured what the current process does, the data turned out to belong to a third party who never agreed to release it, or the finished system arrived and no single person had the authority to say "yes, this is accepted." We have watched that pattern across two decades of production work for federal agencies, through five consulting firms, three of them federal. So we ask five questions first. They are not a screening ritual. They are the first five paragraphs of the statement of work, and once a customer has answered them the scoping is half done.
We ask them of everyone. A prime capture manager calling three weeks before a proposal is due gets the same five. So does a university researcher looking for an STTR small-business partner, a system integrator that needs an AI bench behind its badge, a county that wants a records model, and a commercial firm buying engineering capacity by the month. The questions do not change because the contract vehicle changes. What changes is who holds the answers.
Two of the five are about value, two are about mechanics, and the fifth is about honesty. When all five have answers, our team can price the work, schedule it, and name the acceptance test on the same call. When two or three are blank, that is not a rejection. It is the actual first task, and we will often do that part with the customer before anyone signs anything.
Where scoping stalls — frequency of the blocking gap at first contact
Editorial weighting from practitioner reading of how scoped work goes wrong — illustrative, not a measured statistic.
Question one: what decision does this improve?
Not "what do you want built." What decision, made by a named role, on a known cadence, would come out differently because the system exists. A claims examiner deciding whether to escalate. A depot planner deciding which airframe gets the next induction slot. A contracting officer deciding whether a package is responsive. A grid operator deciding which feeder to inspect this week. A reviewer deciding whether a document is complete enough to route.
The reason we start here is that it fixes everything downstream. The decision tells us the latency budget: a weekly planning decision tolerates an overnight batch job, a dispatch decision does not. It tells us the interface: a person who already lives inside a case-management system needs the answer inside that system, not in a separate dashboard nobody opens. It tells us the failure cost, which sets how conservative the model has to be and how much of the output needs to carry provenance back to a source document.
When the answer is "we want to see what AI can do with our data," we say so plainly. That is a research question, and research questions are legitimate. We will scope it as a bounded study with a written question and a written stopping rule, priced as a study, and we will say up front that a study is what it is. What we will not do is take a capability shopping request and dress it up as a production program, because the day of delivery arrives and there is nothing to compare the system against.
Question two: what is the baseline, and who measured it?
Every process being replaced already has performance. Someone reads the forms today. Someone triages the alerts today. That process has a throughput, an error rate, a cost per unit, and a cycle time, and almost nobody has written them down. Without those numbers there is no way to prove a system helped, which means there is no way to defend the spend at the next budget cycle and no way to justify a follow-on.
The strong answer looks like this: "Two analysts process about 340 documents a week. On a 200-document audit last quarter, 11 percent had at least one field wrong, and rework averaged 14 minutes per flagged document." That is a baseline. It gives our engineers a target, a measurement protocol, and a sample the customer already trusts because their own people produced it.
The common answer is "it takes too long." That is a symptom. We will help turn it into a number, and the cheapest way is usually a hand audit of 100 to 300 records by the people who do the work now, scored against the same rubric the future system will be scored against. This takes a few days of a subject-matter expert's time and it is the single highest-return activity in the whole engagement. It also protects the customer from us. A firm that never establishes a baseline can claim any improvement it likes at the end.
Question three: who owns the data, and can they actually grant access?
This question kills more projects than any technical problem, and it kills them late, which is the expensive way to die. The person authorizing the work is often not the person who controls the data, and the person who controls the data usually answers to a rule that has nothing to do with the project.
So we ask for three things: the legal owner, the mechanism that lets us touch it, and the calendar time that mechanism takes. On federal work the mechanism is usually a government-furnished-information clause naming the data set, delivery format, and delivery date, with government property handled under FAR 52.245-1. Rights in the data and in what we build flow from FAR 52.227-14 on the civilian side and DFARS 252.227-7013 and 252.227-7014 on the defense side, with SBIR-developed data protected under DFARS 252.227-7018 for the SBIR data-rights period defined in the SBIR/STTR Policy Directive. If the work touches controlled unclassified information, the marking and handling rules come from 32 CFR Part 2002, the control baseline from NIST SP 800-171, and on DoD contracts the safeguarding and 72-hour incident reporting obligation from DFARS 252.204-7012.
Outside DoD the mechanisms are different and just as binding. Health data moves under a data use agreement and either an authorization or a de-identification determination under 45 CFR 164.514(b). Student records move under FERPA at 34 CFR Part 99, most often through the studies exception at 99.31(a)(6), which requires a written agreement naming purpose, scope, and destruction date. Federal tax information carries IRS Publication 1075. Criminal justice data carries the FBI CJIS Security Policy, including personnel screening for anyone who touches it. Records in a Privacy Act system under 5 U.S.C. 552a can only be shared consistent with a published routine use. If the plan involves collecting new information from ten or more members of the public, the Paperwork Reduction Act at 44 U.S.C. 3501 adds months, and that discovery belongs in week one.
What we need is not a legal opinion. It is a name, a mechanism, and a date. "Our CIO's data governance lead signs the DUA, the template is standard, it has taken four to six weeks the last two times" is a complete answer and lets us plan around it. If the data cannot leave the customer's boundary at all, that is also a complete answer, and it changes the architecture rather than ending the conversation.
| The question | A weak answer | A strong answer |
|---|---|---|
| What decision does this improve? | "We want to modernize with AI." | "The intake reviewer decides daily whether a package is complete enough to route to adjudication." |
| What is the baseline? | "The current process is slow." | "340 documents a week, 11% field-error rate on a 200-record audit, 14 minutes rework per flag." |
| Who owns the data? | "We'll get you a sample." | "Program office owns it, GFI clause names the extract, DUA signed by the governance lead, four to six weeks." |
| Who accepts the deliverable? | "The team will review it." | "The COR accepts against the acceptance criteria in the SOW; the branch chief signs the memo." |
| What if the answer is no? | "We'd rather not think about that." | "A negative result with the evidence still closes an open question and stops a larger buy." |
Question four: who accepts the deliverable?
One person. A name and a title. On federal contracts the acceptance authority is the contracting officer or a designated representative, and the place and manner of acceptance is written into the contract under FAR Part 46, with the ordinary services clause at FAR 52.246-4 for fixed-price work. Under FAR 46.503 acceptance normally happens at the source unless the contract says otherwise. Those are not decorations. They determine who has the authority to say the work is done and who triggers payment.
On commercial and state work the same question is more informal and matters just as much. "The team will review it" describes a committee, and committees do not accept software. They accumulate opinions. We ask for a named acceptor and, with that person, we write the acceptance test before any code is written: this input set, run by this person, on this machine, produces this measurable outcome, compared against the baseline from question two. Everyone signs that paragraph early, when it costs nothing to argue about it.
The acceptance conversation also surfaces requirements that never appear in a technical discussion. If the interface will be used by federal employees or the public, Section 508 conformance under 29 U.S.C. 794d is part of acceptance, and retrofitting it is far more expensive than building it in. If the system will run inside a federal boundary, someone will need an authorization to operate under the risk management framework in NIST SP 800-37, and the authorizing official is a different person from the acceptor. Naming both in week one prevents a finished system from sitting in a queue for a year.
Question five: what happens if the answer is no?
This is the one people find strange, and it is the most useful of the five. Suppose we do the work honestly and the result is that the approach does not beat the baseline, or the data will not support the accuracy the decision requires. What happens then?
If the answer is "then we wasted the money," the work is scoped wrong, and we will say so before taking it. A well-scoped study is worth its price on either outcome, because a documented negative result closes an open question, stops a larger purchase from going forward on a bad assumption, and gives the customer evidence to show their own leadership. We have seen a two-month evaluation prevent a multi-year platform commitment that would have failed for reasons nobody had tested. That evaluation earned its cost several times over and produced no model at all.
Answering it also forces the stopping rule into the open. We write kill criteria into the scope: if by week four the extraction accuracy on the held-out set is below the threshold the decision requires, we stop, we write up what we learned and why, and the remaining budget goes back or moves to a different question. Customers are sometimes surprised to see a vendor propose the terms of its own early exit. It is simply the honest structure. Work that cannot be stopped is work that will be finished regardless of whether it should be.
What happens once the five answers arrive
How the five change shape on a federal bid
When a prime calls us to carry an AI or ML workshare, the five questions get answered from two directions. Questions one and two come out of the solicitation and the customer's own language: the decision is usually stated in the objectives section, and the baseline is often hiding in the background paragraph as a complaint about the current process. Questions three, four, and five belong to the teaming structure. Who furnishes the data to the team, under what clause, on what date. Who inside the prime accepts our piece before the prime delivers to the government. What the team does if our component underperforms, which is a technical risk paragraph that evaluators read closely and most teams write badly.
Our team can answer those in a single call, and we will give a prime a yes or no on workshare within one business day. Past performance flows one direction, from prime to sub, and a prime may cite a subcontractor's record under FAR 15.305(a)(2)(ii) when the sub will perform a meaningful portion of the effort, so the workshare percentage and the recency of relevant work belong in the same conversation as the five questions.
For STTR work with a university, the split is set by statute before anything technical is discussed: the small business performs at least 40 percent and the research institution at least 30 percent. That constraint plus a faculty PI's research question resolves questions one and two quickly. Question three then becomes an intellectual property conversation with the technology transfer office, and it should start the week the team forms, not the week before submission. Question four is the agency's technical point of contact, and question five is the honest risk section that separates a serious research plan from a promise.
On state, local, and commercial work
The same five apply with different paperwork. State and local agencies buying data and analytics work often fund it through a federal pass-through, which brings the uniform administrative requirements at 2 CFR Part 200 with it, including cost allowability and record retention that outlive the contract. In-state preference rules change who can prime and who subcontracts, which is a teaming question rather than a technical one. Commercial customers rarely have a formal acceptance authority, so question four does more work there than anywhere else.
Commercial and state buyers also tend to have the cleanest answer to question five, because their alternative is visible. If the model does not work, the analysts keep doing what they do now, and the cost of the study was the price of finding out. That is a rational position, and it is the position we would rather a customer hold openly than discover late.
What these questions filter out, and what they attract
They filter out work that would have gone badly for both sides. A build with no named decision produces a system nobody adopts. A build with no baseline produces an argument at the end about whether anything improved. A build with no data access produces four months of synthetic-data theater. A build with no acceptor produces a deliverable that circulates for review and never lands. A build with no off-ramp produces a finished thing that everyone privately knows did not work.
They attract the customers our engineers do their best work for: people who already know what decision they are trying to improve and want an engineering partner who will measure the result rather than describe it. Those engagements start faster, price more accurately, and finish with a number that both sides agreed to in advance.
We do not have a baseline. Does that disqualify us?
No. It is the most common gap and usually the first two weeks of work. A hand audit of 100 to 300 records by the people who do the job now, scored on the same rubric the future system will face, produces a defensible baseline and costs a few days of subject-matter-expert time. We will help design the audit and we will not claim an improvement that has nothing to measure against.
Our data cannot leave our network.
That is an architecture input, not an obstacle. Our engineers deliver headless model packages into a customer-controlled sandbox, run inside an existing accredited boundary, and work air-gapped where the data requires it. The relevant question shifts from "how do we get the data" to "what compute exists inside the boundary and who administers it."
We are three weeks from a proposal due date. Is there time for this?
Yes. On a bid the five questions take one call, because the solicitation answers two of them and the teaming structure answers the rest. Send the solicitation number and the close date and we will tell you within one business day whether we can carry the workshare and what it would cost.
Can we see a demo before answering any of this?
We would rather show a working prototype on a slice of your real problem than a canned demo of someone else's. The five questions are what let us build that slice in days instead of guessing at it for weeks. If a general capability walkthrough is what is useful first, we will do that too.
Bottom line
Five questions. What decision does this improve. What is the baseline and who measured it. Who owns the data and can they grant access. Who accepts the deliverable. What happens if the answer is no. They are short, they are answerable by anyone close to the problem, and together they are most of a statement of work. A customer who arrives with all five already answered will get a scope, a price, and a schedule from us faster than from any firm that starts with a capabilities briefing.
Frequently asked questions
Because access sets the calendar and often the architecture. A data use agreement, a government-furnished-information clause, or an in-boundary deployment each carry different lead times measured in weeks, and each rules some designs in or out. Discovering the constraint in month three wastes the first two months.
Throughput, error rate, cycle time, and cost per unit for the people doing it now. A hand audit of 100 to 300 records scored against the rubric the future system will face is enough, and it is more credible than a benchmark from a public data set because it comes from the customer's own work.
The contracting officer or a designated representative, with place and manner of acceptance specified in the contract under FAR Part 46 and, for fixed-price services, the inspection clause at FAR 52.246-4. Technical reviewers can recommend, but acceptance and the payment trigger rest with the officer or the designee named in the contract.
It should be. Written stopping rules make the study valuable on either outcome and protect the customer from paying to finish work that the evidence already ruled out. They also make the schedule honest, because a milestone with a threshold attached cannot be quietly redefined at the end.
Yes, with the answers split between the prime and the end customer. The prime typically holds acceptance of the component and the data-furnishing path, while the decision and the baseline come from the government customer. Getting all five on the table before the teaming agreement is signed prevents the most common workshare disputes.