
Veris
io.github.vighridayPublished by GitHub account vighridayv2.1.8Updated Oct 25, 2026
Behavioral verification intelligence for AI coding agents. 17 MCP tools. Local-first. MIT.
Overview
Local MCP server that builds a behavioral diff of TypeScript/JavaScript changes so an AI coding agent can see what behavior changed and what evidence backs it.
- What you can do
- Analyze changes: build a behavioral graph of the repo and diff it against a git base ref, flagging added, removed and rewritten-body nodes and edges with a resolution confidence per edge. Assess risk and workflows: rank affected areas by a heuristic risk model and label semantic workflows such as payments, auth or webhooks. Plan verification: generate adversarial probes, allocate a time budget to the highest-leverage checks, and run counterfactuals such as what-if-revert. Track evidence: record execution results in an append-only, hash-chained store with trust classes, and detect drift across runs. Report: export an onboarding map and a standalone HTML dashboard.
- When to use it
- Useful when an agent has made broad edits to a TypeScript or JavaScript repository and you want to know which behaviors changed and which of them have any verification behind them, before review or in CI. It suits teams that want risk-ranked guidance on what to test rather than another test runner or linter.
- Requirements
- Runs locally via npx as a stdio process; needs Node.js and a git repository with real history and a resolvable base ref (fetch-depth 0 in CI). Optional environment variables VERIS_CONFIDENCE_THRESHOLD, VERIS_PLUGINS_DISABLED and VERIS_STATE_DISABLED tune behavior. On npm 12, run history needs an allowScripts entry for better-sqlite3 plus a rebuild.
Installation
In SourceWeft
- Open Veris in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Veris
veris — Latin, “of truth”
Your agent just changed 40 files.
What actually broke, and was any of it checked?
[CI] [npm] [MIT] [MCP: 17 tools] [No telemetry] [Self-audit: 55 defects published]
We pointed Veris at Veris — it found 55 defects
Every one is published — what broke, why it mattered, the fix, and the test that proves it: docs/internal/BUG_TRACKER.md
The worst three, in our own tool:
It invented baselines. When git was unavailable, Veris built a "before" state from the first 70% of the current graph and reported the comparison as a real behavioral diff. No flag. No warning. A verification tool was fabricating the thing it verified against.
91% of its call edges were guesses.
It matched the trailing name of a call against every declaration sharing that name.
console.log() drew an edge to the project's own Logger.log. Measured on a real
dependency: 2,804 of 3,077 edges pointed at an ambiguous name.
The graded agent could erase its own failures.
Execution results were stored with INSERT OR REPLACE. Post fail, then post
pass, and the failure was gone.
We could have fixed these quietly. Publishing them is the point: a tool that tells you what is unverified has no standing to hide its own unverified claims.
This is also the demo. That is the analysis Veris performs, run on itself.
What Veris is
A behavioral diff for AI-written code, speaking the Model Context Protocol so your agent can ask while it is still working — not after you find out in review.
It answers two questions a line diff cannot:
- What behavior changed? Not which lines — which behaviors, and what reaches them.
- Was any of it actually checked? Published research puts roughly 65% of agent-authored PRs at zero coverage of their own changed lines.
Veris never executes anything. No tests, no sandboxes, no runtime. It reads, models, and tells your agent what is at risk and what evidence exists. Running things stays with the tools that are good at running things.
The 30-second version
Read lines 2 and 4 again — they are the whole philosophy.
Six calls were too ambiguous to resolve, so Veris drew no edge rather than
guessing. The head is marked -dirty because uncommitted changes were included, so
the result is not reproducible from commits alone.
Most tools report only what they found. Veris also reports what it could not determine, because a confident wrong answer is worse than an admitted gap.
Install
As an MCP server — one config block, then restart your client:
17 tools light up in Claude Code, Cursor, or any MCP-compatible agent.
As a CLI:
Needs a git repository with real history. Veris diffs against the merge-base with your base ref. If it cannot establish one, it fails and says why rather than inventing a baseline. In CI:
fetch-depth: 0.
On npm 12, run history needs one extra line. npm 12 no longer runs dependency install scripts by default, so
better-sqlite3never fetches its prebuilt binding. Veris still analyzes, diffs, scores risk and plans verification — only run history and cross-run drift need it. The allowlist is per-project and is not inherited from a dependency, so it has to go in yourpackage.json:Then
npm rebuild better-sqlite3.veris-core doctorreports which mode you are in, and never claims persistence is working when it is not.
How it thinks
The red box is a feature. So is the loop back into coverage.
Three ideas that make it different
1. Every edge declares how certain it is
Most graph tools give you an edge. Veris tells you why it believes the edge:
Anything that must not reason on a guess — a gate, a policy rule — filters for
resolved. Missing edges understate coupling. They never invent it.
2. Evidence is append-only, and knows who said it
The agent posting results is usually the agent being judged. So:
Records are hash-chained. A later pass never overwrites an earlier failure; editing
the database directly breaks the chain and verifyEvidenceChain() reports exactly
where. An agent cannot raise its own assurance by asserting harder.
3. It catches the rewrite that keeps its name
Same name. Same callees. Same graph shape. Every name-and-topology comparison sees
nothing. Veris hashes the normalized body, so this surfaces as a modifiedNode —
while renaming a directory, which used to look like 100% drift, now correctly looks
like nothing at all.
What your agent asks
Probes are concrete, not nudges:
Payments / idempotency — Submit a charge twice with the same idempotency key inside a 500 ms window. Invariant: exactly one ledger entry; the second call returns the first result.
Webhooks / replay — Replay a 24-hour-old signed payload with its original signature. Invariant: rejected by timestamp window even though the signature is valid.
Everything else it does
Honest limits
Stated plainly, so nobody discovers them the hard way.
- A workflow is a label, not a path. Classification is a weighted keyword vote over directory names, imports and symbol names. It does not traverse the call graph. Rate-limiting code that imports Redis lands in Caching. Making workflows real paths is the top roadmap item.
- Coverage is not assurance. It measures how much planned verification has evidence behind it. It is not calibrated against real incidents and does not estimate the probability your code is correct.
- Risk is a heuristic. Good for ranking what to look at first. Not a defect predictor. No ground truth behind it.
- Probes are a curated library — real failure modes, written by hand, selected by domain. Not generated from your code.
- TypeScript and JavaScript only. Python and Go are on the roadmap.
- Some calls can't be resolved. Dynamic dispatch and untyped JS defeat the checker. Those produce no edge, and the count is in the output.
Upgrading from 2.x? 3.0 has real breaking changes — see UPGRADING.md.
Privacy & security
- Local-first. All analysis runs on your machine. No telemetry, ever. Nothing about your code leaves the machine.
- Zero-retention mode —
VERIS_STATE_DISABLED=1. - No network sockets in the analyzer. stdio and the filesystem only.
Veris is usually pointed at repositories you did not write, so repository content is
untrusted input. Plugins execute code from the analyzed repo, so they are off by
default — --allow-plugins opts in, and each plugin's path and SHA-256 is printed
before it runs. There is no sandbox, and SECURITY.md says so plainly
instead of implying otherwise.
Docs
Contributing
The five things that move the needle most:
- Entry-point detection for a framework you know — routes, handlers, queue consumers. This is what turns a workflow from a label into a path.
- Labelled repositories for a classification benchmark. The accuracy claim needs ground truth, not more rules.
- Probe provenance. The shipped probes are good and uncited; one backed by a public postmortem is worth ten that aren't.
- Language adapters — Python, Go.
- Calibration data — what Veris flagged that broke, and what it missed. The second is more valuable.
See CONTRIBUTING.md. Open source, sponsor-supported. No paid tier, no gated features, no open-core bait.
MIT — see LICENSE
Source: README.md at commit 8bec168
Tools
0Version history
1- v2.1.8LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts