Why Vertep
The model may choose. The chart decides what is allowed.
AI agents are starting to make decisions that matter: a loan, a claim, a treatment request. The usual way to build one is a loop around a prompt, and the usual answer to "why did it do that?" is a shrug and a transcript. Vertep is the other way to build it: a statechart that states the legal moves, a journal that records every step, and a model that picks among the moves and nothing else.
The problem
A prompt loop is a program whose state is a transcript.
Nothing outside the model knows what is allowed
Where is the process now? Somewhere in a growing prompt. What may it do next? Whatever the model says. A prompt injection in a retrieved document can ask for any tool with any arguments.
It cannot be replayed
Run it again and the model answers differently. A failure in production can be described but not reproduced, and a decision cannot be re-examined, only remembered.
The reasons are written afterwards
Explanations of a model's answer are usually produced after the fact, by the same kind of system that gave the answer. They can be fluent and wrong, and nothing ties them to what actually happened.
It has no clock and no escalation
What if the model hangs? What if a person must approve a step and goes home for the weekend? Each patch adds an if, and the patches grow into a state machine without its diagram or its guarantees.
The idea
Put the model at a choice point inside a program it does not control.
The program is a statechart, a standard (W3C SCXML) way to say which states a process can be in and which moves are legal from each. Most of the chart is ordinary logic. At a few states it cannot decide alone, and those are marked as decide states.
At a decide state the chart works out which moves are enabled right now, and offers only those to a decider: a language model, a person or a rule. The answer is accepted only if it was on the list. Whatever the model prefers, a move the chart does not offer is not available.
Every input, and every answer, is written to a journal before the chart acts on it. The journal is the whole truth of the process, so the process can be replayed without the model, and examined as of any step.
<state id="underwriting" vt:decide="underwriter" vt:candidates="approve decline refer">
<transition event="approve" cond="ctx.dti <= 43 && ctx.amount <= 50000" target="approved"/>
<transition event="decline" target="declined"/>
<transition event="refer" target="officer_review"/>
<transition event="error.decide.invalid" target="officer_review"/>
</state>From the credit-decision example. approve exists only while the ratio is at most 43% and the amount at most 50 000. Above that, the model is never offered it.
What you get
Six properties, each one checked rather than promised.
Bounded
The chart is the policy. A decider chooses among enabled moves; it cannot cut a new one. This is a theorem in the Lean model (decider safety), not a prompt instruction.
How deciders work →Recorded
Inputs, decisions, model results and timers are journaled before they take effect, with compare-and-set appends and a transactional outbox.
The runtime →Replayable
Replay the journal with no model bound and reach the same states. The credit-decision example replays nine entries with zero decider calls.
See it run →Explainable
The record answers what state, what was offered, who chose, under which version of the rules, and what followed. Not a rationalisation: the process itself.
Read the article →Verified
The SCXML algorithm is checked against the W3C conformance suite, and a Lean 4 model replays the Rust traces as a differential oracle. The proofs found thirteen bugs in the first implementation.
Verification →Portable
One core, in Rust and in the browser through WebAssembly. Python bindings are built and not yet released. Charts are SCXML, YAML or a Rust macro, and every chart is also RDF, versioned by its hash.
Get started →Who it is for
Teams putting agents near regulated decisions
Lending, insurance, healthcare, public services: places where someone will later ask why, and where a human must be able to intervene.
The regulated view →People who already think in states
If you model processes as statecharts, or wish your agent's workflow had a diagram, this is the SCXML you know with durable actors and journaled choices.
The shape of behaviour →Rust and WebAssembly developers
A no_std pure core, a Tokio shell, and bindings for browsers and Node.js on one command bridge.
How it compares, honestly
Vertep is not the only way to do any one of these things. It is an unusual combination.
Agent frameworks built on a prompt loop
They are fast to start and flexible. They do not give you a chart that bounds the model, a replay without it, or a record that was written before the action. If your agent only drafts text for a person to read, you may not need more.
Durable-execution engines such as Temporal
They are mature, widely used and excellent at long-running workflows written as code. Vertep's differences are that the process is a chart, which is data that can be hashed, versioned, diagrammed and queried as RDF, and that a model's choice is a first-class journaled step. If you need production-hardened workflows today, in a language they support, they are the safer choice.
Statechart libraries such as XState
They are excellent for interfaces and for application logic in JavaScript. Vertep implements the W3C SCXML algorithm in full for server-side, durable, multi-actor use, and adds the journal, the deciders and the proofs.
Where Vertep stands today
- Version 0.1.x. APIs may change between minor versions before 1.0.
- Built in the open, quickly. The specification is complete for what is built; real-world use is what is missing. That is the reason to try it on a small case and tell us what breaks.
- Strong: the SCXML core, the journal and replay, the deciders, the Lean model, the Rust and JavaScript bindings.
- Younger: clusters, federation, durable objects, wallets and agent protocols. They are built and specified, with fewer users and open items, which the roadmap lists.
- Not yet there: redaction of personal data in a journal, an explanation export, published benchmarks. These are specified in the drafts
m12-decision-recordsandm13-production-readiness.
Try it in ten minutes
git clone https://github.com/Volland/vertep && cd vertep
cargo run -p vertep-examples --bin credit-decisionThree loan applications are decided by a scripted stand-in for a model, then an auditor opens the same journal with no decider at all. Read the walkthrough, then change a threshold in loan.scxml and watch what the model is offered. If something is unclear or broken, open an issue: right now that is the most useful thing you can do.