Reference architecture
The enclave and the gate
A multimodal model harness for an R1 research campus: everything the university cannot afford to export runs inside a closed network, and there is exactly one governed path out to a frontier model.
What the harness is
A harness is not a model. It is everything around the model that turns a heterogeneous request into a governed answer.
A university does not send tidy paragraphs to an LLM. It sends a 340 page grant package, a stack of pathology slides, a two hour lecture recording, a decade of instrument telemetry, and a question that touches all four. The multimodal harness is the layer that accepts that, splits it by modality, encodes each piece, decides which model slot should see it, retrieves what is relevant, runs the call, and records what happened.
On a research campus the harness carries a second job that a commercial deployment does not. Every one of those inputs arrives with a compliance status attached. A slide from the medical center is PHI. A dataset from a Department of Defense subcontract is controlled unclassified information. A transcript is a student record. The harness has to know which is which before it decides where the bytes are allowed to go, and it has to be able to prove afterward that it got the decision right.
That requirement is what produces the two zone layout below. It is not a security wrapper bolted onto an AI system. The classification decision is the first thing the harness does and the last thing it logs.
Figure 1 / Campus layout
The two zones, and why they are not symmetric
It is tempting to draw this as two peer networks with a firewall between them. That is the wrong mental model and it produces the wrong build.
Inside
The sovereign enclave
- No default route. Not a filtered route. No route. Package mirrors, model weights, and license servers are staged in, not pulled down.
- Weights are resident. The general slot runs a post-trained OLMo 3, so the campus holds the actual weights rather than renting an endpoint, and the base itself is a fully open release it can audit.
- The restricted index lives here and only here. Clinical, controlled, and student data are embedded and searched without ever leaving the boundary.
- Full tool authority. Models inside can call campus systems, write to stores, and drive agents, because everything they touched was already inside.
Outside
The frontier broker
- It is a container, not a network. One workload with one job. It holds the egress route so that nothing else has to.
- It never sees restricted content. Everything it receives has already passed the redaction stage, so a compromise leaks placeholders.
- It cannot initiate. The enclave polls for results. The broker has no inbound path, which means an attacker who owns it still cannot reach in.
- Its output is untrusted by default. A frontier answer is text to be checked, never an instruction to be executed.
That last point is the one people skip, and it is the one that matters most in practice. If a frontier model is allowed to return a tool call that the enclave then runs, the gate is decorative. Any content that reached the frontier model, including a poisoned PDF pulled from the open index, becomes a way to steer actions inside the closed network. So the rule is structural rather than procedural: a response that came from outside can inform an answer, and it can never take an action.
What a slot is
A slot is a named routing target, not a model.
Every module in the platform asks for savrn-local-general. None of them knows a vendor, a file path, or a checkpoint. That indirection is the whole reason a model can be retrained, requantized, replaced, or rolled back without a single caller changing. It is also what makes the audit record mean something: the ledger names the slot and the attested artifact that filled it at that moment, so a claim about what produced a given deliverable stays checkable after the fact.
A slot declares seven things. One that cannot declare all seven does not serve traffic.
- A routing identifier. The only name a caller ever uses.
- Base weights pinned to an upstream revision. A commit, never a branch. A SHA-256 manifest is verified at load, and a mismatch quarantines the artifact rather than serving it.
- The adaptation applied, and the data it came from. For the general slot that is a full post-training pass, SFT then DPO then RLVR, over accepted campus deliverables. A stock slot declares none, which is also a real answer.
- Quantization and serving runtime, both pinned by build. The runtime version is part of the model's identity, because it changes the output.
- A decoding policy set by purpose, not by the caller. Temperature, top_k, top_p, min_p, and seed are governed values with a stated precedence.
- A held-out evaluation score, and the incumbent it has to beat. Promotion is a gate, not a deploy.
- A rollback that someone has actually run.
Why the fifth one is on the list
SAVRN shipped a gateway that quietly discarded every sampler field except temperature. Nothing errored, so nothing surfaced. The consequence was that top_k, top_p, min_p, and seed were coming from the inference runtime's defaults, which means the decoding policy behind every governed deliverable belonged to llama.cpp rather than to anyone who had approved it.
The fix was to forward the fields and make precedence explicit: governed purpose policy first, then an approved evaluation override, then a conservative model default, with unsupported parameters rejected out loud instead of dropped. A stack that cannot say which sampler produced a given answer is not yet sovereign over its own output, whatever the network diagram says.
The slots
| Slot | What fills it | Adaptation | What it serves |
|---|---|---|---|
| savrn-local-general | Ai2 OLMo 3.1-32B-Instruct, fully open release at a pinned revision | Post-trained on domain data: SFT, DPO, RLVR | Long-form reasoning, drafting, and synthesis over retrieved context |
| savrn-local-coding | Qwen 3.8-27B | Stock | Code, schema work, query generation, refactors |
| savrn-local-utility | Qwen 3.5-9B | Stock | Classification, extraction, routing, and short summarization at high concurrency |
| savrn-local-vision | Open-weight vision language model, selected with the campus | Stock at first, LoRA once the real page-type mix is known | Figures, scans, slides, forms, whiteboards, instrument screens |
| savrn-local-speech | A recognition and synthesis pair | Stock, plus a campus lexicon for domain vocabulary | Lecture capture, clinical dictation, transcript alignment |
| savrn-local-embed | Qwen3-Embedding-0.6B | Stock | Retrieval vectors for both indexes |
| savrn-domain-* | Weights the campus brings | Owned by the lab that trained it | Whatever that department built it for, under its own tenancy |
Multimodal is slot composition
Multimodal does not mean one model that does everything. It means several slots, a router that knows which to call, and an embedding space where their outputs can meet. A scanned protocol page goes to the vision slot for layout and figure content, the text pulled off that page goes to the general slot, and both are anchored by vectors from the embedding slot, so the retrieved context and the generated answer are demonstrably about the same document. The researcher asks one question. The harness is the thing that turns it into one answer.
The base, and what SAVRN did to it
SAVRN builds on Ai2's OLMo 3, a fully open release: published weights, published training data, published training code, and published intermediate checkpoints, under Apache 2.0. That is a stronger position than open weights alone, and on a research campus the difference carries load. Open weights let you run a model. A fully open release lets you answer where its behavior came from, which is the question an IRB, an export control officer, or a reviewer of a published result will actually ask.
SAVRN post-trained OLMo 3 on its own domain data using the OLMo 3 model flow: supervised fine-tuning, then direct preference optimization, then reinforcement learning with verifiable rewards. Evaluation runs against a SAVRN-authored held-out set with a paired assertion-level instrument. That post-trained model is what runs the SAVRN platform today.
The brief says post-trained rather than fine-tuned on purpose. Fine-tuning is one stage of three, and the shorter word understates the work. What SAVRN owns is the post-training flow, the evaluation instrument, and the domain data that goes through them. It does not pretrain a foundation model, and that distinction is worth stating plainly rather than leaving a product name to imply otherwise.
The fork, and why a campus should care
SAVRN is preparing to fork the OLMo 3 lineage into its own model line, with SAVRN-defined naming, versioning, evaluation, and release cadence, no longer tracking upstream OLMo 3 releases. Apache 2.0 permits this explicitly, and it is the ordinary path for a permissively licensed lineage: Llama 2 to Vicuna, Mistral to Zephyr, Qwen to Nous.
For a university this is a procurement question rather than a branding one. An institution that has certified a model slot for clinical or controlled work cannot have the base shift underneath it on someone else's schedule. A fork is what converts "the model may change when upstream ships" into a release cadence the campus can plan revalidation around, and it is what makes the promotion gate in the slot contract enforceable across versions instead of only within one.
On runtime
The serving stack is a property of the target, not of the slot. A campus GPU pool runs a paged-attention server over GPTQ or FP8 weights. SAVRN's own reference implementation runs llama.cpp with Q5_K_M GGUF at a pinned commit, which is the right choice on Apple silicon and the wrong one on an H200 rack. The slot contract does not change between them, and that is the point of having one.
What happens to one request
The interesting case is not the request that stays inside. It is the one where a researcher wants frontier reasoning applied to work that cannot be exported.
Figure 2 / Request path
The index splits the same way the network does
Retrieval is where most sovereign designs quietly fail. A team builds one index over everything, points both the local and the frontier path at it, and has now created an exfiltration channel that no firewall rule will catch, because the leak travels inside a legitimate prompt.
Two indexes, one gate. The line between them is the same classification line that governs the network.
Figure 3 / Split retrieval
Where each class of data may go
This matrix is the default the harness ships with. The campus compliance offices own the final version, and the harness enforces whatever they set.
| Data class | Sovereign models | Sovereign index | Frontier release | Condition set at ingest |
|---|---|---|---|---|
| Published and open | yes | yes | yes | None. This is the default path. |
| De-identified research | yes | yes | conditional | Release only after the IRB de-identification standard is confirmed for that dataset. |
| FERPA student records | yes | yes | no | No release path by default. Consent, if the registrar allows it, is per student and per purpose. |
| PHI, clinical | yes | yes | no | Enclave only. A crossing attempt is treated as an incident, not a policy exception. |
| CUI under NIST 800-171 | yes | yes | no | Enclave only. The enclave is the boundary described in the system security plan. |
| Export controlled, ITAR and EAR | yes | yes | no | Enclave only, and the deemed export question also governs which people may query it at all. |
| Industry sponsored under NDA | yes | yes | sponsor decides | Flag carried from the agreement. Default closed until the sponsor says otherwise in writing. |
| Campus operations | yes | yes | conditional | Facility telemetry may release. Anything that identifies a person or a secured space may not. |
This is an engineering default, not legal advice. The value of putting it in the harness is that the answer becomes machine enforced and auditable rather than a paragraph in a policy document that nobody can prove was followed.
Landing it in the data center
The harness is software, but it only works if the physical and network layout underneath it agrees with the design. Four things have to be true on day one.
Power and space
The deployment unit is one Atom block at 13.2 MW, which is where a campus starts rather than where it ends. An R1 that is standing up inference for the medical center, the engineering college, and a teaching workload does not need a full site to begin, and the block is the increment that lets the university add capacity against demand it can actually observe instead of demand it forecast.
Network
The enclave gets its own routing domain with no default route and no NAT to the outside. The broker sits in a separate DMZ domain that holds the single egress path, through a forward proxy with an explicit allow-list, terminated TLS, request rate limits, and a hard spend cap. The gate is the only adjacency between the two, and the connection direction is one way: the enclave reaches out to the broker, the broker never reaches in.
Identity
Authentication federates from campus SSO so the harness never holds a credential. What the harness does hold is the attribute set that follows the person: department, role, training completion, export control status, and the grants they are named on. Those attributes are what the gate evaluates, which means a policy change in the identity system takes effect at the gate without a code change.
Scheduling
Interactive inference and batch training want the same GPUs at the same time, and the university already has a scheduler with its own political history. The workable split is a reserved interactive pool that the harness owns outright, a batch pool that stays under Slurm, and a documented arbitration rule for the boundary between them. Getting that rule written down before the first grant deadline is worth more than any amount of capacity planning after it.
What already runs, and what is new
Worth separating, because the credibility of this design rests on the parts that are not hypothetical.
Running today in SAVRN
- The single choke point. Every model call in the platform goes through one gateway on loopback. No module imports a vendor SDK directly, so gateway policy is platform policy.
- Fail closed by default. The gateway runs local only. An external provider is refused unless it has been explicitly allow-listed, and the refusal is the default rather than the exception.
- The no-tools rule. The one sanctioned external lane is permitted only when the purpose is evaluation and the request carries no tools. The same call with tools attached is refused on the same provider.
- Resident model slots. A general slot running a post-trained OLMo 3, plus coding and utility slots, served from weights held locally.
- The ledger. Calls are recorded and reconciled, and the record is what gets audited when a number looks wrong.
New for a campus deployment
- Classification at ingest. Today the platform knows which tenant a call belongs to. A campus needs it to know which compliance regime the bytes fall under, applied at the source.
- Redaction and rehydration. The reversible entity map, and the discipline that it never crosses the boundary.
- The split index. Two retrieval corpora with a replication rule between them, rather than one index serving both sides.
- Campus identity and attributes. Federated SSO with the attribute set that drives the gate decision.
- Per-grant accounting. Tokens metered against departments and grant codes, because that is the unit the university has to report on.
Questions the campus has to answer
These are the ones that change the build. Better to settle them before the racks land than after.
- Who owns the release decision? A policy engine alone is fast and consistent. A named human in the loop for certain classes is slower and more defensible. Most campuses will want the engine for routine classes and a person for the sensitive ones, and the harness should support both without a redesign.
- Does the medical center ever get a release path? If the answer is no, say so now and design the clinical workload as enclave only. Half-committing to that answer is what produces the architecture that leaks.
- Where does the placeholder map live, and who can read it? It is the most sensitive object in the system, because it is the key that turns released text back into identified data.
- Is a frontier API call a deemed export? Get the export control office's written position before the first call, not after. This is a question with a real answer and a real audit trail attached to it.
- What bar does a model slot clear before it serves clinical or coursework traffic? Held-out evaluation sets, a promotion gate, and a rollback that someone has actually run.
- Who arbitrates GPUs at three in the morning before a submission deadline? Write the rule down while everyone is calm.