Solvi 1.0 puts rules, evidence checks and replayable records around automated decisions. The open-source Python library combines fast decision paths with an LLM or search when needed, and human escalation when neither can answer under the system’s configured conditions. Its author, Maxim Kuznetsov, dates the release to October 4, 2026, in his DEV Community walkthrough.
For AI application developers, the central feature is the separation between proposing an answer and having authority to act on it. Hard checks can force an outcome regardless of a model’s confidence; a tool guard can allow, deny or escalate a proposed call; and a knowledge store tracks where accepted information came from. Solvi is a library for constructing these decision systems, rather than a newly trained language model.
How the decision paths work
In the author’s HackerNoon explanation, Solvi divides decision work between two paths and a person. System 1 consists of rules, ordinary code or small fitted models. System 2 uses an LLM or search for cases the fast path cannot handle under its calibrated conditions. Cases neither path can resolve go to a person.
The conditions matter as much as the routing. The author describes System 1 answering alone under a promise calibrated on labelled examples it did not see during fitting. Two examples illustrate different targets: limiting wrong autonomous answers as a share of all inputs, using conformal risk control, or limiting errors among the answers given autonomously, using learn-then-test. Those denominators differ, so a developer needs to identify which promise applies before interpreting an error limit.
The slow path also has conditions: according to the explanation, handoffs go to it only on subsets of cases where it meets the promise too. Other cases go to a person with the candidate answers and reasons. The architecture therefore treats escalation as part of the decision process, rather than assuming that a more deliberative model can resolve every difficult input.
These are the author’s descriptions of the system’s operation. They should not be read as independent evidence that a particular deployment will meet an error target on its own data.
Ready systems and the functions underneath
Solvi’s release description separates configurable systems from the building blocks used to construct them. The ready interfaces cover four distinct jobs:
| Interface | Documented role |
|---|---|
| <code>solvi.build</code> | Compose a decision system from a question, labelled examples, a promise and an optional slow path. |
| <code>solvi.Agent</code> | Act in an environment. |
| <code>solvi.Guard</code> | Decide whether a proposed tool call proceeds, is denied or needs a person. |
| <code>solvi.Knowledge</code> | Store what the system knows and where that information came from. |
The author places building blocks in solvi.core and describes the ready systems as stable in 1.x. Experimental functionality lives separately in solvi.experimental. This gives developers a documented distinction between configuring a supplied system and assembling its lower-level parts. Source: release explanation.
At the lower level, the DEV tutorial starts with a catalog of plain functions: argument names identify the facts a function reads, and its name identifies the fact it sets. Its leave-request example calculates requested days and the remaining leave balance, then applies a hard balance check and a notice rule.
In the reported output, a balance of 14 produces approval, while a balance of 3 produces a forced rejection. In the latter case, the hard check determines the answer before the ordinary approval rule can do so. This demonstrates the intended precedence of a mandatory condition over the rest of the decision logic. Source: author’s tutorial.
What changes in checks and replay
The tutorial identifies a specific change in 1.0: then= automatically connects a hard check to the question’s flow. Previously, developers also had to list the check in requires=; forgetting that step could let the question be answered as though the check had passed. The release also exposes checks through res.checks, including their names, statuses, hard-or-soft classification and reasons.
Solvi’s evidence checking has a narrower purpose than establishing that an answer is true. The author describes a quote check that retains a model’s cited text only when it appears in the source, after normalizing no-break spaces, curly quotes and dashes. That checks the presence of supporting text; developers still need to assess what that text establishes. Source: architecture explanation.
For accountability, decisions are stored in hash-chained records that can be replayed. The DEV tutorial reports successful replay for both leave-request outcomes. It then describes manually changing a stored balance from 14 to 41 and detecting the edit through a hash mismatch. The author distinguishes such editing from store.redact, which is described as erasing personal data while preserving chain verification. These are reported demonstrations, rather than an independent security assessment. Source: replay walkthrough.
Tool authority and knowledge provenance
With solvi.Guard, an agent proposes a call instead of invoking the tool directly. The guard can allow it, in which case Solvi runs the function, deny it with reasons, or escalate it to a person. The practical significance is a distinct decision point between an agent’s proposal and execution. Its usefulness still depends on the checks and escalation conditions the developer supplies. Source: Guard description.
solvi.Knowledge addresses a related question: which information may become part of the system’s knowledge? The release description says it accepts information from a person, an outcome, a written specification or a verified System 2 answer. It refuses the system’s own unverified answers. That creates an explicit boundary between generating an answer and accepting it as knowledge, while retaining its provenance.
The author also reports a retraction test on a synthetic store of 10,000 items: 1,000 out of 1,000 random retractions left the same fingerprint as rebuilding the store as though the item had never been written. This is a specific consistency result for the described synthetic test. It does not establish production performance or correctness across other workloads. Source: Knowledge release description.
Requirements and migration boundaries
Solvi 1.0 requires Python 3.11 or later. The repository evidence lists testing on Python 3.11 through 3.14, while the author’s tutorial names numpy, scipy and pydantic as core dependencies and supplies this installation command:
pip install solvi
For developers moving from 0.9, the release materials say old import paths continue to work through 1.0.x with warnings. The documented migration command is solvi migrate PATH. The tutorial also says experimental components warn on import and are scheduled to graduate or be removed by version 1.2. That schedule is a stated plan, rather than a completed change. Source: installation and migration guidance.
Solvi’s strongest documented proposition is the combination of explicit decision authority, traceable evidence and replay. Evaluating it means testing the whole configured process: the promise on representative labelled examples, the precedence of hard checks, the guard’s execution decisions and the handling of knowledge sources. The supplied walkthroughs explain those mechanisms, but leave deployment-specific reliability to be established on the developer’s own task.
Related reading: Coinbase’s Autopilot brings a quality loop to AI customer support
