How it works

Stochastic vs deterministic

Most enterprise AI today is stochastic: a model estimates what you probably meant and what the answer might be. Ask the same question twice and wording, filters, or conclusions can shift — including confident answers that never appeared in your source data. That is useful for brainstorming. It is a poor fit when a regulator, auditor, or risk committee asks “show your work.”

Vera is deterministic at runtime. Given the same prompt, skill version, and underlying datasets, you get the same governed plan and the same results. Vera does not invent SQL or invent balances — it resolves your words against skills, then executes against your org’s columns and your curated rows.

	Stochastic (typical LLM)	Deterministic (Vera)
Ground truth	Training corpus and statistical guesswork	Your loaded datasets and org profile
Repeatability	May vary run to run	Same inputs → same plan
Industry fit	Generic language about “loans” or “accounts”	Domain skill + org mapping for your codes and columns
Audit	Hard to reconstruct after the fact	Inspectable query plan before and after execution

Why industry and datasets matter. Banking — Vera’s first domain — is not one universal schema. “Checking account,” branch 14, and product code 4 are meaningless until they map to your physical columns and translation catalogs. A stochastic model can sound fluent about loans and CDs while filtering the wrong field or citing rows that do not exist in your portfolio. Vera binds language to your curated.* data and org profile before anything executes.

LLMs still have a role — at design time, to help distill vocabulary and patterns into skills. At runtime, intelligence is rules, data, and small engines running locally. That is the philosophical shift: from probabilistic guessing over the internet’s text to governed computation over your institution’s datasets.

The distillation model

Vera resolves the stochastic problem by separating when knowledge is captured from when it runs. Tacit language compresses into three durable layers:

General skill — operators (“over”, “between”), intents, dates, conversation cues, scope polarity
Domain skill — entity aliases, field synonyms, translator config (products, locations, employees)
Org profile — logical → physical column mapping and dataset scripts for your institution

Large row datasets load on demand at runtime; small translation catalogs (products, branches, employees) are prepared in advance. Vera ships with a Python app for that offline curation step—turning exports into the curated.* scripts and org data Vera expects. Want the full workflow? Join Verans for member guidance on org profiles and data preparation.

At runtime, Vera never asks a model “what did the user mean?” It matches phrases from skills, resolves catalogs deterministically, and builds a structured plan you can inspect in the UI.

Query path vs agent path

Path	When	Output
Query	No agent trigger matches	Structured query plan → filtered rows, counts, aggregates
Agent	Catalog trigger matches (e.g. customer profitability)	Multi-dataset logic, derived tables, portfolio roll-ups

Skill-first rule

Core code (prompt.js, query_engine.js, summarizer.js) must stay algorithmic. New business wording goes in skills — never as a one-off string in the planner. Scoped filters, loan exclusions, and CD exclusions all share one general polarity grammar plus domain resolution.

Version 4 conversations

Vera remembers filter state across turns. Refine with short follow-ups — “exclude customers with CDs”, “also in Vermont” — without retyping the full prompt. Portfolio search handles customer-grain joins that row-level plans cannot express alone.

Try it yourself

Open Vera Chat (runs locally in your browser), pick a starter suggestion, or paste a banking prompt. Expand “Technical query plan” on any response to see the governed JSON plan. Building for your own organization? The README covers org profiles, catalogs, and on-demand loading; Verans members get deeper material on the curation tooling and deployment patterns.