Local inference
Models execute on customer-controlled compute sized to the mission, latency target, and available power envelope.
Private AI inside the mission boundary
Useful AI when the internet is unavailable—or prohibited.
Mimir is an air-gap-capable AI reference appliance designed to keep retrieval, reranking, model inference, and approved mission knowledge local. In a configured topology, it gives teams source-cited support without making the core answer path dependent on a commercial cloud connection.
Air gap is an operating model
Offline inference is only one part of a disconnected system.
A credible air-gapped deployment must account for models, containers, operating-system content, identity, time, logging, licensing, knowledge updates, support, and recovery—not merely run a local language model. Mimir’s reference design accounts for that complete operational boundary.
01 / Local operation
The answer path stays on the local node.
A user submits a question to Mimir inside the customer network. The system retrieves relevant passages from approved knowledge packs, reranks those passages, sends the selected context to a locally hosted model, and returns an answer with source references. The core path does not require a public model endpoint.
This local design supports air-gapped sites as well as denied, degraded, intermittent, and limited-bandwidth environments. It also helps organizations that maintain connectivity but cannot move sensitive operational knowledge into a multi-tenant cloud service.
Local retrieval
Indexes, embeddings, reranking, and citations remain with the approved source library inside the boundary.
Local administration
Knowledge-pack lifecycle, access, and operational evidence are managed without a dependency on a public control plane.
Human authority
Mimir reduces search burden; the operator retains responsibility for interpretation, verification, and action.
Air-gap capability depends on the final bill of materials and configuration. During delivery, outbound dependencies, license behavior, support tools, and update sources are documented and tested against the selected boundary.
02 / Sovereign data
Mission owners decide what enters, who can use it, and when it changes.
Data sovereignty is more than a storage location. It means the mission owner controls the source documents, indexes, model artifacts, logs, identities, retention policy, and transfer process. Mimir is designed so those elements can remain in an environment governed by the customer rather than a commercial AI provider.
Knowledge packs create a deliberate publishing boundary. Administrators select approved manuals, doctrine, SOPs, technical orders, and local references; version the collection; and make it available to the appropriate users. A response can then point back to the material used, improving traceability without pretending that a citation guarantees correctness.
Approved sources
Customer-selected material becomes the retrieval corpus; the open web is not silently mixed into answers.
Defined retention
Logs, uploaded sources, indexes, and generated answers can follow the site’s storage and retention decisions.
No shared-model training
The deployment pattern does not require submitting customer content to train a shared public model.
Inspectable answers
Users can compare output with cited passages and the current governing publication before acting.
03 / Disconnected lifecycle
The update path is designed before the network disappears.
Disconnected systems still need security updates, new models, refreshed containers, revised manuals, configuration changes, backups, and technical support. Mimir’s deployment plan identifies the connected preparation environment, transfer media or cross-domain process, integrity checks, approval gates, rollback material, and the record retained for each release.
Knowledge can move on a different cadence from the platform. A mission owner may publish a revised knowledge pack without changing the model or application, while a larger software update moves through additional testing and authorization. Separating those lifecycles keeps routine content maintenance deliberate and auditable.
Stage and verify
Artifacts are collected from approved sources, inventoried, scanned as required, and verified before transfer.
Approve and import
The customer’s authorized process governs what crosses the boundary and who accepts it on the destination side.
Record and recover
Versions, checksums, exceptions, configuration changes, and rollback inputs are retained with the release record.
Support without telemetry
Diagnostic evidence can be collected intentionally rather than requiring persistent vendor access or outbound telemetry.
Continue the mission thread
See how the pieces work together.
Related capability
Defense RAG
See how approved sources, retrieval, reranking, citations, and operator verification form the answer path.
Related capability
Security baseline
Examine the RHEL foundation, STIG-aligned hardening process, evidence, and scoped PQC capability.
Related capability
Expeditionary edge
Explore a notional compact OpenShift and PacStar-class pattern for forward Army and Marine units.
Plan the deployment
Bring the mission and the constraints. We’ll map the system to both.
A Mimir briefing covers the operating boundary, approved knowledge, deployment pattern, security evidence, and the people the system is intended to support.