Why we publish our methods

The market runs on claims that cannot be checked

Nearly every firm selling artificial intelligence to a government buyer says the same six things. Deep expertise. Mission focus. Proven approach. Trusted partner. End-to-end delivery. Rapid results. None of those sentences can be false, which is exactly the problem. A sentence that cannot be false carries no information. A capture manager reading forty capability statements in a week is reading forty documents that are identical in substance and different only in typography.

We took a different route. What this firm knows about federal AI delivery goes on this website, in public, with the regulation cited and the threshold named, so a reader can grade the reasoning line by line before speaking to anyone here. That is what the insights library is. It is not marketing content wearing an education costume. It is the working knowledge of our bench, written down where a stranger can check it against the primary source.

The test we set for ourselves is narrow. If a program manager who has run twenty AI acquisitions reads our piece on authorization boundaries or data rights, does that person finish it thinking "these people have done this," or thinking "these people have read about this"? Only the first answer justifies the hours. When a draft lands on the second answer, it does not go up.

What the federal evidence rules do to a buyer

Federal source selection has a structural gap that is rarely said out loud. Under FAR 9.104-1, a contracting officer must make an affirmative determination of responsibility before award, covering financial resources, ability to meet the schedule, performance record, integrity, and technical capability. Under FAR 15.305(a)(2)(iv), an offeror without a relevant performance record may not be evaluated favorably or unfavorably on past performance. That rule exists to keep the door open for new entrants. Its side effect is that on that one factor, a thirty-year incumbent and a firm the evaluator has never heard of can land in the same place.

So the weight moves elsewhere. Where past performance goes neutral, technical merit and the qualifications of the proposed team decide the award. In DoD SBIR evaluations those are two of the three published criteria, sitting alongside commercialization potential, and all three are judged from what the offeror wrote. Nothing else is available to the evaluator. The same dynamic runs through commercial and state buying for different reasons: a first-time buyer of machine-learning work has no instrument for grading a vendor's technical claim, so the buyer grades the prose the claim arrived in.

That is why we treat the public library as a capture asset rather than an afterthought. Whoever is deciding whether to put our name in their proposal will make that decision from text. We would rather they make it from three thousand words of our engineering reasoning than from a one-page slick sheet with a stock photo of a server rack.

A falsifiable sentence beats ten confident ones

The discipline is simple to state and hard to keep: name the part, the section, the clause, the number. When we write that a small business subcontracting plan attaches once a contract exceeds the FAR 19.702 threshold of $750,000, a reader who works in contracts knows within seconds whether we are right. When we write that DFARS 252.204-7012 pulls the NIST SP 800-171 control set onto a contractor's covered systems, or that the CMMC program requirements live at 32 CFR part 170, that is four minutes of checking. When we write that SBIR data rights under DFARS 252.227-7018 run for twenty years from award, someone can confirm it and then know something about us.

Set that against "we bring deep compliance expertise." There is no world in which that sentence turns out wrong. It cannot earn trust because it can never lose any. Every claim we make that can be checked is a small bet we are placing in public, and a reader who checks two of them and finds them correct has real evidence about the third.

We get things wrong sometimes. Regulations move, thresholds get adjusted for inflation, clause numbers get reissued. When a reader writes in with a correction we fix the page and thank the person, because a correction is proof the mechanism works. A firm whose public writing has never needed a correction has never written anything specific enough to correct.

Writing is also how our bench stays honest

There is an internal reason, and it is the stronger of the two. Writing a public explanation of an authorization boundary forces the writer to actually know where the boundary sits. You cannot draft the paragraph on which components fall inside a System Security Plan and which fall outside on a vague sense of the answer. The sentence will not come out. Vagueness is visible in prose in a way it is never visible on a slide.

So each article here is drafted by someone on the bench who does that class of work, checked against primary sources, and edited by a second engineer with standing authority to say the argument does not hold. It is the same practice we run on proposal volumes and on delivered code. The library is simply where that practice is visible to outsiders.

The people writing are the people who would do your work. Our team is led by a former professor in technology who ranks in the Kaggle Top 200 out of more than 200,000 competitors, the top one tenth of one percent worldwide, holds seven cloud certifications, and has twenty years building production systems for federal agencies across five consulting firms, three of them federal. Around that core we keep a standing bench of named engineers, licensed professional engineers, and domain specialists across defense, health, energy, transportation, and public-sector data. Precision Federal is active in SAM.gov, holds CAGE code 1AYQ0, and is JCP and DD-2345 certified for controlled technical data.

What goes in, and what never goes in

Writing openly does not mean writing everything. There is a hard line, and it is drawn by statute and by client obligation rather than by preference. Knowing where that line runs is itself part of the demonstration.

Published here	Never published anywhere	Why the line sits there
Regulatory mechanics with the part and section cited	Customer names, program identifiers, contract numbers	The rules are public record. A customer relationship is theirs to disclose, not ours.
Technique comparisons drawn from open literature	Any client's technical data or delivered code	Contract data rights, plus DFARS 252.227-7018 protections on SBIR-funded work.
Our evaluation criteria and how we scope work	Proposal text, pricing on a live bid, competitive positioning	Procurement integrity and simple fairness to the customers running the competition.
Failure modes we have hit and how we test for them	Export-controlled technical data under 22 CFR parts 120 to 130	The ITAR does not have a blog exception. Controlled data moves through the certified channel.
Named bench roles, disciplines, and licensure	Controlled unclassified information under 32 CFR part 2002	CUI marking and handling obligations follow the data, including onto a web page.

