Approved inputs
The mission owner determines which sources, revisions, markings, and metadata may enter each pack.
A local source-to-answer system
One controlled path from approved knowledge to an inspectable answer.
Mimir’s reference architecture combines a RHEL 9 and Podman deployment baseline, a governed document pipeline, hybrid retrieval, a local model runtime, application services, and operator-facing citations. Components can run together on one node or be separated across local tiers when scale and mission architecture require it.
Reference architecture
The mission boundary—not a generic diagram—determines the final system.
Compute, model size, storage, identity, availability, network segmentation, transfer mechanisms, logging, backup, environmental requirements, and security controls are selected for each deployment. The architecture below describes the Mimir pattern, not a claim that every topology is already field-validated.
01 / Knowledge plane
Prepare approved source material as a governed release.
Administrators organize manuals, technical orders, SOPs, doctrine, policy, and local references into a knowledge pack. The ingestion pipeline extracts text and metadata, creates searchable chunks, generates local embeddings, and stores both retrieval data and source relationships inside the selected boundary.
A pack should be treated as a release artifact, not an unreviewed folder dump. Content ownership, revision state, source provenance, access, quality checks, and test questions are defined before promotion. This makes the knowledge lifecycle understandable even when the system is disconnected from enterprise content services.
Local processing
Parsing, chunking, embeddings, and indexing can operate using services staged inside the boundary.
Versioned packs
Knowledge changes can be reviewed and promoted independently from the application and model runtime.
Release checks
Representative queries, source coverage, citation behavior, and document metadata are checked before acceptance.
02 / Answer plane
Retrieve evidence before asking the local model to synthesize.
An authenticated user selects an available knowledge pack and submits a question. Mimir retrieves candidate passages using semantic and lexical signals, reranks those candidates, and constructs bounded context for the selected local model. The application then streams a response and exposes source evidence for review.
This pipeline is intended to reduce dependence on model memory. It does not eliminate retrieval misses or model error, so the interface and operating concept keep citations, uncertainty, abstention, and human verification visible. For technical or operational use, the current approved publication remains authoritative.
Application service
Handles identity, roles, team scope, pack selection, session behavior, and response presentation.
Retrieval services
Relational and vector stores support content metadata, search, relevance, and source relationships.
Local model service
A deployment-approved runtime provides embeddings, reranking, and generation without required public APIs.
Evidence surface
Knowledge answers are designed to expose citations that users can inspect against the source material.
03 / Deployment plane
Scale the topology without hiding its dependencies.
A compact pilot may colocate the application and model stack on a single local node. A larger deployment can separate the application tier from accelerator-backed model serving while keeping both inside the local boundary. The design records required local DNS, time, certificates, identity, storage, ports, health checks, and recovery dependencies.
Disconnected release operations use staged artifacts rather than live registries and package repositories. Models, containers, operating-system content, knowledge packs, configuration, and integrity records cross the boundary through an approved process. Diagnostic evidence can be exported intentionally for support without requiring persistent vendor access.
Single-node pilot
A compact reference pattern reduces integration overhead for controlled evaluation and lower-demand workloads.
Split local tiers
Application and model services can use separate compute while communicating only across an approved local network.
Compact OpenShift concept
Mimir can be evaluated alongside a three-node compact cluster; the exact pattern requires platform validation.
Disconnected release chain
Inventories, checksums, approval, import, validation, rollback, and release records are part of the operating design.
The current PacStar-class and compact OpenShift material is a notional deployment concept. It has not been validated on PacStar hardware and does not imply Curtiss-Wright endorsement or certification.
Continue the mission thread
See how the pieces work together.
Related capability
Defense RAG
Go deeper on governed knowledge, local retrieval, citations, abstention, and evaluation.
Related capability
Security baseline
Review the RHEL foundation, deployment-specific hardening, STIG tailoring, and PQC enablement path.
Related capability
Expeditionary concept
See the notional PacStar-class and compact OpenShift deployment pattern for forward 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.