Why this page exists
Most of the time it takes to answer a first email is spent finding out whether the work is a fit at all. Two weeks of calls, a mutual NDA, a discovery session, and then somebody discovers the scope was never ours to take. This page removes that step. Below is the list of what we build, the list of what we turn down, and the reason attached to each refusal. If your work is in the first list, one email gets you an answer inside a business day. If it is in the second list, you will know in the time it takes to read a page, and we will usually name someone better suited.
Declining well is the strongest credibility signal an engineering firm has available. A shop that says yes to everything is telling you three things at once: it has no method that constrains what it can do well, no bench worth protecting, and no view of where its own work stops being good. We would rather be the firm you call for four problems and never for the fifth.
Our team is led by a former professor in technology who ranks in the Kaggle top 200 of more than 200,000 competitors and holds seven cloud certifications, with twenty years building production systems for federal agencies across five consulting firms, three of them federal. Around that sits a standing bench of named engineers, licensed professional engineers, and domain specialists across defense, health, energy, transportation, and public-sector data. That shape determines both lists.
What we build
Five lines of work, and the SBIR and STTR programs that fund a good share of them. Prime or subcontract, federal, state, or commercial.
- Production AI and ML. Models that run behind a live workflow with real evaluation, drift monitoring, retraining, and a rollback path.
- Data engineering. Ingest, entity resolution, lineage, quality gates, and warehouses that survive the handoff to a government team.
- Cloud and platform. AWS GovCloud and Azure Government, infrastructure as code, CI/CD, container hardening, and the security boundary that goes with it.
- Full-stack delivery. The application around the model: API, interface, authentication, audit log, and Section 508 conformance from the first sprint.
- Modernization. Moving mainframe, Oracle Forms, Access, and unsupported .NET systems onto current architecture without a big-bang cutover.
- SBIR and STTR research. Phase I feasibility through Phase II prototype, as the small business of record or as a named subcontractor with real scope.
Production AI and ML
The part of AI work that decides whether a system survives contact with a federal user is the evaluation, not the model. We build that first: a labeled holdout the customer agrees with, a false-extraction rate, a refusal rate, a per-class breakdown, and a threshold a program manager can move without calling us. Then we build the model that has to clear it. A system with no agreed metric cannot be defended in a review and cannot be improved after we leave.
We document to what federal reviewers now expect: model cards, data provenance, intended-use statements, and the risk mapping in the NIST AI Risk Management Framework. For systems carrying consequences for a member of the public, OMB memorandum M-25-21 sets the high-impact category and requires human oversight and a documented failure path. Those are design inputs on day one, because retrofitting an audit trail into a shipped model is the most expensive kind of rework there is.
Data engineering
Half the AI projects that fail never had a data problem in the modeling sense. They had a plumbing problem: three systems of record with different keys, an extract arriving weekly as a flat file, and no owner willing to sign off on what a record meant. We build the plumbing. Ingest with schema contracts, entity resolution that produces auditable match evidence rather than a black-box score, lineage that traces a dashboard number back to the row it came from, and quality gates that fail loudly instead of passing bad data downstream.
We also build for the handoff. Every pipeline we deliver comes with a runbook, tests a government engineer can run, and infrastructure defined in code so the environment can be rebuilt without us. That is a deliberate choice about how the relationship ends. A pipeline nobody but the vendor can operate is a hostage, and agencies have learned to spot one.
Cloud, platform, and the security boundary
We build in AWS GovCloud and Azure Government, and we design to the impact level the data actually carries. Controlled Unclassified Information on a DoD system means DFARS 252.204-7012 flowdown and the NIST SP 800-171 control set, with the CMMC program requirements at 32 CFR Part 170 now attached to solicitations through DFARS 252.204-7021. Cloud services carrying federal data need a FedRAMP authorization at Moderate or High, and DoD workloads add the Impact Level structure on top, from IL4 to IL6.
Most of the security cost on a project is not the controls. It is the boundary drawing: which components sit inside the authorization, what crosses, and who signs. We do that work early and write it down in a form an assessor can read, because an elegant system that cannot get an authorization to operate never carries a single user.
Full-stack delivery and modernization
A model with no interface is a research artifact. We build the application around it, which in federal work means authentication against the agency identity provider, a per-action audit log, role separation that survives an inspector general question, and Section 508 conformance under 29 U.S.C. 794d designed in rather than remediated after a complaint.
On modernization, we work incrementally. New services stand up beside the legacy system, traffic moves route by route, and the old code retires only after the replacement has carried production load. Agencies have watched enough big-bang cutovers fail that a phased plan with reversible steps is now the easier plan to fund.
Where our fit runs strongest
Editorial weighting of problem-class fit, not a measured statistic.
What we decline
Seven categories. Each one has a reason that is either a rule, a conflict, or a judgment about where our work stops being worth what it costs. None of them is a soft no that a bigger number reopens.
| The request | Our answer | The reason |
|---|---|---|
| Assess the system we built for you | No | Impaired objectivity under FAR Subpart 9.5 |
| Give us three engineers by the hour | No | We sell scope and outcomes, not seats |
| Write our SBIR proposal for us | No | The awardee must perform the work |
| Start now, data access later | Not yet | The schedule is fiction until the data path exists |
| Automate the adverse decision itself | No | Human oversight is required for high-impact use |
| Pay you a percentage if we win | No | Covenant against contingent fees, FAR 52.203-5 |
| Fabricate the hardware too | Routed | Software firm; we team for fabrication |
We do not grade our own homework
If we build a system, we will not also be the independent assessor of it. That is not a preference. FAR Subpart 9.5 treats impaired objectivity as a real organizational conflict of interest, and the Preventing Organizational Conflicts of Interest in Federal Acquisition Act of 2022 pushed agencies to tighten how they identify one. The same logic runs through the accreditation regimes: FedRAMP third-party assessment organizations are accredited under an inspection-body standard precisely so the assessor has no stake in the outcome, and CMMC third-party assessors operate under the same separation at 32 CFR Part 170.
The practical version is simpler. An engineer who spent six months making a design work cannot then credibly report that it does not. We will hand your assessor a clean package and fix what the assessment finds. We take independent review work happily when the system came from somewhere else, which is the version where the finding means something.
We do not sell seats
A named engineer at an hourly rate, sitting in a customer's sprint, taking direction from a customer's lead, is staff augmentation. That is a legitimate business and it is not ours. When a firm bills by the seat, the incentive quietly inverts: the longer the work takes, the better the quarter looks. We price a scope, a deliverable, and a date, and we carry the risk of the estimate.
What we do take is an engineering subcontract with a defined statement of work, our own technical lead, and acceptance criteria written before the first commit. Same people, different contract shape, opposite incentives. If you need bodies to fill a labor category on an existing task order, we will say so on the first call and point you at firms that do it well.
We do not write another firm's proposal
Proposal-writing-as-a-service for someone else's SBIR is a hard no for two reasons. The first is the program's own rule: the SBIR Policy Directive requires the awardee to perform a minimum share of the research itself, at least two-thirds of the effort in Phase I and at least half in Phase II. A proposal written by an outside shop that then performs the technical work has a structural problem long before the audit. The second is conflict. We bid these programs, and the firm that hands us its technical approach on Monday is competing against us on Tuesday.
What we do instead is straightforward: we join the team as a named subcontractor with real scope, our own tasks, our own budget line, and our own bios in the personnel volume. That sits comfortably inside the performance rules, and it makes the proposal stronger because the technical risk is carried by whoever is going to retire it.
Building and judging are separate contracts
We will build your system, or we will independently evaluate someone else's, and we will help you prepare for an assessment either way. What we will not do is occupy both sides of the same system, because a finding from an interested party is worth nothing to the agency that has to rely on it.
We do not start a build with no data path
The single most common way an AI project dies is that nobody could name the system of record, the human who owns it, and the approval that releases an extract. Every week of that ambiguity burns a week of a fixed schedule while the engineers write mock data.
So we ask three questions before we quote: where does the data live, who signs to release it, and when does a real sample land. If the answers are not known, we scope a short data-access engagement to get them, with a written deliverable naming the systems, the owners, the agreements required, and the volume actually available. That is a smaller contract and a better use of the first month than a build that stalls at the same wall in week five.
We do not automate the adverse decision
We build systems that sort, rank, extract, flag, and explain. We decline to build the system that denies a benefit, revokes a credential, or issues a penalty with no person in the loop. Federal policy is now explicit that AI carrying consequences for rights or safety requires human oversight and a documented path to contest an outcome, and the administrative law behind it is older than any of this: an agency action has to rest on a reason a reviewer can read.
This is also the design that survives. A decision-support tool with span-level provenance, where an adjudicator clicks a recommendation and sees the exact sentence in the exact document it came from, gets adopted. A black-box automatic denial gets litigated, then turned off. We build the version that is still running in three years.
We do not take contingent or success fees
No percentage of a win, no fee contingent on award, no equity for proposal work. FAR Subpart 3.4 and the covenant at FAR 52.203-5 exist because contingent-fee arrangements in federal contracting carry a specific corruption risk, and a small firm that treats that rule as flexible has told a contracting officer everything they need to know. We bill for engineering, at a rate, for work performed.
Two more, and what we do with them
Hardware fabrication and wet-lab work. We are a software firm. We build the control software, the data path, the models, and hardware-in-the-loop test rigs, and our bench includes licensed professional engineers who carry domain review on the physical side. Actual fabrication, machining, and laboratory chemistry go to a teammate, and we will say that on the first call rather than after the award.
Work that must run inside a cleared facility. Where a task has to be executed inside cleared spaces, we structure the team so a cleared partner carries that segment and we carry the unclassified engineering beside it. We hold JCP and DD-2345 certification for export-controlled technical data under CAGE 1AYQ0, so the controlled-data handling on our side is already in place, and the teaming structure is a routine one that primes set up regularly.
What a "no" from us actually looks like
A no is not the end of the email thread. When the work sits outside our lists, we say which category it fell into and, where we can, name a firm or a research institution that does it. We keep a warm bench of academic partners and specialist shops so a refusal can arrive with a referral attached.
We also decline work we could technically take when the fit is thin, and that is the harder discipline. The check we run is whether the person on our bench who would own it is genuinely one of the better people in the country for that problem. If the honest answer is merely competent, you are better served elsewhere, and we would rather keep the relationship for the next one.
How a request gets answered
Where the line moves, and where it does not
Does the conflict rule mean you cannot help us prepare for an assessment?
No. Preparing a system and its documentation for an assessment is engineering work, and we do a lot of it. The line is on issuing the finding. We will write the system security plan, close the gaps, run the internal dry run, and sit with your assessor. We will not be the assessor of record on a system we built.
We need a subcontractor for one deliverable, not a whole program. Too small?
Not too small. A single well-defined deliverable with a date and acceptance criteria is our favorite shape of work. The size that gives us trouble is an open-ended retainer with no deliverable, because there is nothing to be accountable to.
Our work is commercial, not federal. Are you interested?
Yes. The lists on this page are the same for commercial and state and local clients. The federal rules we cite drive the refusals that come from regulation, and the rest of the method transfers unchanged. Commercial buyers usually notice that the audit trails and handoff documentation we build by habit are worth more than they expected.
Can you take direction from our technical lead?
We take requirements, priorities, and acceptance criteria from your lead, and we work in your ceremonies if that is how the program runs. What stays with us is the technical execution and the accountability for the deliverable. That distinction is what separates an engineering subcontract from a staffing arrangement, and it also matters to your contracting officer.
Frequently asked questions
Because it saves both sides weeks. A buyer who reads a scope statement and self-selects out never spends time on a call that was going nowhere, and a buyer who reads it and self-selects in arrives already knowing how the engagement will be shaped. The refusals also carry information about method that a capability list cannot.
The two common shapes are unequal access to information and impaired objectivity, both addressed in FAR Subpart 9.5. Impaired objectivity is the one that bites AI work: a firm evaluating, testing, or certifying a system it has a stake in cannot render an unbiased judgment. The cleanest mitigation is structural separation, which is why building and assessing stay on separate contracts.
Under the SBIR Policy Directive, at least two-thirds of the research effort in Phase I and at least half in Phase II must be performed by the awardee, with the balance available to subcontractors and research partners. STTR uses a different split, with a research institution carrying a defined share. Those percentages shape how a teaming arrangement can legitimately be built.
Three things: what the system has to do, where the data lives today, and the date something has to be working. If it is a bid, add the solicitation number and the close date. That is enough for a yes or a no, and almost never requires a call first.