Research · Substrate · v1.0

An inspectable
substrate for AI
governance.

On why the governance layer for agentic systems needs to be a primitive, not a product, and what it means to release one.

Published 23 · 04 · 2026
Reading time 14 minutes
Artifact vella-substrate · v1.0.0
License MIT
00 / Opening

The question that keeps returning.

The question that keeps returning in conversations about AI safety is not whether models can be made safer. It is what happens when the model is safe enough and the system around it is still doing things no one authorized.

A model that refuses to help a user write malware is not the same as a system that prevents the agent it powers from issuing an unauthorized API call. A constitutional AI that declines to generate harmful content is not the same as a governance layer that stops the agent from deleting a production database because an intermediate reasoning step concluded the database was "stale." These are distinct properties of distinct layers. We tend to conflate them because the outputs are surface-similar: the bad thing did not happen. But the mechanisms are structurally different, and one of them has received enormous investment while the other has received almost none.

The layer that has received almost none is the one this essay is about.

It is the layer that answers: for this specific proposed action, right now, under the policy that applies, is the agent authorized to proceed? Not "is the model aligned?" Not "does this text look safe?" Not "will the permissions system allow this API call?" The narrower question: is the evidence for taking this action, at this moment, present and sufficient, and can we produce a record that says so?

We have built a substrate that adjudicates exactly that question, and today we are releasing it under an MIT license for anyone to inspect, run, cite, and extend.
01 / The problem this names

A category error at the heart of the stack.

Most AI governance work, whether in academic literature or in industry practice, collapses a few different things into a single concept. Consider the standard layering:

Fig. 01 The four-layer stack — and the seam it hides
Layer
What it governs
How it is implemented
Model alignment
Layer · 01
The model's internal disposition
RLHF · Constitutional AI · Red-teaming
Input safety
Layer · 02
What the model is asked to do
Prompt filters · Content classifiers
Permission systems
Layer · 03
What resources an agent can access
IAM · OAuth scopes · API keys
Post-hoc observation
Layer · 04
What happened, after the fact
Logs · Dashboards · Audit trails
Governance substrate
Missing · 00
Per-action authority, pre-execution
Deterministic adjudication · Signed evidence
Claim
None of the first four answer the narrower question. The fifth is what we built.

These four layers are real, important, and actively worked on. None of them answer the question we care about here. Let me walk through why.

Model alignment is about disposition. A well-aligned model is more likely, in distribution, to behave well. It is not a commitment that any specific action will or will not execute. A fully aligned model in an agentic loop can still, through a chain of perfectly well-intentioned reasoning steps, arrive at a proposed action that is unauthorized given the broader context. It can execute that action, because there is nothing in the alignment layer that enforces per-action authority.

Input safety is about the request going in. It has nothing to say about what the agent decides to do mid-execution, when a tool call is proposed that the user never explicitly asked for. Agentic systems by design generate actions that were not in the original prompt; filtering the prompt does not cover what happens downstream.

Permission systems authorize access to resources. They are agnostic to intent. An agent with valid API credentials to a production database has the same permission to query that database whether the query is part of an authorized maintenance task or part of an unsanctioned exfiltration. The permission system cannot tell the difference because it was never designed to.

Post-hoc observation is not governance. Logs are evidence that something happened. They are the material from which an auditor reconstructs the event. They do not prevent the event, and they do not bind the actor to the consequences of having ignored a constraint that was never made explicit in the first place.

What's missing, across all four of these, is something that sits between intent and execution, in the moment when an action has been proposed but has not yet happened, and adjudicates. Something that says yes, given this intent, this evidence, and this policy, the action is authorized; proceed and here is a signed record. Or no, it is not authorized; halt, and here is a signed record of why.

We call this primitive a governance substrate. The word substrate is deliberate. It is not a product, it is not a framework, it is not a library competing with other libraries in a crowded category. It is a foundational layer that other things sit on top of. Nothing in the standard four-layer stack provides it. It has to be built separately and called at the right point in the action lifecycle.

02 / What we built, concretely

VELLA. Each word load-bearing.

