You awarded the subcontract three weeks ago. The specialist firm was convincing in the technical exchange, their people sounded like they had done this before, and the customer is expecting something at the next program review. The question you have now is not whether they are smart. It is whether they are actually working, in the environment, on the real problem, or whether they are doing what a surprising number of teams do in the first month: reading documents, waiting on access, and producing status slides that describe intentions. This is written for the program manager who wants to know the difference before month three makes it obvious.
The first thirty days on an AI subcontract are unusually diagnostic. Almost everything that goes wrong later is visible in that window if you know what to look at, and almost none of it requires reading code to see. What follows is what a good first month produces, the signals that the sub is real, the signals that warrant escalation, and a checklist a program manager can run without a technical background.
What day thirty should look like
Five things exist. Not five things are planned; five things exist and can be shown.
An environment stood up in the destination. Not a developer presenter machine, not a personal cloud account. Compute and storage inside the environment the system will eventually live in, or inside an environment created by the same infrastructure code so the move is mechanical. Repository, pipeline, and access controls in place. If the system will need an authorization to operate, the security posture conversation has started and the control ownership is at least sketched. The reason this matters more than it sounds: a proof of concept built somewhere it cannot be deployed is a proof of concept that gets rebuilt, and the rebuild lands exactly when the schedule has no room.
Data access negotiated, with something real in hand. The full production feed rarely arrives in thirty days on a federal program; that is normal and not a failure. What should exist is a data sharing agreement in motion with named owners and dates, a representative sample or a synthetic stand-in built from the documented schema, and, importantly, a written record of what the team learned by looking at the data they do have. Access delays are the single most common schedule driver on this kind of work, and a sub that is escalating them in writing in week two is behaving correctly.
A baseline measured. This is the signal that separates teams. Before any model exists, somebody should have measured how well the current process performs, whether that is a rule set, an existing tool, or people doing the task by hand. It gives the program a comparison for everything that follows and it answers the only question the customer actually has, which is whether this is better than what we do now.
A first working increment. Small and real. An ingestion path that runs on a schedule and validates what it pulls, or a simple model measured end to end on held-out data, or a working interface with one function connected. Deployed in the environment, not shown from a notebook. It does not need to be good; it needs to prove the whole chain runs.
A plan the customer has seen. The technical approach written down, the milestones with what completion means for each, the risks named with owners and dates, and the government's technical lead has read it and pushed back. A plan the customer has not seen is a plan that will be renegotiated later at a worse moment.
Day-thirty signals ranked by how well each predicts the rest of the subcontract
Editorial weighting, illustrative rather than measured. The last row is deliberately low: reporting quality is uncorrelated with delivery quality in the first month.
The signals that the sub is real
These are observable without reading code, and they mostly concern behavior rather than output.
They asked uncomfortable questions in week one. A team that knows this work arrives with questions that are slightly rude: what exactly does this label mean, who decided it, how often is it wrong. Where does this field come from and what happens when the upstream system is down. What does the operator do with the output today and what would they do differently. Who has authority to say the requirement changed. A team that accepts the statement of work without friction has either done this many times with an identical problem or is not engaging with it yet, and the second is more common.
They wrote down what they found in the data and it was inconvenient. Real data is always worse than the documentation says. A sub that reports missing fields, inconsistent codes, duplicate records and a labeling convention that changed two years ago is doing the work. A sub whose first month contains no bad news about the data has not looked at it closely.
They built the measurement before the model. An evaluation suite and a locked held-out set in the first month is the strongest single indicator of a team that has delivered before. It is unglamorous, it produces nothing to demo, and it determines whether anything later can be trusted.
They escalate blockers early and in writing. Week two, not week eight. A sub that sends a short note naming the pending access request, the person it is with and the schedule consequence is giving you something you can act on. Silence about blockers is not the absence of blockers.
Their estimates changed and they said why. Contact with real data changes estimates. A team whose plan is identical on day thirty to the version in the proposal has either learned nothing or is not telling you.
The people on the work are the people from the proposal. Check this directly in the first month, at the working level rather than through the account manager. Key personnel substitution after award is a known pattern and it is much easier to correct in week three than in month five.
The signals that warrant escalation
Each of the following is recoverable in week four and expensive in month four.
Work is happening outside the destination environment. If development is on personal machines or an unapproved cloud account, either the access problem is worse than reported or nobody planned for accreditation. Both need your attention now. Ask where the code runs and where the data sits, and ask to see it.
Nothing has been measured. Thirty days without a number of any kind means the team is building toward a subjective acceptance conversation. Ask what has been measured and on what data. The answer should be specific.
The demonstration is against data the team chose. An early demo on hand-picked examples is fine as communication and worthless as evidence. If it is presented as evidence, correct the expectation immediately, before the customer forms a view of progress that the eventual measurement will contradict.
Status is activity, not results. Reports describing meetings attended, documents reviewed and approaches considered, with no artifact behind them. Ask for the artifact each week. If the artifact does not exist, the activity did not produce anything.
Access has been pending for three weeks and nobody escalated. This is the failure mode that quietly eats a schedule. Either the sub is waiting politely, or somebody on your side is the bottleneck and does not know it. Make access status a standing line on the weekly report with a name and a date attached.
The customer's technical lead has not met the team. On federal work the government technical lead is where requirements actually get decided. A sub that has not talked to them by day thirty is building to a document rather than to a person, and the gap between those two shows up at acceptance.
| Area | What to ask for at day 30 | A healthy answer | Escalate if |
|---|---|---|---|
| Environment | Show me where the code runs and where the data sits | Destination environment or one built by the same infrastructure code | Personal machines, an unapproved account, or a vague answer |
| Data | What did you learn about the data that the documentation did not say | A written list of specific quality problems and their consequences | Nothing found, or the data has not been examined |
| Measurement | What number do we have and on what data | A baseline for the current process, measured on held-out data | No number, or a number on data the team selected |
| Increment | Run the working piece for me, end to end | Runs in the environment from a clean start, imperfect but complete | Only runs in a notebook, or only the developer can run it |
| Plan | What changed in your plan since the proposal and why | Specific changes tied to what was learned | Nothing changed, or changes were not communicated |
| People | Who is doing the work, at what allocation, this week | Named proposal people at the committed percentages | Substitutions you were not told about |
What a program manager can check without reading code
Six checks, each taking under an hour, none requiring a technical background.
Ask someone to run the increment while you watch. Not a presentation, an execution, on the shared environment, from a clean start. You will learn in ten minutes whether the thing exists.
Ask what the baseline is and how it was measured. Listen for a specific number, a specific dataset and a specific method. Vagueness here is the most reliable early warning sign available to you.
Ask the team to name the three biggest risks and who owns each. A team in contact with the work names data access, label quality and integration. A team that is not names generic risks like schedule and resources.
Read the decision record. Ask for the written log of choices made and reasons. Its existence tells you whether this workstream will be maintainable. Its content tells you whether the team is thinking.
Look at the repository activity yourself. You do not need to read the code. Commits distributed across the month, by the people named in the proposal, in your repository, is a different picture from one large drop in week four by someone you have not met.
Ask the government technical lead what they think. Directly, and separately from the formal review. They will tell you things about how the engagement is going that will not appear on any status report.
What the prime controls that most affects a specialist sub's first month
Editorial weighting, illustrative rather than measured. The last row is deliberately low: kickoff length has never unblocked an access request.
How we run the first thirty days
Precision Federal is a small business engineering firm. We build machine learning systems, data platforms, cloud infrastructure and full-stack applications and deliver them into production inside federal agencies, working as a specialist subcontractor, teaming partner, protégé or nontraditional partner on an other transaction. Here is what a prime gets from us in the first month, stated as commitments a program manager can check against the list above.
Week one: a written technical plan with milestones and what completion means for each, the questions we need answered and who we need them from, the access requests submitted with names and dates, and the environment request in motion. We also give you a short list of what we expect to find wrong, so it is on the record before it becomes a surprise.
Week two: the environment stood up in the destination or in one built by the same infrastructure code, the repository live in your configuration management, and the first data examination written up including everything inconvenient. Blockers escalated in writing to whoever can move them.
Week three: the evaluation suite running against a locked held-out set, the experiment registry recording every run, and the current process measured to give the program a baseline. This is the month's most important output even though it demonstrates nothing.
Week four: a first working increment running end to end in the environment, a written status with measured results rather than activity, and a revised plan showing what changed and why. The government's technical lead has seen and challenged the approach.
The prime keeps everything. The customer relationship is yours and stays yours. Code goes into your repositories under your configuration management from the first commit. Data stays inside the environment your security agreement permits. Our background tooling is named at award, excluded from assignment, and licensed to you and to any follow-on team, so nothing we bring can block a successor. We work as a named subcontractor with an evaluated scope where that strengthens your position with the customer, or inside your delivery organization without a public role, whichever fits.
Pricing takes one of two shapes. Firm fixed price against milestones that are the deliverables themselves, with acceptance written as tests. Or a committed team at a stated allocation for a defined period. On an earned value program, work packages close on objective results rather than percentage estimates, so your control account manager gets clean data.
The first step is one email with a one-page brief: the program, the workstream, the data and who grants access to it, the target environment, the schedule that matters and the contract instrument. We read it and return a scoped, priced statement of work with acceptance criteria written as tests. Days, not weeks, and no cost.
What the prime owes the sub in the same thirty days
Half of the failures we see in a first month are on the prime's side, and they are correctable. A specialist team can only move as fast as its access allows.
Accounts and environment access requested on day one, not after the kickoff meeting, because provisioning inside a federal environment takes longer than anyone plans. A named technical point of contact on your side who can answer questions in a day rather than a week. Introduction to the government's technical lead early, with a clear statement of who talks to whom about what. The real requirement documents including whatever informal understanding exists behind them, because the gap between the statement of work and what the customer wants is where subs get lost. And a decision path: when something needs to change, who decides, and how fast.
Programs where those five things exist run visibly differently in the first month. Programs where they do not produce a sub that looks slow and is actually blocked, and the diagnosis is often wrong for a long time.
Bottom line
By day thirty, five things should exist: an environment in the destination, data access in motion with something real examined and written up, a measured baseline for the current process, a first working increment running end to end, and a plan the government's technical lead has read and challenged. The strongest positive signals are uncomfortable questions in week one, bad news about the data, measurement built before the model, and blockers escalated in writing. The signals to act on are work happening outside the destination environment, nothing measured, demonstrations on hand-picked data, and status that reports activity instead of results. All of it is checkable in an afternoon without reading a line of code, and all of it is far cheaper to correct in week four than in month four.
Frequently asked questions
Five things that exist rather than five things that are planned. An environment stood up in the destination or in one built by the same infrastructure code. Data access in motion with named owners and dates, plus a written examination of whatever data is available. A measured baseline for the current process, so every later claim has a comparison. A first working increment running end to end in the environment. And a technical plan with milestones and completion criteria that the government's technical lead has read and pushed back on.
Ask them to run the working increment while you watch, from a clean start in the shared environment. Ask what has been measured, on what data, by what method, and listen for specifics. Ask what they found in the data that the documentation did not mention. Look at repository activity yourself and check the commits are spread across the month and made by the people named in the proposal. Then ask the government's technical lead, separately, how the engagement feels to them.
Not by itself. Full production access inside a federal environment routinely takes longer than thirty days and that is a known condition, not a failure. What matters is whether the request is in motion with named owners and dates, whether the delay was escalated in writing early, and whether the team made progress against a representative sample or a documented synthetic stand-in in the meantime. Access pending for three weeks with no escalation is the real warning sign.
Because it answers the only question the customer has, which is whether the new system is better than the current process and by how much. It also fixes the acceptance conversation early: with a measured starting point, the improvement target is a real number rather than an adjective. Teams skip it because it produces nothing to demonstrate, and programs pay for that later when nobody can say what the model is being compared against.
Five things, all on day one rather than after kickoff. Accounts and environment access requested immediately, since provisioning is usually the long pole. A named technical contact who answers within a day. An early introduction to the government's technical lead with a clear statement of who talks to whom. The real requirement documents plus the informal understanding behind them. And a defined decision path for when something needs to change. Where those exist, a first month looks completely different.