Our JCP and DD-2345 certification exists precisely so controlled technical data can be handled in the right channel, and a public web page is not that channel. A reader who notices our writing runs right up to the edge of the public record and then stops is seeing the discipline, not the limit of what the bench knows.

The twenty-minute audit we invite

Here is how to grade us without a call, an NDA, or a calendar invite. Nothing in this sequence requires our participation, which is the point of it.

If we survive that, a call is worth your time. If we do not, you spent twenty minutes instead of an hour and we did not waste one either. Both outcomes are good outcomes, which is why we would rather be audited than pitched to.

What published reasoning replaces in a teaming decision

The usual sequence for choosing a subcontractor is a capability statement, a reference call, then an interview. Each step is weak in a specific way. A capability statement is written to flatter and is never wrong. A reference call reaches a contact the vendor selected. An interview measures how well a vendor performs in interviews, which tracks sales skill far more closely than engineering skill.

Published reasoning carries none of those weaknesses. You pick which pieces to read. You pick which claims to check. The vendor cannot curate your sample. Volume matters too: a firm can produce one impressive article, but a library of a hundred pieces that survive spot checks is not something a marketing department can manufacture.

The practical effect is speed. Most teaming conversations that start here open with someone who has already concluded we understand the problem class and now wants three things: availability, price, and whether the scope fits. That is a twenty-minute call, not three meetings and a bake-off.

If you are a prime capture manager

You need an AI/ML subcontractor who can write a technical section that survives evaluation, answer a customer's questions without you in the room, and not create a problem inside your subcontracting plan. Under FAR 19.702 and the clause at FAR 52.219-9, that plan carries small business goals you report against, and a sub who cannot deliver is worse for you than no sub at all.

Read the pieces closest to your solicitation's technical area first. If the reasoning lines up with what your customer actually needs, you already have most of a technical evaluation done. What is left is scope and price, and both of those we will put in writing quickly. When the answer is no, you get a reason and a fast release of your time.

If you are a faculty PI looking for a small-business partner

STTR requires the small business to hold the prime contract and perform at least 40 percent of the work, with the research institution performing at least 30 percent, under the SBA SBIR/STTR Policy Directive. The small business signs, carries the reporting, builds the cost volume, and owns the deliverables schedule. That split is why the quality of the small-business partner matters more than its convenience.

What our writing lets a PI check is whether the small business can genuinely carry the engineering half rather than quietly hand it back to the lab. Read what we publish on data pipelines, evaluation design, and deployment. If the engineering reads like people who have shipped systems into production, you have your answer without a single meeting. Our companion piece on structuring STTR university partnerships lays out the paperwork we handle so your lab does not have to.

If you are an integrator, a commercial buyer, or a state or local vendor

Same logic, different clock. A system integrator needs a bench that plugs in without a ramp. A commercial buyer has no FAR at all and therefore no procedural safety net. A state or local vendor is working through cooperative purchasing, piggyback awards, or a state term contract, with rules that change at every border. In every one of those cases the buyer's underlying problem is identical: grading technical capability without any instrument for testing it. Our writing is the instrument, handed over in advance and free.

If you are an investor or a board doing technical diligence

Technical diligence on an AI company usually collapses into a reference exercise, because the diligence team cannot evaluate the engineering directly and the founders can talk faster than the questions arrive. Reading a company's public engineering writing is a cheap and surprisingly strong substitute. Look for three markers: specificity that could be wrong, named failure modes, and a stated list of work the company declines. Any company that publishes all three has told you how it thinks under pressure. We publish all three about ourselves, including the work we turn down.

What publishing costs us

It is expensive. Every piece here consumes real bench hours from people whose hours are otherwise billable. Competitors read the library; framing that started on this site has turned up in other firms' materials with the serial numbers filed off. Publishing how we score a bid tells a rival exactly how we think about one.

We keep doing it because the alternative is worse. The alternative is asking strangers to trust assertions in a market where every firm makes the same assertions with the same adjectives. The only firm that separates from that pack is the one that shows its work and then invites the audit. We would rather compete on whether the reasoning holds than on who has the glossier one-pager.

The three ways our own writing can go wrong

Publishing a lot creates its own failure modes. These are the three we watch for, and readers are welcome to hold us to them.

• Confident vagueness. A paragraph that sounds authoritative and contains nothing a reader could falsify. When a draft has one, we cut it or add the number that makes it checkable.
• Stale regulation. A clause number or dollar threshold that shifted after publication. Every piece carries a visible date, and corrections go in on notice.
• Benchmark theater. A metric reported without the conditions that produced it. A number with no test set, sample size, or failure cases is decoration, and we treat it that way in other people's materials too.
• Reach beyond the bench. Writing about a problem class we have studied rather than built in. When that is the case, the piece says so plainly instead of blurring the difference.

Common objections to all of this

Read three, then send one paragraph

Do not take any of this on our word. That would defeat the entire argument. Open the library, pick three pieces in your own problem area, and check the claims that matter to you. If the reasoning holds and the specificity is real, you have already done the technical part of your evaluation and you know what kind of engineers you would be working with. If it does not hold, you have learned that at zero cost and no one had to sit through a call to find out.

What we want back is small. One paragraph, in plain language, describing what you are building and when something is due. We answer in writing, quickly, with a yes or a no. A yes comes with a one-page scope naming the engineers, the hours, and the price. A no comes with the reason and, when we know one, the name of a better fit.

Frequently asked questions