The whole path, before the details
A first engagement with our team runs on a fixed shape. You send one email describing the problem. You get a yes or a no inside one business day. If it is a yes, we trade questions for a few days and write a one-page scope. That scope usually becomes a two-to-three-week fixed-price discovery with a named deliverable and a written acceptance test. If the discovery says the thing is buildable, we build it in milestones over six to twelve weeks. Then we hand it over: your repository, your infrastructure, your runbook, your evaluation harness, and a walkthrough with your engineers until they can run it without us. Nothing in that path is a mystery, and no step obligates the next one.
We publish this because the alternative wastes everyone's time. Buyers of AI and data engineering are usually asked to commit to a large scope before anyone has looked at their data, and the projects that die in month five almost always died in week one, when nobody wrote down what "working" would mean. Our team would rather spend two weeks proving a thing is real than six months discovering it is not.
The path below is the same whether you are a prime capture manager who needs an AI/ML workshare on a bid, a university PI who needs a small-business partner, a system integrator who needs bench depth for a delivery already under contract, or a commercial company that has a data problem and no one in-house to own it. The paperwork changes. The sequence does not.
Step one: the first email
Write it yourself, in your own words, in ten minutes. We do not need a requirements document, a maturity assessment, or a redacted architecture diagram. We need to know what is going wrong, who cares that it is going wrong, and roughly when it needs to stop going wrong.
The emails that get the fastest and most useful reply tend to answer the same handful of questions. You do not need all of them. Three is enough to start.
- What the problem is, in plain language, with no vendor vocabulary.
- Who owns the outcome on your side, and who has to approve the spend.
- What data exists, where it lives, and who controls access to it.
- Where the finished thing has to run: your cloud, our cloud, on-premises, or disconnected.
- Any sensitivity flags: CUI, export-controlled technical data, PHI, PII, student records, or trade-secret material.
- The date something has to exist by, and what happens if it does not.
- If it is a federal bid: the solicitation number, the close date, and the workshare you are trying to fill.
Send it to [email protected]. If the material is sensitive, describe the shape of the problem without the sensitive content and say so; we will put a mutual NDA in place before you send anything real. We hold a JCP / DD-2345 certification for export-controlled technical data, so ITAR-adjacent material has a path that does not require a workaround.
Step two: the reply, inside one business day
You get one of three answers. A yes, with the questions we need answered to write a scope. A no, with the reason, and usually a pointer to the kind of firm that does fit. Or a "yes, but not the way you asked," which is more common than either and is the most valuable answer we give.
That third answer matters because a large share of requests arrive framed as a model problem when the binding constraint is data access, records quality, or an approval gate nobody scheduled. Hearing that on day one costs nothing. Finding it in month four costs the budget.
What we weigh when we scope a first engagement
Editorial weighting of the factors that most often decide whether a first engagement succeeds. Illustrative, not a measured statistic.
Step three: the scoping exchange
This takes two to five business days and costs nothing. It is normally an email thread. If you would rather talk, one 45-minute call covers it, and our engineers come to that call having already read whatever you sent.
What we are trying to establish is narrow: what the smallest useful version of the thing is, what data has to be in hand to build it, what environment it runs in, and what test would convince a skeptical person that it works. We push hard on the last one. "Better triage" is not a test. "Ninety percent of the alerts an examiner currently opens by hand are ranked in the top decile by the model, measured on a held-out month the model never saw" is a test.
The exchange ends with a one-page scope from us: the deliverable, the acceptance criteria, the data and access we need, the price, the duration, and the assumptions. One page, not thirty. If it is wrong, you say so and we fix it before anyone signs.
Step four: the fixed-scope discovery
Almost every first engagement starts here: a two-to-three-week, firm-fixed-price discovery with a named deliverable. In federal terms it is a firm-fixed-price arrangement under FAR 16.202, which puts the schedule and cost risk on us, where a buyer who cannot yet evaluate the work should want it. Commercial clients get the same structure under ordinary commercial terms.
A discovery is not a slide deck. It produces working artifacts: a data profile of what you actually have rather than what the schema claims; a running baseline that produces real outputs on real records; an evaluation harness with a held-out test set and its numbers; a written production architecture; and a build estimate with the risks named and priced. You keep all of it whether or not you continue.
Discovery ends in one of three places. The thing is buildable and we quote the build. It is buildable but the value is not there, and we say so in writing. Or the blocking constraint sits somewhere else, and the report tells you where.
Fixed, small, and terminable
A discovery is priced as a fixed sum agreed in advance, invoiced on completion, with no change orders inside the window. It is small enough to approve without a capital request, and you can walk away at the end owing nothing further. The first money you spend with us should buy a decision, not a dependency.
Step five: acceptance criteria, written before anyone builds
The build statement of work carries acceptance criteria written as tests, not adjectives. Each one names the metric, the dataset it is measured on, the threshold, and who runs the measurement. A typical set has four to seven criteria, and they cover quality, performance, operations, and security.
Quality. A stated numeric threshold on a held-out dataset that our team does not tune against. Where a human reviewer is the standard, the criterion is agreement against an adjudicated sample, with the adjudication rules written down first.
Performance. Latency at a stated percentile and a stated concurrency, on the hardware the system will actually run on. Not on a laptop.
Operations. The system deploys from a clean checkout, in your environment, by your engineer, following the runbook, with no one from our team touching the keyboard. That criterion catches more real defects than any other single item on the list.
Security and records. Controls appropriate to the data class, evidenced rather than asserted: for CUI on a defense contract that means the NIST SP 800-171 control set invoked by DFARS 252.204-7012 and the CUI rules at 32 CFR Part 2002; for health data, the HIPAA Security Rule at 45 CFR Part 164; for a federal system of record, the logging and traceability the ATO package requires.
Acceptance criteria are the client's protection, and we write them to be usable against us. If the delivered system misses a threshold, fixing it is our schedule and our cost.
First engagement, end to end
Step six: the paperwork, by client type
The instrument depends on who you are. None of these takes long, and our team has the templates ready.
| Who you are | What the first engagement usually is | Instrument |
|---|---|---|
| Prime on a federal bid | An AI/ML workshare defined before proposal submission, with a technical narrative and a priced basis of estimate you can drop into your volume | Mutual NDA, then a teaming agreement; a subcontract on award, flowed down per FAR 52.244-6 |
| System integrator on a live delivery | A scoped module or a bench of named engineers against a defined statement of work | NDA, then a fixed-price or capped time-and-materials subcontract |
| University research team | The small-business half of an STTR, including the commercialization plan and the engineering that turns the research into software | NDA, letter of intent, allocation-of-rights agreement, then a subaward at award |
| State or local agency | A discovery against your records problem, or a subcontract under an incumbent prime | Purchase order or subcontract; federal pass-through funds follow 2 CFR 200.331 |
| Commercial company | A fixed-scope discovery, then a milestone build | Mutual NDA and a two-page master services agreement with a per-project SOW |
One note for primes: a documented private-sector engagement with us is citable past performance under FAR 15.305(a)(2)(ii), which lets an agency consider a subcontractor's relevant record. Ask for the performance summary at closeout and it arrives written for proposal use.
Step seven: the build
Builds run in milestones of two to three weeks, each with something you can run at the end. We work in your repository from the first commit where possible, or in ours with mirrored history where your access controls require it. Either way you see the code as it is written.
Every milestone closes the same way: the branch merges, the pipeline runs, the evaluation harness reports its numbers, and you get a short written note that says what moved, what did not, and what is now known that was not known before. Nobody has to attend a status meeting to learn whether the project is in trouble.
Our team keeps the engineer who scoped the work on the work. The named people on the one-page scope are the people who build it. When a build needs a licensed professional engineer, a clinician, or another domain specialist, we name that person from our standing bench in the SOW rather than describing an anonymous resource.
What you own at the end
This is the part most vendors leave vague, so here it is flatly. On acceptance and payment, you own the delivered work product: source code, infrastructure-as-code, container definitions, configuration, migration scripts, the evaluation harness, test fixtures, trained model artifacts, the data dictionary, the runbook, and the acceptance report. It lands in your repository and your cloud account, not ours.
We retain rights only to our pre-existing tooling and general methods, licensed to you perpetually and irrevocably for the delivered system, which is standard practice and is written into the SOW rather than buried. We do not hold your deployment hostage through a private dependency, and we do not ship an artifact your engineers cannot rebuild from source.
Federal work follows the applicable data-rights clause instead of our commercial terms, and the clause is named in the subcontract before work starts. For most federal software deliverables that is FAR 52.227-14 or, on defense work, DFARS 252.227-7014 for noncommercial computer software. Work funded under an SBIR or STTR award carries SBIR data rights under DFARS 252.227-7018, which protect the data for a 20-year period running from the award of the funding agreement, per the SBIR/STTR Policy Directive. If you are a prime and the rights allocation matters to your customer, raise it during scoping and we will write it the way your contract needs it.
Handoff, and what "done" actually means
Handoff is three to five days and has one test: your engineers deploy the system, from a clean checkout, in your environment, following our runbook, while we watch and answer questions. If they cannot, it is not done, and finishing it is our cost.
The package includes the runbook, an architecture document short enough that someone will read it, the evaluation harness with instructions for re-running it on new data, a list of known limitations written honestly, and a recorded walkthrough for the engineers who join your team next year. A support window after handoff is available if you want one, and designed to be unnecessary.
What we decline
We say no to staff augmentation with no defined deliverable, to work where nobody will grant data access, to projects whose only success criterion is a demonstration, and to engagements where an organizational conflict of interest under FAR Subpart 9.5 would compromise a competition. We also decline work outside what our engineers do. We build production AI, ML, data, and cloud systems, and we say so plainly rather than subcontracting the rest quietly.
Common questions before the first email
Do I need budget approved before I email you?
No. Scoping is free and produces a one-page document with a price on it, which is usually the artifact you need in order to get budget approved. Many first emails arrive precisely because someone needs a credible number to take to a finance committee or a capture review.
What if I cannot share the data yet?
Common, and not a blocker for scoping. Describe the schema, the volume, the sensitivity class, and the access process. We scope against the description and write the access timeline into the SOW as a dated assumption. If access slips, the schedule moves with it and neither side is surprised.
We are two weeks from a proposal deadline. Is that too late?
Not for a workshare. Send the solicitation number and the close date and you will have a yes or no the next business day, with a technical narrative and a priced basis of estimate inside a few days of a yes. Two weeks is workable. Two days is not, and we will tell you that instead of promising it.
Can you work under our security requirements?
Tell us the data class and the environment in the first email. We work in customer-controlled cloud accounts, in restricted and disconnected environments, and under CUI handling requirements. Export-controlled technical data is covered by our JCP / DD-2345 certification.
Frequently asked questions
Roughly one week from first email to signed scope, two to three weeks for a fixed-price discovery, and six to twelve weeks for a first production build. A proposal workshare moves faster, since the deliverable is a technical narrative and a basis of estimate rather than a system.
Because the accuracy of any build estimate depends on facts about your data that nobody knows yet. A short fixed-price discovery converts those unknowns into measured numbers, so the build quote is real. It also gives you a low-cost exit if the answer turns out to be that the project should not proceed.
Source code, infrastructure-as-code, model artifacts, evaluation harness, test fixtures, runbook, and documentation, delivered into the client's own repository and cloud account. Federal work follows the data-rights clause named in the subcontract, commonly FAR 52.227-14, DFARS 252.227-7014, or SBIR data rights under DFARS 252.227-7018.
Yes, on federal, state, and commercial work, and it is a large share of what we do. The usual sequence is a mutual NDA, a teaming agreement before submission, and a subcontract on award with the appropriate FAR and DFARS flowdowns.
No defined deliverable, no path to data access, no decision-maker who will act on the result, an organizational conflict of interest, or a scope outside production AI, ML, data, and cloud engineering. We say no quickly and give the reason. A fast no is worth more than a slow maybe.