Here's something that surprised us when we started building AI systems for government: almost every AI vendor in the market assumes you have an internet connection.

That sounds obvious. Of course you need internet — the models are in the cloud, the APIs require authentication, the data flows up and the answers flow back down. That's how modern AI works.

Except if you're in a SCIF. Or on a ship. Or in a tactical operations center in a denied environment. Or on a classified network where "the cloud" is a concept you've heard about but can't actually use for anything that matters.

We decided to start from the opposite assumption: what if there is no network at all?

That single design decision changed everything about how we build.

The Problem with Cloud-First AI

Most AI systems today follow the same pattern. Your data goes up to a cloud provider. A large language model processes it. The answer comes back. You pay per query. Simple, effective, and completely unusable in about half the environments the Department of Defense operates in.

Global network visualization showing connected data points
Cloud AI requires constant connectivity. Many government environments have none.

The requirements for getting a cloud AI system authorized on a government network are substantial. You're looking at an Authority to Operate (ATO), IL5 or IL6 cloud authorization, FedRAMP compliance, DISA review, and months of paperwork before a single query runs. For classified networks, multiply that timeline by three.

And even after all that, you still have a fundamental dependency: if the network goes down, your AI goes down with it.

For a business application, that's an inconvenience. For a commander making decisions under fire, it's unacceptable.

What Changes When You Design for Zero Connectivity

When we removed the assumption of network access, three things happened that we didn't fully expect.

1. The knowledge had to live locally

If you can't call an API to look something up, you need the knowledge on the machine. So we built a knowledge graph — hundreds of thousands of verified facts and relationships, stored as binary files that load instantly via memory-mapping. No database server. No connection string. Just files on a disk.

The entire knowledge base for a domain — every fact, every relationship, every rule — fits in under 60 megabytes. That's smaller than a single PowerPoint presentation from most program offices.

This turns out to be a massive advantage even when you do have network access. Why send a query to an API and wait 2-3 seconds for a response when the answer is already on your machine and available in under 50 milliseconds?

2. The reasoning had to be deterministic

Cloud AI models give you a different answer every time you ask the same question. That's a feature for creative writing. It's a problem for intelligence analysis, audit findings, and mission planning — environments where reproducibility isn't optional.

Code on a computer screen showing structured logic
Deterministic analysis means the same input produces the same output. Every time. Auditable and reproducible.

Our system uses graph traversal as its primary reasoning method. When it follows a "Causes" edge from a problem node to a root cause node, that traversal is deterministic — same graph, same query, same answer. The graph structure is the reasoning. There's nothing probabilistic about it.

We only bring in a language model for the tasks that genuinely require judgment: evaluating whether a plan's assumptions might fail, proposing ways to harden a plan against identified weaknesses, or finding cross-domain analogies that a purely structural approach would miss. And even that model runs locally — a small, specialized model on the same machine, not a cloud API.

3. The footprint had to be tiny

If you're deploying to a laptop a Marine carries in a backpack, you can't require a GPU cluster. Our entire system — the reasoning engine, the knowledge graphs, the local model, everything — runs on standard hardware. No special GPU required. No 64GB of RAM. No enterprise server.

Total deployment footprint: One compiled binary (~8MB), one local model file (~2GB), and the knowledge graph files (~60MB). Under 3GB total. Copy it to a USB drive, plug it into any Windows or Linux machine, and it runs.

That's not a simplified demo version. That's the full system — the same one that analyzes threats, evaluates plans, and produces intelligence assessments. The constraint of air-gapped deployment forced us to be efficient in ways that cloud-first architectures never have to worry about.

What This Looks Like in Practice

Let's make this concrete. Say you're an S2 intelligence officer and you need a threat assessment. In a cloud-first system, you'd type your question, wait for it to hit the API, wait for the model to process, wait for the response to come back. If your connection is slow — or if the cloud provider is having a bad day — you wait longer.

Digital interface showing data analysis and security monitoring
Local analysis means results in milliseconds, not seconds. The difference matters when decisions are time-critical.

In our system, the knowledge graph is already loaded in memory. The graph-only agents traverse the relevant edges in under 25 milliseconds — that's faster than a single frame of video. The specialized agents that need deeper reasoning take about 10 seconds each on a standard laptop GPU. Total time for a full eight-agent analysis: about 30 seconds. Total cost: zero.

And because everything runs locally, there's a complete audit trail. Every finding traces back to a specific node in the knowledge graph. Every recommendation can be explained: "This conclusion was reached by following these edges, through these nodes, in this graph." Try getting that level of explainability from a cloud language model.

The Deployment That Doesn't Need Permission

Here's the part that matters most for government programs: there's nothing to authorize.

No cloud infrastructure means no cloud ATO. No data leaving the machine means no data-in-transit concerns. No external connections means no network security review. No API keys, no subscriptions, no vendor lock-in, no per-query costs that balloon at scale.

The system runs on the hardware you already own. The data stays on the machine it's already on. The model was trained on unclassified doctrine. Your operational data never touches anything that isn't already within your security boundary.

The fastest way to deploy AI in a government environment isn't to fight through the authorization process. It's to build something that doesn't need one.

What We're Building Next

The air-gapped architecture isn't a limitation we work around. It's a design principle that makes everything better — faster, cheaper, more auditable, more deployable. We're now extending this approach to specialized domain models: AI that doesn't just retrieve knowledge but reasons within specific professional disciplines, using the terminology and frameworks that practitioners actually use.

More on that soon.

If you're working on a government program and you're tired of hearing "connect to our cloud" from AI vendors, we should talk. The best AI for defense might be the one that never needs to phone home.

Interested in what we're building?

We're always happy to walk through the architecture with program managers, contracting officers, and technical evaluators.

Start a Conversation