Why a scope page is worth writing honestly
A capability list that includes everything is the same as a capability list that includes nothing. It transfers no information, and the reader who most needs the information — the engineer or the program owner who already knows their own constraints — learns nothing from it and moves on. We would rather write the version that can lose us an engagement, because the same sentences that turn away the wrong work are the ones that let the right work recognize itself.
Precision Federal is an Iowa limited liability company. We are a small engineering firm with a few members, and we build production AI, machine learning, data and cloud systems for federal missions. The paragraphs below are the scope statement. Where we say no, we give the reason, and where the reason is a rule rather than a preference, we name the rule so it can be checked without taking our word for it.
The problems we take on
The common thread across everything below is that the system has to survive somebody else's review — a security control assessor, an authorizing official, an inspector general, a program office that will operate it after we are gone. That constraint is what shapes the engineering, and it is the reason our work looks different from a commercial build of the same nominal feature.
- Retrieval over a corpus with access rules — structural chunking, hybrid dense-and-lexical retrieval, reranking, classification labels enforced as a pre-search filter rather than a post-filter, and citations that open the actual source paragraph. RAG systems.
- Small models that run where the data already lives — headless, offline-installable, no outbound calls, no hosted API on the critical path, packaged so an environment we cannot see can stand it up from an artifact. Enclave-resident AI.
- Cloud and platform engineering at DoD impact levels — boundary drawing, service-by-service accreditation checks, hardened images, and the documentation package that has to match the architecture. IL5 cloud.
- The authorization-engineering side of RMF — control narratives written with the engineers who built the control, organization-defined parameters traced to real values, evidence generated by the system instead of asserted in a policy PDF. ATO engineering and FedRAMP engineering.
- Data platforms that carry classification with the data — ingest, lakehouse and streaming architectures where every column is tagged at ingest and the tag travels downstream through lineage. Data engineering.
- MLOps that an assessor can audit — a model registry that answers what is running right now, on what data, approved by whom; drift monitoring wired to a ticket rather than a dashboard; rollback that works. MLOps.
- Measurement and governance artifacts as engineering output — bias, robustness and evaluation harnesses that run in CI, model cards generated on release, risk registers mapped to framework subcategories. Responsible AI.
- CUI enclave design and 800-171 implementation — scoping the boundary down to the smallest population and stack that can hold the controlled data. CMMC readiness.
A request shaped like this sits squarely inside that list: a bespoke small model trained on an organization's own corpus, delivered as an artifact that deploys into a sandbox the customer controls, with no telemetry leaving the boundary and no dependency on a hosted endpoint. We are set up for that shape of work — the packaging discipline, the offline dependency handling and the evidence trail are the parts we spend the most time on. If that is the request, it is worth a conversation.
What we decline
Each of the following is a standing refusal, not a negotiating position. Several of them exist because a federal rule assigns the role to somebody else, and a firm that offers to do it anyway is either mistaken about the rule or hoping the buyer is.
| What we decline | Why | What we do instead |
|---|---|---|
| Issuing or granting an ATO | The authorization is a federal official's risk decision. NIST SP 800-37 Rev. 2 states that explicit acceptance of risk is the authorizing official's responsibility and cannot be delegated. | Build the system and produce the evidence package the authorizing official reads before signing. |
| Certifying you for CMMC | We are not a C3PAO. Under 32 CFR part 170, Level 2 certification assessments are performed by CMMC Third-Party Assessment Organizations authorized through the Accreditation Body. | Implement NIST SP 800-171 controls, scope the CUI enclave, and hand a clean environment to a C3PAO you select. |
| Assessing our own work | FedRAMP does not allow a 3PAO to author an SSP for a cloud service provider and then assess it. The same conflict exists for any firm holding both roles. | Engineering review you keep; the independent assessment goes to an independent party with no stake in the finding. |
| Classified processing on classified networks | We do not hold a facility clearance today, and under the NISPOM at 32 CFR part 117 an FCL is sponsored by a government contracting activity or a cleared prime — a company cannot apply for one on its own. | Build to the constraints those environments impose, so the work transfers cleanly if and when a sponsor exists. |
| Selling training as a product | We are an engineering firm, not a courseware vendor. Curriculum, certification prep and workshop delivery are somebody else's craft. | Transfer what we built — runbooks and working sessions with the engineers who wrote the code — as part of delivery. |
| Writing proposals for other firms | Proposal work for another offeror puts us on both sides of a competition we may also be in. | Team as a named subcontractor on scope we will actually perform. See teaming. |
We will not hold both sides of an evaluation
The three refusals at the top of that table are versions of one principle. An assessment is only worth the independence behind it, and independence is destroyed the moment the assessor has an interest in the finding. Federal rules are explicit about this in the places where it has been tested. FedRAMP recognizes 3PAOs accredited by A2LA against ISO/IEC 17020, and a 3PAO that prepared a provider's System Security Plan is not permitted to then perform that provider's assessment. On the defense side, 32 CFR part 170 requires C3PAOs to comply with the Accreditation Body's conflict-of-interest policy, which is the mechanism that separates the firm that prepared an organization from the firm that assesses it.
We apply the same logic where no rule requires it. If we build a system, we do not also write the independent evaluation that says the system is good. If we are asked to review another vendor's work, we will do it as an engineering review the customer owns outright — findings written plainly, handed over, and not followed by a proposal from us to fix what we found. Anyone can offer that arrangement; very few offer it before being asked, which is exactly when it is worth something.
Clearance, and what "not today" honestly means
We do not hold a facility clearance. That is a plain fact and we would rather state it on a public page than let it surface three meetings into a discussion. Under the National Industrial Security Program Operating Manual, codified at 32 CFR part 117, a facility clearance is not something a company obtains on its own initiative — it is sponsored, either by a government contracting activity or by a cleared prime contractor, and the sponsorship follows a bona fide requirement for access on a specific effort.
What that means practically: we do not perform classified work on classified networks, and if your requirement is analysis inside a SCIF today, we are not the firm. What we do is build to the constraints those environments impose — offline installability, no phone-home behavior, dependency inventories that survive a one-way transfer, retrieval that enforces labels before a model sees a document — so that a system built unclassified is a system that can move. Designing to a pattern and operating inside an accredited enclave are different things, and we are careful not to let the first imply the second.
Nothing arrives pre-accredited
A recurring claim in this market is that a product is "FedRAMP" or "IL5," full stop, as though the label attaches to the software and travels with it. It does not, and we will not repeat the claim about our own work. FedRAMP authorizes a specific cloud service offering with a specific boundary. Under the DoD Cloud Computing Security Requirements Guide, DISA issues a provisional authorization for a cloud service offering; the mission owner's authorizing official still grants the ATO for the system built on top of it.
Inheritance is real, and it is partial. Deploying inside an authorized platform means a set of infrastructure controls can be inherited with a documented reference to the provider's authorization — that is a genuine reduction in work, and it is why platform choice matters early. It is not an authorization for your application, your data flows, your identity model or your logging. When we hand over a component, we say precisely which controls it satisfies, which it inherits, which it leaves to you, and what evidence it emits. That list is longer and less satisfying than "pre-accredited," and it is the one that survives an assessor.
Demos that cannot deploy, and rewrites that cannot finish
We will not build a demonstration that has no path to the environment where the data actually lives. If the corpus cannot leave a boundary, then a hosted prototype over sample data proves one thing only: that the prototype runs somewhere the real system never will. Every hard problem — throughput inside the available compute, dependency handling with no package index, label-aware retrieval, audit output the enclave's logging can consume — has been deferred rather than solved, and the deferral is discovered at the worst moment. We would rather build the smaller thing that runs in the real place. It demonstrates less and proves more.
We also will not recommend replacing a working system in one motion. The Government Accountability Office has reported on this for years: Information Technology: Agencies Need to Develop Modernization Plans for Critical Legacy Systems (GAO-19-471, June 2019) and, more recently, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795) document how long these systems persist and how much of federal operations still runs on them. The mechanism behind the failures is not mysterious. A rewrite asks a team to reproduce behavior that was never written down, encoded over decades in exception handling and operator habit, while shipping nothing until the whole replacement is done. Our default is incremental: put the new component beside the old one, move one flow, run both, measure the difference, and keep the ability to stop at any point with something better than when you started. That is the strangler-fig pattern Martin Fowler described, and it exists because the alternative keeps not working. See legacy modernization.
What a first conversation looks like
There is no retainer to talk. A first exchange is a scoping conversation: what the system is, who operates it, where the data sits, what constraints are already fixed, and what has been tried. If it becomes clear during that conversation that the work belongs somewhere else, we will say so and, where we can, point at who is better positioned.
A short scoped assessment, ending in a written recommendation you keep
Rather than a proposal built on assumptions, the first piece of work is a bounded assessment against the real system and the real constraints — the architecture as it exists, the data as it is actually classified and stored, the authorization posture, and the people who will run it afterward. It ends in a written recommendation: what we would build, what we would leave alone, what we think will not work and why, and where another firm is the better fit. It is yours regardless of whether we do the build. Scope, price and schedule come out of that assessment, not before it.
How to tell quickly whether this is a fit
Answering these honestly will settle it faster than a capabilities briefing will.
Can you name the system? If the answer is "we want to use AI" rather than a named system with users, an owner and a data source, the work is upstream of us. That is a real stage and worth doing — it is just not an engineering engagement yet.
Does the data have a home it cannot leave? If yes, this is a good sign for fit. Our defaults already assume no outbound network, no hosted endpoint and an artifact handed across a boundary. If the data is happy in a commercial cloud with no access constraints, a general software firm will serve you at lower cost.
Is there someone who will operate this after we leave? If nobody owns it in production, what gets built is a demonstration, and we should both name it that at the start rather than discover it at delivery.
Do you know who signs the risk? If no authorizing official is identified, the first work is finding that person and learning what they need to see. Building first and looking for a signer later is the most common way federal AI work stalls after it technically succeeds.
Is there a number that would change if this worked? Hours per case, backlog depth, time to a decision, error rate on a task somebody currently does by hand. Without one, there is no way to tell whether the system helped, and the engagement ends in an argument about impressions.
Are you asking us to certify, authorize or independently assess something? Then you want an assessor, and we are the wrong call. We are happy to say which kind, and why.
Common questions about where the line sits
You publish about air-gapped and enclave systems, but say you do not do classified work. Which is it?
Both, and the distinction is between designing to a constraint and operating inside an accredited environment. We build systems that assume no outbound network, no package index at runtime, label-aware retrieval and audit output the receiving environment can consume, because that discipline is right for a great deal of unclassified but controlled work. Performing classified processing on a classified network additionally requires a sponsored facility clearance and cleared personnel, which we do not have today. We will not blur that.
Can you get us CMMC certified?
We can implement the NIST SP 800-171 controls, design and shrink the CUI enclave, author the SSP and drive the plan of action to closure. We cannot certify you, and neither can any firm that did the implementation — 32 CFR part 170 assigns certification assessments to C3PAOs authorized through the Accreditation Body and requires them to follow that body's conflict-of-interest policy. Treat any firm offering both as a signal about how they read rules generally.
Another vendor is already building it. Will you review their work?
Yes, as an engineering review that belongs to you: architecture, data handling, evaluation method, control evidence, operational readiness. What we will not do is deliver findings and then bid to remediate them. If the review concludes the current vendor is doing it correctly, that is a legitimate outcome and we will write it that way.
Will you work under a prime rather than directly?
Yes, on scope we will actually perform ourselves. We do not accept pass-through scope we intend to hand to somebody else, and we do not lend our name to a capability we cannot staff. Details on teaming.
Frequently asked questions
No. An ATO is a management decision by a federal authorizing official who explicitly accepts residual risk on the agency's behalf. NIST SP 800-37 Rev. 2 states that this acceptance of risk cannot be delegated. A contractor builds the system, implements the controls and assembles the evidence; the signature belongs to the government.
For CMMC, no. 32 CFR part 170 assigns Level 2 certification assessments to C3PAOs authorized through the Accreditation Body, and requires them to comply with that body's conflict-of-interest policy. FedRAMP applies the same principle to 3PAOs, which may not assess a package they authored. Separate the builder from the assessor as a matter of course.
No. FedRAMP authorizes a specific cloud service offering, and DISA issues provisional authorizations for cloud service offerings under the DoD Cloud Computing SRG. Your application, data flows, identity model and logging still require their own authorization. You inherit infrastructure controls with a documented reference — a real reduction in work, not a substitute for it.
Not on their own. Under the NISPOM at 32 CFR part 117, a facility clearance is sponsored by a government contracting activity or a cleared prime contractor, tied to a bona fide need for access on a specific effort. A firm without one should say so plainly rather than imply otherwise.
Because a rewrite asks a team to reproduce undocumented behavior while delivering nothing until it is complete, and the undocumented behavior is usually the part that matters. Incremental replacement puts the new component next to the old one, moves one flow at a time and keeps a working system throughout. GAO's reporting on long-lived federal legacy systems, including GAO-19-471 and GAO-25-107795, is a useful backdrop for how durable these systems are.