VELLA, the Verifiable Evidence Ledger and Logic Authority, is our name for this substrate. Each word in the expansion is load-bearing. Verifiable because every decision produces a cryptographically signed record anyone can check. Evidence because decisions are bound to the evidence that justified them, not taken on policy alone. Ledger because the signed records compose into an append-only history of governed actions. Logic Authority because the decisions are made by a deterministic function, not a heuristic or a learned scorer.

The implementation published today is the embedded SDK: a library you import into your Node.js or Python application, call with a proposed intent and supporting evidence, and receive back a binding decision along with a cryptographically signed proof record.

Four properties define the substrate. They are individually unremarkable. The combination is the point.

Property · 01

It is deterministic.

Given the same intent, the same evidence, and the same policy, the SDK returns the same decision. There is no model call in the decision path. No heuristic, no scoring function, no temperature parameter, no learned component. The evaluator is a pure function over structured inputs — two calls with identical inputs, from different machines, in different languages, in different decades, produce identical outputs.

Property · 02

It is pre-execution.

The adjudication happens after the agent has formed an intent but before the action is enacted. Not after, as a log would. Not during, as an interlock might. Before. The calling system commits to halting on DENIED. This timing is the structural property from which audit semantics and legal attribution flow.

Property · 03

It is evidence-bound.

The decision is made against policy and an explicit evidence mask describing which classes of evidence the calling system has established: authentication, authorization, freshness, attestation, and any custom bits a policy requires. If the evidence is absent, the decision is DENIED. If asserted but false, that falsehood is bound into the signed record.

Property · 04

It is non-executing.

The substrate cannot take any action. It has no actuation interface: no file writes, no network calls, no side effects beyond the decision and the signed record. This is not a policy choice; it is an architectural property. The surface area simply does not exist. Enforcement is the calling system's responsibility, and that asymmetry matters.

Fig. 02 Where the adjudication lives in the action lifecycle
Request
Model output
Intent formed
Vella
adjudicate
Enactment
Audit log

Not after. Not during. Before.
The seam between what the agent proposes and what the world receives.

These four properties together describe a primitive that is structurally different from anything in the standard stack. Not better. Different. It is not a replacement for alignment work, or for permission systems, or for logging. It is the missing piece that sits between them and makes them coherent as an audit architecture.

03 / What the SDK release is

Ten lines to a signed decision.

The repository at github.com/vellacognitive/vella-substrate publishes, under MIT license, the embedded SDK for Node.js and Python (npm install @vellacognitive/vella-sdk and pip install vella-sdk), three standalone verifiers (Node, Python, shell) that confirm any proof bundle's authenticity with only the bundle and a public key, the Interface Control Document specifying the decision contract, the threat model and its fail-closed posture, the policy taxonomy covering twenty-two governance domains, and test vectors — known-good and known-tampered proof bundles, for CI and for auditors.

