A protégé is a multi-year commitment of a prime's scarcest resource, which is not money but the attention of program managers and chief engineers. The ones that pay it back are chosen the way a chief engineer would choose a subcontractor for a scored technical volume: on systems they have deployed, engineers you can name, a delivery record inside agencies, clean registrations, and the internal discipline to work inside a large program without generating work for the prime. The ones that do not pay back are chosen on socioeconomic category, a capability statement and a good meeting.
This is the checklist for the second kind of selection. It is written for the person at a prime who owns the relationship: a strategic partnerships lead, a small business office director, or the capture director who has to put the protégé's name in a technical volume and sign under it. The subject here is AI and data firms specifically, because that is where the gap between marketing and engineering is currently widest and where a bad selection is most expensive.
The one question the checklist is trying to answer
Strip away the program mechanics and the selection reduces to this: with no obligation of any kind, would our capture team choose this firm for the technical scope, against commercial alternatives, and be comfortable when the evaluator reads it?
If the answer is yes, the mentor-protégé structure adds set-aside pursuit eligibility and subcontracting substance to a partner the prime wanted anyway. If the answer is no, the structure adds a reporting obligation to a relationship that will never appear in a bid. Everything below is a way of getting to a truthful answer before the agreement is signed rather than eighteen months into it.
Selection signals, weighted by how well each predicts scored workshare
Editorial weighting, illustrative rather than measured. The last row is low because it is what most selections actually run on.
One: what have they deployed, and is it still running
Start here and spend the most time here. Ask for a system, named, that is in production inside a federal environment now. Then ask the questions that only someone who did the work can answer.
Who was the government sponsor, and what problem did they have. What does the system do on a normal Tuesday, and how many people touch it. What environment does it live in, and how did it get authorized to operate there. What integration was hardest: identity, the data source, the network path, or the approval. What broke after go-live, and what changed as a result. How long did the first deployment take from kickoff, and where did the schedule actually go.
Engineers who have shipped into an agency answer these in specifics and often with mild irritation, because the memories are real. Firms that have not shipped answer with methodology, with a phased approach, and with the word "typically." The difference is audible inside five minutes and it is the single most reliable signal in the whole checklist.
Two follow-ups sharpen it. Ask what they would do differently on that system, which surfaces whether anyone reflected. And ask whether the government would take a reference call, which surfaces how the relationship ended.
A firm whose deployments are all commercial is not disqualified, but it is a different risk. Commercial software teams are frequently excellent and consistently underestimate federal environment access, authorization timelines and the way approvals gate engineering. If the record is commercial, weight the compliance and process questions below more heavily and make the first assignment one where a slow start does not damage a program.
Two: who are the engineers, and are they real people with real allocation
A small firm's capacity is its named people. Ask for the list. Not a headcount, not a resume book: the specific engineers who would work on the prime's programs, what each one did on the systems just discussed, what else they are committed to, and what allocation is available.
Then check three things. That the people described as senior actually made the technical decisions on the named systems rather than supervising them. That the firm has more than one person who understands each critical part, because a single point of knowledge inside a subcontractor becomes a program risk on the prime's side. And that the firm can articulate what happens if the start date slips two quarters, which is the normal outcome in federal procurement and the one that quietly destroys small-firm staffing plans.
A firm that gives straight answers here, including uncomfortable ones about who is booked, is a firm that will give straight answers during delivery. A firm that describes a bench in the abstract is describing hiring intent.
Three: look at the engineering surface directly
This is the step most primes skip, and it is the cheapest high-value hour in the process. Ask a senior engineer from the prime to sit with a senior engineer from the candidate and look at actual work. Not slides. Code, pipelines and infrastructure.
- How a deployment happens from a clean checkout. Can a new engineer, on a new machine, get the system running by following written steps? If the answer involves a person who knows the tricks, the firm has an undocumented system and the prime will inherit it.
- How tests run and what they cover. Whether there is a test suite, whether it runs automatically, what fails when someone breaks something, and whether anyone looks at the result.
- How infrastructure is defined. Infrastructure as code, environments that can be rebuilt, and configuration that is not typed into a console by hand. This predicts whether the system can be moved into the prime's environment at all.
- How secrets and credentials are handled. Where they live, how they rotate, and whether any of them have ever been in a repository. The answer to the last part is more informative than the answer to the first two.
- How data flows and where it stops. Which systems hold what, what is retained, what is logged, and who can reach production data. This is the question that most often reveals a firm that has only ever worked on prototypes.
- How a change gets from a request to production. Review, approval, release, and rollback. A firm with a real path here will slot into a program's configuration management with almost no friction.
Four: the AI-specific engineering questions
For an AI or machine learning firm, general software practice is necessary and not sufficient. The failure modes are different, and most of them are invisible in a demonstration. Ask these, and listen for whether the answers come from experience or from reading.
Where does the training data come from and what governs its use? Provenance, licensing, whether any government data was used and under what agreement, whether personal information is present, and what the firm does about data that cannot leave a boundary. A firm that has not thought about this hands the prime a legal problem wrapped in a model.
What happens when an upstream source changes without notice? A production pipeline reads from systems maintained by people who will not tell you when a column changes meaning. Ask what their pipeline does: fails loudly with an alert to a named person, fails silently, or keeps running and produces wrong answers. The right architecture has validation at ingest, a schema contract, and monitoring on distribution shift rather than only on uptime.
How is the model versioned and reproduced? Given a decision the system made last quarter, can they identify which model version produced it, recover the code and data that produced that model, and explain the difference from the current one. Federal governance expectations keep converging on exactly this, and a firm that treats models as files in a folder will fail an assessment.
What gates a model into production? An evaluation set held separate from training, a threshold agreed before the run, a comparison against a simple baseline, and a documented decision. If promotion happens because the new model "looked better," there is no gate.
Where does the number come from? Any accuracy figure without a named dataset, a split, a date and a baseline is decoration. Ask where the model performs worst and on which subgroup. A firm that answers candidly is a firm that measures; a firm that says performance is uniformly strong has not looked.
What does the system do when the model is wrong? Every deployed model is wrong sometimes. Ask what the user sees, whether the output carries a confidence and a path to a human, what is logged, how a bad output is reported, and how that report becomes training data. The surrounding software is where a deployment succeeds or dies, and it is where weak firms have thought least.
What is the authorization path? Which boundary the system lives in, which components are already authorized, what control inheritance looks like, and who writes the evidence. Fluency here separates firms that have delivered inside agencies from firms that have delivered near them.
Five: controlled unclassified information, today rather than planned
Ask what is in place now. Where covered data would sit, which environment it is in, who has access and how that access is granted and removed, how the environment is monitored, what the incident process is, and how quickly a reportable incident reaches the prime. Ask for the current self-assessment and the plan of action behind it, and ask when it was last updated. A firm with a real posture will hand these over without drama; a firm without one will describe a roadmap.
Then match the answer against what actually flows down on the prime's programs. Defense work carries specific safeguarding and incident-reporting obligations that reach subcontractors handling covered defense information, and assessment requirements are tightening across the base. The relevant question for the mentor is not whether the candidate is perfect today, but whether the gap is closeable with the assistance the mentor is prepared to give, on a timeline that matches the pursuits. A firm two controls short with a funded plan is a good protégé. A firm that has not started and does not understand why it matters is a liability on any program that touches covered data.
Six: the data-rights posture
This is the checklist item most often skipped and the one that causes the most expensive surprises. On defense work in particular, what the government receives in delivered software, models and data depends on what was developed at private expense, what was developed under the contract, and what was asserted and marked correctly and on time.
Ask the candidate to explain their own position in their own words. What tooling, libraries, model artifacts and frameworks they bring as background. What they consider developed under a contract. Whether they have ever produced an assertions table, and whether they can produce one for a hypothetical scope. What markings they apply and when. Whether they have ever had an assertion challenged.
A firm with a clear position is a firm that will not strand the prime at closeout with software the government cannot maintain and cannot legally hand to anyone else. A firm that has never considered the question will assert nothing, mark nothing, deliver everything, and then object when the prime asks for the source. Either outcome is decided before the first line of code, in a conversation that takes an hour.
Seven: the boring diligence that fails more relationships than engineering does
| What to check | How to check it | What a good answer looks like |
|---|---|---|
| Registration and representations | Confirm active registration and current representations directly in the government system | Active, current, and matching the entity that will sign the subcontract |
| Exclusions | Search the exclusions list for the firm and its principals | Nothing, confirmed rather than assumed |
| Accounting system | Ask what type of subcontract the system can carry and whether it has been reviewed | A clear statement of what they can and cannot support, with evidence |
| Financial stability | Two years of statements, current backlog, and cash across a payment cycle | They can carry payroll while a cost-type invoice waits |
| Insurance | Certificates at the limits the prime's flow-downs require, naming the right entity | Already in place, or a written quote and a date |
| Concentration risk | Ask what share of revenue comes from the largest customer | An honest number, with a plan if it is high |
Most of these take a subcontracts analyst under a day. Skipping them is how a prime discovers in week three of a proposal that its named partner cannot be put on the contract.
Where partnerships with technically strong firms actually break down
Editorial weighting, illustrative rather than measured. The last row is low because engineering is the thing primes screen hardest and therefore miss least.
Eight: appetite, not just capability
The last check is about intent, and it is easy to get a comfortable but useless answer. Ask directly.
Do they want to be the managing venturer on a joint venture, with the accountability that carries, or do they want subcontract workshare. Both are legitimate; only one supports a set-aside pursuit through a joint venture. What does their capacity look like if a pursuit wins at full value, and what would they do in the first thirty days. Are they willing to put engineers on the prime's programs, in the prime's environment, under the prime's process. What do they want from the relationship, said plainly. A firm that wants the mentor's pipeline and does not want to change how it works will be a poor fit no matter how good the engineering is.
And one question about the prime, asked of the candidate: what do they need from us to succeed. The answer tells you whether they have thought about the relationship as a working arrangement or as a credential.
How we answer this checklist
Precision Federal is a small business engineering firm. We build AI systems, data platforms, cloud infrastructure and full-stack web and mobile software, and we deliver them into production inside federal agencies. We work as a specialist subcontractor, teaming partner, protégé and nontraditional partner on other transaction agreements. We take a scope and answer for it rather than supplying hours.
We answer the questions above the way this article says to answer them. We will name systems, name the engineers who built them, describe what broke and what we changed, and sit with a prime's chief engineer to look at repositories, pipelines and deployments rather than slides. We will state our data-rights position in writing and produce an assertions table for a proposed scope. We will describe our security posture as it stands, with the assessment and the plan behind it, rather than as a roadmap.
What a prime gets in the first weeks is concrete. Week one: a written technical position on the scope we would own, with the risks named and the questions we need answered. Weeks two and three: a scoped, priced statement of work with acceptance criteria written as tests rather than adjectives, and, on a live pursuit, draft technical volume text a proposal manager can edit instead of rewrite. Where work has already started, the first increment lands in the prime's environment, on the prime's pipeline, in the prime's deliverable format.
What the prime keeps is everything a prime should keep. The customer relationship is the prime's and we do not go around it. Code, models, pipelines and documentation are delivered under the assignment terms of the subcontract, with our pre-existing tooling named, carved out, and licensed back so nothing is stranded. Markings and assertions are settled before the first delivery. On a proposal we are named and stand behind our resumes where that strengthens the technical volume, and invisible where the capture strategy calls for one face to the customer.
Pricing takes one of two shapes: fixed-price milestones against written acceptance criteria where the scope is definable, or a committed team at an agreed allocation for a stated period where the program needs sustained capacity. Both are quoted against a rate structure that supports the flow-downs the prime's contract carries.
The first step is one email with a one-page brief: the program or pursuit, the technical scope in question, the environment the result must live in, the security destination, the date that matters, and the contract instrument. We return a scoped, priced statement of work. If the fit is not there, we say so in the same reply.
Running the checklist without spending three months
The whole thing fits in about three weeks of calendar and a handful of people's hours, and it is worth doing in this order because each step can end the process cheaply.
First, a one-hour conversation with the candidate's senior engineer about a system they deployed. This eliminates most candidates and costs almost nothing. Second, the engineering surface review, two hours with a prime engineer looking at real work. Third, the compliance and data-rights conversation, one hour, with documents requested afterward. Fourth, the subcontracts diligence pack, running in parallel from step two. Fifth, the appetite conversation with whoever at the candidate can actually commit the firm. Sixth, a small paid pilot task if anything is still uncertain, which is the only diligence that is fully truthful.
Score it against the pursuits the relationship is supposed to win, not against an abstract standard. A firm that is exactly right for two named pursuits and mediocre for everything else is still the right protégé if those two pursuits matter.
Bottom line
The protégé that repays a mentor's investment is one the capture team would have chosen with no program obligation at all. Get to that answer honestly by asking for deployed systems rather than capabilities, named engineers rather than headcount, and a look at real code rather than a briefing. For AI work, press on data provenance, pipeline failure behavior, model versioning, what gates a promotion, where the accuracy number came from, and what the system does when the model is wrong. Check the security posture as it stands today, settle the data-rights position before anything is built, and run the ordinary registration and financial diligence that fails more relationships than engineering ever does. Then ask what the firm actually wants. Three weeks of that beats eighteen months of quarterly calls.
Frequently asked questions
Ask for a named system running in a federal production environment, then ask who sponsored it, what it does now, what was hardest to integrate, and what broke after go-live. Have a prime engineer look at the repository, the test suite, the deployment from a clean checkout, and the infrastructure as code. Press on data provenance, model versioning, what gates a model into production, and what the system does when the model is wrong. Then run ordinary registration, insurance and financial diligence.
Where the training data came from and what governs its use. What the pipeline does when an upstream source changes schema without notice. Whether a decision made last quarter can be traced to a model version and that model reproduced from code and data. What evaluation set and threshold gate a promotion, and what a simple baseline scored. Where the model performs worst and on which subgroup. And what the surrounding software does when the model is wrong.
What is in place today rather than planned. Where covered data would sit, which environment holds it, how access is granted and removed, how it is monitored, what the incident process is, and how fast a reportable incident reaches the prime. Ask for the current self-assessment and the plan of action behind it, with a date. Then compare the answer to what actually flows down on the prime's contracts and decide whether the gap is closeable on the timeline of the pursuits.
Because what the government receives in delivered software, models and data depends on what was developed at private expense, what was developed under the contract, and what was asserted and marked correctly and on time. A partner with a clear position will not strand the prime at closeout with software the government cannot maintain. A partner who has never considered it will assert nothing, deliver everything, and then object when asked for source. Settle it in an hour, before anything is built.
About three weeks of calendar. One hour with their senior engineer about a system they deployed, which eliminates most candidates. Two hours of engineering surface review with a prime engineer. One hour on security posture and data rights. Subcontracts diligence running in parallel. A conversation about appetite with whoever can commit the firm. And a small paid pilot task if anything is still uncertain, which is the only diligence that is fully truthful.