One architecture, two deployment pathways
This is VaHive Systems Lab’s governance architecture — the specification behind the preprints under The Lab, extended into an implementable design. There are two specification series because there are two genuinely different problems, and the thing that separates them is not who the operator is. It is where the model runs.
When the model is a remote service, the boundary between model and governance is the API call. That boundary is structured, auditable and controllable, and it comes for free.
When the model runs on the operator’s own hardware, that boundary does not exist by default. The weights are files on disk. The inference process shares an operating system with everything governing it. Without deliberate isolation, a model process does not need to attack through the governed channel; it can simply go around it: read the token store, truncate the append-only record, read the signing key out of another process’s memory. None of that requires a sophisticated attack. It requires access.
That single difference generates every other difference between the two pathways. One specification covering both would be dishonest, so VSL developed two, as peers.
The shared foundation.
Both pathways inherit the same core, and most of the architecture lives here.
- A deterministic enforcement layer — fixed, code-level rules, with no neural computation anywhere in the decision
- An evaluator with structurally zero execution rights, separated by routing rather than by policy
- An append-only, hash-chained governance record, sealed before a change takes effect
- Epistemic control — confidence derived from the model’s own output distribution, not from what it claims about itself, with drift measured as a gradient rather than a threshold
- A memory graph with explicit human anchoring signals and a contamination guard
- An agent hierarchy where authority is structural, not linguistic — an agent cannot talk its way into a permission it was not given
- A stress-test harness that exists to attack the governance layer itself
How they were hardened.
The method is the same one VaHive Systems Lab applies to its code: publish, red-team, register every issue by name, close them, bump the version, repeat.
v3.0 was published in March 2026. Successive rounds hardened both series — candidate designs analysed and rejected with their failure modes recorded, and at least one issue reclassified upward in severity when review showed it had been underrated. That work is converging now on v3.5.
The register is the point. An architecture nobody has attacked has an unknown number of holes.
Magus Local.
The model runs on the operator’s hardware, beside the thing governing it. Everything in the shared foundation, plus the machinery required when the thing being governed sits on the same machine as the thing governing it:
- Mandatory process isolation, stated as a compliance boundary rather than a recommendation — an implementation that does not meet it is not MAGUS-compliant, and none of the governance claims apply to it
- Cryptographic boot binding and a runtime attestation guard
- Governed model-weight loading — the enforcement layer opens the weights, verifies them, and passes a file descriptor, so the model process never resolves the path itself
- A recovery architecture — state journal, host sentinel, and a global state transition matrix, because a crash must not become an opportunity
Magus Agent API.
The model is a remote API; the boundary already exists, so the work moves to what crosses it. Injection is the primary threat here, and it operates through the governed channel rather than around it, which means the channel is where governance concentrates:
- Containment for external content, with untrusted material structurally unable to acquire authority
- Session boundaries defined explicitly, including what must be re-established when one opens
- Long-horizon drift detection anchored against a genesis state, so slow deviation is visible without a single failure event to point at
- Provenance on proposals, so an action can be traced to what actually caused it
What v3.5 adds.
v3.5 is an extension of v3.0, not a revision — every sealed invariant holds. Two additions are worth naming because they are unusual.
Trajectory verification. v3.0 evaluated model certainty as a point-in-time measurement, which left it blind to a slow slide that never breaches the ceiling on any single step. v3.5 accumulates that strain across a generation sequence, so a degrading trajectory is caught before it arrives rather than after.
Governance of the operator, not only the agent. If the agent is an employee, the supervisor’s attention is also a variable, and it degrades. v3.5 measures that degradation and surfaces it. It does not act on it: the system may detect, signal, escalate and restrict, but it may never automatically correct for operator behaviour without explicit acknowledgment. Human intent stays the terminal authority.
Want to talk about applying this to your own system?
VSL never faces a customer — this page is research, published to be checked, not a sales surface. Virasai’s own Secure engagements are built on these same deterministic principles, applied to a real, deployed system.