RUNTIMEProduct
Sentinel Runtime
The execution substrate every other capability rests on. It sits in the path of an AI operation, decides whether it may proceed, and writes the record of what happened as the operation happens.
Everything else in the platform reads what the runtime produced. Nothing else can produce it.
Evidence begins where execution begins.
A tool that reads what an AI system did is downstream of the only moment that mattered. The runtime exists to occupy that moment: to be present while the operation is decided, so the decision and the record of it are the same event. Governance here happens at execution time. Auditing happens later, to something that was already governed.
- A tool positioned after execution: Observes
- A runtime positioned inside it: Participates
- A tool positioned after execution: Collects
- A runtime positioned inside it: Creates
- A tool positioned after execution: Analyses logs
- A runtime positioned inside it: Produces evidence
- A tool positioned after execution: Verifies afterwards
- A runtime positioned inside it: Makes execution verifiable from the start
Every capability above it inherits whatever the runtime recorded, and nothing more.
A dashboard cannot show what was never written. An assessment cannot check a record that does not exist. A receipt cannot bind to an operation nobody was present for. This is why the runtime is the first product rather than one of several: it is the only one that can create the material the others read. It is also why the position cannot be taken by a tool built alongside it. Being in the path is not a capability that can be added to something standing outside the path, and everything downstream is a consequence of a decision this component already made.
A participant, not an observer.
In-process
It runs inside the process performing the operation. No sidecar, no agent shipping data somewhere, no remote call to reach a decision. Removing the network does not change its behaviour.
Deterministic
The same operation against the same policy returns the same result, every time. No language model sits in the decision path, so nothing about an outcome is inferred or sampled. The verdict is ALLOW, WARN or BLOCK (ALLOW · WARN · BLOCK), and which one is decided by the adopted policy rather than by a judgement about the work.
Identity-aware
Which agent, which surface, which version. The actor is part of the record rather than something reconstructed from timestamps afterwards, so “who did this” is answered by the record itself.
Local-first
Records are written where the operation happened, in a portable format that outlives the runtime that produced it. The evidence is yours before it is anything else.
- actor
- claude-code-1.0.60
- requested
- write · src/billing/rates.py
- policy
- adopted pack · evaluated
- outcome
- proceeded
- sealed
- 09:20:04.887857
Nothing is reconstructed
There is no pipeline between the operation and the record, because there is no gap for one to cross. No parsing, no correlation, no reconciliation between sources, no second version of what happened.
A refusal is recorded with the same weight as a success. An architecture that only writes down what proceeded cannot tell you what it stopped.
As much as you turn on. No more.
Four levels, each opt-in, each a superset of the one before. Start at the first and stay there indefinitely; move deeper when the reason to do so arrives. Nothing forces the whole depth on day one.
TELEMETRYMetadata onlyNo raw payload is stored at all. Enough to answer whether an operation was permitted and what happened, for every operation that passed through.
OPERATIONALDiffs and tool IO metadataAdds what changed and what the tools were asked for, so a reader can see what was attempted rather than only what executed.
DEEP_CAPTUREPrompts and full IO · explicit opt-inAdds the environment the decision was made in, which is what makes a result reproducible rather than merely repeatable.
FORENSICEncrypted and signed · explicit opt-inThe depth an external assessment expects. Chosen deliberately, by an organisation that has a reason for it.
A level that was never enabled produces no record, and a reader asking about it is told nothing could look, not that nothing was wrong. Absence returns as absence. Shallow capture is an honest configuration; it is never quietly reported as approval.
One command, then it is in the path.
The runtime installs into an editor as an MCP server. There is no cluster to stand up, no pipeline to build, no separate store to operate and no specialist to hire before the first governed operation exists.
Claude Code
python scripts/install_claude_mcp.py
Cursor
python scripts/install_cursor_mcp.py
copilotPlanned, and not built yet: PLANNEDGitHub Copilot
codex-cliPlanned, and not built yet: PLANNEDOpenAI Codex CLI
gemini-cliPlanned, and not built yet: PLANNEDGemini CLI
windsurfPlanned, and not built yet: PLANNEDWindsurf
The four above are declared in scg/integrations/reference.py as reference adapters: identity and capability metadata, explicitly non-functional, with no IDE dependency, no network call and no code execution. That is exactly what PLANNED means here · declared and not built. No install path exists for them, and this page will not name one until it does. Editors the repository declares nothing about are not listed at all.
The runtime is editor-agnostic
It speaks MCP; editors are clients. The two that install are the first two we install and test, not the two it depends on. An editor that speaks the same protocol fits the same architecture, and none is named here before that is true.
More governance without more setup
The claim is architectural, not a promise about effort. One runtime means there is no second system to run, so depth increases by enabling a level rather than by building infrastructure.
What the runtime does not do.
Nothing here is a download. Three surfaces install across the whole platform · the MCP server, the vai command line and the browser extension · and two editors install today.
No severity is produced, so nothing orders one record above another. Records are read in the order they occurred.
Whether an operation was permitted is a policy question. Whether it was a good idea is not one the runtime answers.
Nothing is written to a time series, so no improvement or decline across a period is available from it.
It evaluates the operations that pass through it against the policy that was adopted. Work that bypasses the runtime is not evaluated, and its absence is reported as absence rather than as approval.
VerifAIer Me governs assistants that act for a person and is a separate product with a separate surface, not a consumer edition of this one.
A runtime is the one component that cannot be added later.
Everything else in the platform can be adopted in any order, at any time, by reading what already exists. This is the piece that has to be present first, because it is the piece that was there when it happened.