Introducing Forge: The Secure, Air-Gapped Copilot for Defense Engineering

Defense and government engineering teams have spent the last several years watching the rest of the software industry adopt AI coding assistants as a default part of the job, and watching themselves sit it out. Not from lack of interest. The productivity case is not in serious dispute. It's that every credible option on the market is built on the same assumption: that the assistant earns its usefulness by sending your code somewhere else. A model that has never seen your repository cannot meaningfully help write the next function in it. A model that has seen your repository, in the cloud-assistant model, means your repository left the building.

For a team working on classified, export-controlled, or otherwise walled-off source, that is not a tradeoff to negotiate. It is a disqualifying property. Forge exists because the underlying need, a coding assistant that actually understands your codebase, does not go away just because the usual way of delivering it is off the table. It answers the same question the rest of the industry answers with a cloud API, but it answers it entirely inside the boundary.

What Forge is

Forge is a sealed hardware appliance that runs a code-aware AI assistant against your own repositories, on your own premises, with no outbound network path to any vendor infrastructure. It is built for the specific case where source code cannot leave a defined boundary, an enclave, a SCIF, a contractor facility operating under program-specific data-handling rules, and where "we trust the vendor's data policy" is not an acceptable substitute for "there is no connection over which the policy would even apply."

Functionally, engineers interact with Forge the way they would interact with any other internal development tool: inline completions, chat-style question answering against the codebase, review assistance, documentation generation. The experience is deliberately unremarkable. What is different is everything underneath it. The model, the repository index, and the retrieval layer all run on hardware sitting inside your network segment, and the appliance has no destination outside it to send anything to, even accidentally, even under a misconfiguration. The security property is not a setting someone could turn off. It is a fact about what the hardware is physically capable of.

Repo-aware, not just code-aware

A useful coding assistant is not a generic model that happens to output code. It knows the specific codebase in front of it: the internal libraries, the conventions the team already settled on, the parts of the architecture that are load-bearing and the parts that are legacy scaffolding nobody wants touched. That context normally comes from an indexing step, and the indexing step is exactly where a cloud tool's data-handling story gets complicated, because building a useful index usually means shipping a meaningful slice of the repository somewhere to build it.

Forge does that indexing locally, inside the boundary, before or during onboarding, and keeps the index current as commits land, without any of that traffic crossing the edge of the network it lives on. The practical effect is a code assistant that can reason about how a change in one module ripples through another, or point to the existing internal utility instead of reinventing it, using the same repository context a cloud tool would use, just without the round trip. From the engineer's chair, the assistant feels like it has actually read the codebase. It has, and nowhere else has.

Built for how defense engineering actually connects

Cloud AI tools assume a standing, well-behaved internet connection, because that is the substrate their whole architecture is built on. Defense and government engineering environments rarely offer one. A program might run out of a fixed lab with strict egress controls, a field site that relocates with the unit it supports, or a facility where connectivity to the outside is a scheduled, supervised event rather than a background assumption. A tool that quietly assumes reachback breaks in exactly the environments where the engineering work matters most.

Forge is provisioned as a sealed, self-contained unit precisely so it does not carry that assumption. The model and the software stack ship configured and indexed against the intended repositories before the appliance goes into service, and from that point forward the appliance does not need an open connection to function. It needs the LAN it already sits on. That makes it suited to the same range of physical postures the rest of the Element 31 line is built for: a steady-state facility today, a relocating team next quarter, a site with no maintenance reachback at all.

The integrity story a security review actually wants

A cloud vendor's answer to "where does my code go" is ultimately a policy commitment: a data processing agreement, a promise about retention, a claim about what the vendor's own engineers can and cannot see. Those commitments can be sincere and still be the wrong artifact for a program security review, because a policy is revisable, and a breach is discovered after the fact if it is discovered at all. What a reviewer actually wants is a property of the system that holds regardless of anyone's intentions this quarter.

That is the property Forge is built to hand over. The enclosure is tamper-evident, so physical access to the unit is itself detectable. The software image is signed, and the appliance continuously verifies its own running state against that signature rather than trusting that nothing has quietly changed since installation. And the appliance keeps its own record of what it has been running and when that changed, so a reviewer months later is not relying on anyone's memory or a vendor's server logs. The evidence lives on the unit itself. None of that replaces a security review. It gives the review something concrete to check instead of a policy document to take on faith.

Where Forge sits in the Element 31 line

Forge is purpose-built for one job: AI-assisted software engineering against a codebase that cannot leave its boundary. It shares its underlying platform (memory, retrieval, integrity verification, governed connectivity) with the rest of the Element 31 line, but it is not the whole line. Czar addresses a different problem: training and fine-tuning models against sensitive data, for programs whose need is building or adapting a model rather than getting help writing code against one that already exists. Chassis is a different kind of offering entirely: bespoke, per-deal hardware manufacturing for independent software vendors who need to ship their own existing product as a sealed on-prem appliance, scoped to a specific buyer and workload rather than sold as a standing catalog tier.

For a defense engineering team, the relevant comparison is narrower and more concrete: a coding assistant that behaves like the rest of the industry's tools from the engineer's seat, and behaves like an internal, boundary-respecting service from the security team's seat. Forge is built to be evaluated on both counts at once, because a tool that only satisfies one of them was never going to get past onboarding in this kind of environment anyway.