A pricing team receives a subcontractor's number for the AI portion of a bid and has to decide whether it can be defended. The usual number arrives as a labor mix of senior and mid-level software engineers over a period of performance, with a total that looks reasonable against the rest of the estimate. It will not survive a price realism analysis, and more importantly it will not survive performance, because the work it prices is not the work that gets done. AI and data effort has a different shape from software effort, and an estimate that ignores the difference is wrong in a predictable direction. This is how a specialist builds a basis of estimate a pricing team can defend, with an illustrative worked example, and the questions to ask before accepting a number.
We build AI systems, data platforms and full-stack applications and deliver them into production inside federal agencies, and we write these estimates for primes. What follows is the structure we use and the reasoning behind each part of it.
Why software labor categories misprice AI work
The mismatch is structural, not a matter of rate. Four differences drive it.
Data work is the majority of the effort and is invisible in a software estimate. Acquiring data, understanding it, cleaning it, resolving entities across systems that disagree, designing the schema, building the pipelines and proving quality is the bulk of an AI program. In a software estimate this either disappears into development hours or shows up as a small integration line. When it disappears, the estimate is short by a large margin and the shortfall arrives in month three.
The work iterates and software estimates assume convergence. A software feature is specified, built, tested and done. A model or a retrieval pipeline is built, measured, found insufficient against the acceptance threshold, and revised. The number of cycles is an assumption that has to be stated. An estimate with no iteration assumption is not conservative; it is silent, and silence in an estimate reads as a number that was back-solved.
Evaluation is a first-class activity, not a testing percentage. Software testing is often estimated as a fraction of development. On AI work, building the evaluation set, deciding the metrics, running human review where the task requires judgment, and maintaining regression runs is a separate stream of work with its own labor and its own schedule. Folding it into a testing percentage understates it every time.
Compute is a real cost with a sizing assumption. Training and inference cost money, and the amount depends on choices that have not been made when the estimate is written. It belongs on its own line with the assumption stated, so that a change in approach produces a visible change in cost rather than an overrun.
What makes an AI basis of estimate defensible under price realism
Editorial weighting, illustrative rather than measured. The last row is low because a number matched to a guess is not a rationale.
The structure: five layers, each traceable
A basis of estimate is a chain of reasoning from the statement of work to a number, and every link has to be visible. Five layers.
Layer one: task decomposition. Break the scope into elements small enough that each has one deliverable and one estimating rationale. If an element takes more than about six weeks or produces more than one deliverable, split it. Every element carries an identifier that ties to the work breakdown structure and to the paragraph of the technical approach that describes it. That traceability is what lets a pricing analyst answer a government question in one minute instead of a day.
Layer two: the estimating method per element. Each element says how its hours were derived. Analogy to a comparable prior effort, with the comparison stated. Parametric, where a unit rate is applied to a count, such as hours per source system integrated. Engineering judgment by the named person who will do the work, which is legitimate when the person is identified and the assumptions are written. Mixing methods across elements is normal. Leaving the method unstated is what makes an estimate look like a guess.
Layer three: the assumptions. Written as a list, each one testable. How many source systems. Roughly what volume of records or documents. Whether data is accessible at kickoff or requires an agreement. Whether an environment exists or has to be stood up. Whether the acceptance threshold is fixed at award or set during performance. Whether labeling is needed and who does it. Every assumption is a place the estimate could move, and stating them converts a hidden risk into a negotiable term.
Layer four: the labor mix. Hours by category per element, matching the technical approach. A pipeline element is data engineering hours with a small architecture allocation, not research hours. An evaluation element is a different mix again. When a pricing analyst reads the technical approach and the labor mix together and they describe the same work, the estimate reads as built.
Layer five: non-labor. Compute with its sizing assumption, licensed tools, environment costs, and travel if any. Separate lines, each with the assumption written beside it.
An illustrative worked example
To make this concrete, consider an illustrative scope: a document retrieval and question-answering system over an agency's policy corpus, delivered into an existing cloud environment, with a measured accuracy threshold in the acceptance criteria. The numbers below are illustrative and chosen to show the shape of an estimate, not to represent any actual engagement or any actual price.
The decomposition might run:
- Discovery and data assessment. Access to the corpus, sampling, a written quality assessment and a revised assumption set. Estimating method: analogy to comparable assessments, adjusted for the number of source systems. One deliverable: the assessment memo.
- Ingestion and processing pipeline. Parametric: an hours-per-source-system rate times the count, plus a fixed base for the pipeline framework. Deliverable: a running pipeline with monitoring.
- Index and retrieval build. Engineering judgment by the named architect, with the chunking and embedding approach stated as an assumption that may change once the corpus is seen.
- Evaluation set construction. Parametric: a number of question-answer pairs at an hours-per-pair rate, with subject matter review time counted separately. Deliverable: the evaluation set and the scoring code.
- Tuning to threshold. This is the element that carries the iteration assumption. State the number of cycles assumed, what one cycle contains, and what triggers another: a measured result below the acceptance threshold on the held-out set.
- Deployment and authorization support. Analogy, adjusted for whether the environment exists. Deliverable: the system running in the target environment with documentation for the security review.
- Monitoring and handover. Fixed, small, and never omitted, because it is what makes the system survivable after the subcontract ends.
Two observations about the shape of an estimate built this way. First, the data-facing elements together are usually the largest block, and a pricing team seeing an AI estimate where modeling dominates should ask why. Second, the tuning element is the one with real variance, and stating its iteration count converts that variance into a term the prime can negotiate: fewer cycles for a lower price and a lower threshold, more cycles for a higher one.
Pricing the uncertainty rather than hiding it
The hard part of an AI estimate is that the outcome is not fully knowable at bid time. There are three honest ways to handle that and one dishonest one.
Phase the work with a decision point. Price discovery and assessment as a firm-fixed-price element that ends with a written finding, then price the build with assumptions the assessment will confirm or correct. This is the cleanest structure and government customers generally understand it.
Tie the acceptance threshold to the price. State the measured threshold the price buys and what changes if the government wants a higher one. This turns an argument about performance into a scope conversation, which is a far better conversation to have.
Carry a stated allowance for iteration. A named number of additional cycles, with the trigger written down, priced as an option or an allowance rather than buried in the base.
The dishonest way is a large undisclosed contingency inside the labor hours. It fails price realism when the analyst compares hours to the described tasks, it fails competitively because the total is high without a visible reason, and it fails at performance because nobody knows what the buffer was for.
| Estimate element | Software-shaped version | AI-shaped version | Effect on defensibility |
|---|---|---|---|
| Data work | Folded into development hours or a small integration line | Its own elements: acquisition, cleaning, entity resolution, schema, pipelines | The largest block becomes visible and checkable |
| Iteration | Assumed away; one build pass per feature | Cycles stated per element with a written trigger for another | Variance becomes a negotiable term instead of an overrun |
| Evaluation | A percentage of development for testing | Evaluation set, metric selection, human review, regression as a stream | Acceptance criteria have an owner and a cost |
| Compute | Absent or in overhead | A line with the sizing assumption written beside it | An approach change shows as a cost change, not a surprise |
| Labor mix | Senior and mid engineers across the whole period | Mix per element matching the technical approach for that element | Technical volume and price volume tell the same story |
| Uncertainty | Hidden contingency inside the hours | Phased with a decision point, or a stated iteration allowance | Survives realism analysis and survives performance |
The five assumptions that move the number most
On nearly every AI estimate, the same short list of unknowns controls most of the variance. Naming them in the assumption list is what lets a prime negotiate them rather than absorb them.
Data access timing. Whether the team can touch real data on day one or waits sixty days for an agreement and an environment. This single item moves schedule more than any technical choice, and an estimate that assumes day-one access without saying so is carrying a risk nobody agreed to.
Data condition. Whether records are consistent across sources, whether identifiers reconcile, whether documents are machine-readable or scanned. The difference between a clean corpus and a messy one is a large multiple on the cleaning and entity-resolution elements, and it cannot be known before assessment. That is exactly why the assessment belongs as its own priced element.
Where the acceptance threshold is set. A threshold fixed at award is a scope; a threshold negotiated during performance is an open-ended obligation. State which one the price assumes.
Environment readiness. Whether the target environment exists with the services the design needs, or whether standing it up is part of the work. Deployment elements sized for an existing environment and delivered into an empty one are the most common schedule failure on data programs.
Who provides subject matter judgment. Evaluation sets and labeling need people who know the domain. If the government provides them, the estimate carries coordination time. If the sub provides them, it carries labor. Silence here means the estimate assumed one and the program discovers the other.
Relative influence of each assumption on the final number
Editorial weighting, illustrative rather than measured. The last row is low because the model choice matters far less to cost than the data does.
What the prime should ask before accepting a sub's number
Ten questions. A partner who has built the estimate properly answers all ten from the document. A partner who has not will answer the first three and start reconstructing.
- Which element in this estimate has the most hours, and why is it that one?
- How many hours are data work, stated as a share of the total?
- How many iteration cycles are assumed on the elements that iterate, and what triggers another one?
- What acceptance threshold does this price buy, and what would a higher one cost?
- Which elements were estimated by analogy, and to what?
- What are the five assumptions that would move this number the most if they turn out to be wrong?
- Where is evaluation in this estimate, and who performs it?
- What is the compute sizing assumption, and what happens to the cost if the corpus is twice the assumed size?
- Does the labor mix on each element match the technical approach for that element, and can you point to both?
- What is in the estimate for handover and monitoring, and what happens after the subcontract ends?
The tenth question is the one that most often reveals whether the sub intends to leave a working system behind or a dependency.
How the estimate connects to the technical volume
The most common cause of a price realism finding is not a bad number. It is a technical volume and a price volume that describe different projects. The technical approach promises continuous monitoring and retraining; the estimate has no hours for it. The technical approach names four source systems; the estimate has a pipeline element sized for two. The technical approach names an evaluation lead in key personnel; the estimate has no labor category for that person.
The fix is mechanical. Build a two-column map, technical paragraph to estimate element, and walk it before the pink team rather than the week before submission. Every promise in the technical volume should point to hours. Every element with hours should point to a promise. Anything unmatched in either direction is either an unfunded commitment or an unexplained cost, and both are findings waiting to happen.
Doing this early has a second benefit. It usually surfaces one or two promises in the technical approach that nobody intended to price, which is a cheaper discovery at pink team than at kickoff.
How we build and hand over an estimate
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack applications and delivers them into production inside federal agencies. When we price a workshare for a prime, this is what your pricing team receives and when.
Within roughly a week of a nondisclosure agreement and the solicitation package, you get the workshare scope as named tasks mapped to your work breakdown structure and to the evaluation criteria; the basis of estimate with hours by element and by labor category, the estimating method stated per element, the assumption list, the iteration counts and their triggers, and non-labor lines with their sizing assumptions; the technical-to-price traceability map; and a short risk register for the elements with real variance.
We write it in your format, and if your pricing team needs the estimate restructured to a different work breakdown, we restructure it rather than sending a mapping note. During the bid our estimator is available to answer a pricing question within a day, and the named engineers who built the estimate are the engineers who will perform the work.
If the number has to come down, we will tell you which task to remove and what the removal costs in capability. We will not accept a silent cut on a fixed scope, because that produces a subcontract nobody can perform and a program that goes badly for the prime as well as the sub.
On price shape after award, we work as fixed-price milestones where the scope is defined enough to write acceptance criteria as tests, and as a committed team at a stated allocation where the work is discovery or sustained engineering. You keep the customer relationship, the program, the code and the data, with assignment or license terms agreed before submission.
The first step is one email with a one-page brief: the solicitation, the technical scope you want priced, and the date. We return a scoped, priced statement of work and a basis of estimate your pricing team can put straight into the volume.
Bottom line
An AI workshare priced like software labor is wrong in a predictable direction, because data work is the largest block and is invisible, iteration is assumed away, evaluation is folded into a testing percentage, and compute is missing. Build the estimate in five traceable layers: task decomposition to one deliverable each, a stated estimating method per element, a written assumption list, a labor mix that matches the technical approach element by element, and non-labor lines with their sizing assumptions. Handle uncertainty by phasing the work with a decision point or by tying the price to a stated acceptance threshold, never by hiding a contingency inside the hours. Then walk the technical-to-price map before pink team. An estimate built this way answers a government question in a minute and survives the program as well as the evaluation.
Frequently asked questions
Because the effort has a different shape. Data acquisition, cleaning, entity resolution across systems that disagree, schema design and pipeline construction are usually the largest block of work and disappear into development hours in a software-shaped estimate. Model and pipeline work iterates rather than converging in one pass, so a cycle count has to be assumed and stated. Evaluation is a separate stream with its own labor rather than a testing percentage. And compute is a real cost with a sizing assumption. An estimate that omits those four is short in a predictable direction.
Five layers, each traceable. A task decomposition where every element has one deliverable and ties to the work breakdown structure and to a paragraph of the technical approach. A stated estimating method per element: analogy with the comparison named, parametric with the unit rate shown, or engineering judgment by the named person who will do the work. A written assumption list where each item is testable. A labor mix per element that matches the technical approach for that element. And non-labor lines for compute, tooling and environments with the sizing assumptions written beside them.
Three honest structures. Phase the work so discovery and data assessment are a fixed-price element ending in a written finding, then price the build against assumptions that finding will confirm or correct. Tie the price to a stated acceptance threshold and say what a higher threshold would cost, which turns a performance argument into a scope conversation. Or carry a named allowance of additional iteration cycles with the trigger written down, priced as an option rather than buried in the base. What fails is a large undisclosed contingency inside the labor hours.
Which element carries the most hours and why. What share of the total is data work. How many iteration cycles are assumed and what triggers another. What acceptance threshold the price buys and what a higher one costs. Which elements were estimated by analogy and to what. The five assumptions that would move the number most. Where evaluation sits and who performs it. The compute sizing assumption and what a corpus twice the assumed size does to the cost. Whether the labor mix matches the technical approach element by element. And what is included for handover and monitoring.
Build a two-column map from technical paragraph to estimate element and walk it before the pink team rather than the week before submission. Every promise in the technical approach should point to hours, and every element with hours should point to a promise. Anything unmatched in either direction is an unfunded commitment or an unexplained cost, and both become findings. The exercise usually also surfaces one or two commitments in the technical volume that nobody intended to price, which is far cheaper to discover at pink team than at kickoff.