One architecture, two deployment pathways
There are two specification series because there are two genuinely different problems, and the thing that separates them is not who you are. 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 you get it for free.
When the model runs on your 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. Pretending one specification covered both would be dishonest, so there are two, developed 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 applied to the 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 your 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.
Talk about your actual system.
If one of these describes your situation, the useful next step is a conversation about your actual system — what it does, what it touches, and what happens when it goes wrong.