govern.mjs  ·  example
import { govern } from "@vellacognitive/vella-sdk"; import fs from "node:fs"; const signingKey = fs.readFileSync("./proof-signing.key", "utf8"); const result = govern({ intent: "EXECUTE_CHANGE", evidenceMask: 1, // AUTHN present proof: { signingKey } }); // result.decision === "ALLOWED" // result.reasonCode === "POLICY_SATISFIED" // result.latencyUs === 3 (single-digit microseconds) // result.proofBundle === { …complete signed record… }

The signed bundle that comes back is self-contained. It includes the intent, the evidence mask, the decision, the reason code, the policy version, the build hash, a timestamp, an ECDSA-P256 signature over a canonical hash of the envelope, and a second hash over the complete bundle. Any party in possession of the bundle and the signer's public key can verify it — in ten years, in an air-gapped environment, from a backup tape. As long as you have the bundle and the public key, the decision is legible and either valid or invalid on its own terms.

That verification step is the load-bearing one. It is what lets a claim about a governed decision stand on its own, independent of any continuing relationship with VELLA's author or infrastructure.

04 / Where this fits, and where it doesn't

What VELLA is not, as explicitly as what it is.

The SDK is not the only form of VELLA. A commercial runtime and sidecar exist for deployment contexts where a library-level primitive isn't enough: polyglot service meshes, multi-tenant adjudication, Kubernetes admission control, enforcement at network boundaries between trust domains. The SDK and the runtime produce identical proof bundles, verifiable with the same tools, so the choice between them is operational rather than semantic.

For researchers, and for anyone building agent frameworks, developer tools, CI/CD governance, or edge-deployed autonomous systems, the SDK is the right form. For enterprise-scale deployment across language boundaries and organizational trust domains, the commercial form is. Both are VELLA; the interface is the same, only the operating envelope differs.

What VELLA does not try to be is worth naming as explicitly as what it is.

not
A model safety mechanism

It does not inspect the model's reasoning, classify content, or attempt to detect misalignment. It operates on the proposed action, not the cognition behind it.

not
An IAM or access system

IAM adjudicates access to resources. VELLA adjudicates authority over actions. The two layers compose — they are not substitutes.

not
A logging or observability tool

Logs describe what happened. VELLA decides what is allowed to happen. The signed proof record is a byproduct of the decision, not the purpose of the system.

not
For hard real-time control loops

Autopilot servo commands, hardware safety interlocks, and millisecond-scale control systems are the wrong layer. VELLA gates authority-level decisions at human-command or mission-event frequency.

05 / Why we are releasing this

A substrate is only useful when it is shared.

The honest answer is that a governance substrate is not a useful primitive if it lives in one organization. A substrate is useful to the degree that it is shared. A cryptographic library that only one company's engineers can inspect is not trustworthy on the same terms as one the entire field can audit. The same principle applies here. For pre-execution adjudication with signed evidence to become a real category — something researchers cite, policy documents reference, and standards bodies engage with — the reference implementation has to be public, inspectable, runnable, and independently verifiable.

The deeper answer is that we think the category itself matters, and the only way to make a case for a category is to put a concrete, non-hypothetical instance of it in the world where people can test it against their own assumptions. An essay like this one can sketch the shape of a primitive. It cannot prove the primitive is real until there is code that implements it, tests that demonstrate its properties, and a verification procedure anyone can run.

The narrower answer is that the specific research program downstream of VELLA — work on agentic systems that can sustain audit claims over time — depends on the substrate being legible to the research community. A governed decision is only as credible as the infrastructure that adjudicated it. For researchers to treat VELLA-produced evidence as meaningful in their own work, they have to be able to inspect and run the thing that produced it. MIT licensing of the SDK is the minimum posture that makes this possible.

06 / What we are asking for

If this is your question too.

If you are working on agent safety, on pre-execution governance, on compliance evidence frameworks, on auditability for autonomous systems, or on any research program where the question what was authorized, by whom, with what evidence is a question you need to answer with cryptographic precision — we would like to hear from you.

  1. If you want to use VELLA in your experimental work, the repository has everything you need. The quickstart in each SDK's README gets you to a signed decision in ten lines of code.
  2. If you have a concrete use case where VELLA's interface doesn't cover something it should, open a GitHub issue. The Interface Control Document is stable, but the policy taxonomy and the evidence bit layout have room to grow.
  3. If you are doing academic research that would benefit from a stable, citable governance substrate, the repository is set up for citation via CITATION.cff and the v1.0.0 release is tagged and versioned.
  4. If you see something we got wrong — a structural error, a threat model gap, a bit of code that makes a claim we can't back up — tell us. Both the essay and the repository are improved by being stress-tested by the community whose judgment this work ultimately has to withstand.

The work this essay describes is the foundation for a broader research program on agentic systems with sustained audit properties. That program includes ongoing work on parallel-policy consistency for batched tool calls, integration patterns for the current generation of agent harnesses, and a separate research effort on stateful AI systems whose behavior can be evidenced rather than asserted. The SDK released today is the first public artifact of that work. More will follow.

— The invitation

The substrate exists.
It is inspectable.

Clone it, verify it, cite it, break it. The reference implementation is in your hands on the same terms as ours.

Node · npm
npm install @vellacognitive/vella-sdk
Copy
View on npm ↗
Python · pip
pip install vella-sdk
Copy
View on PyPI ↗

Correspondence to agent@vellacognitive.com

Tweaks