Excellent 0.1.0 is on npm.Read the changelog
Your agent says it's done. Excellent finds out, and shows you how it knows.
Pay invoice INV-20931
Every check held. The receipt binds the task, the checks, the evidence and the verdict, and stays on this machine.
amount-matches-invoice$4,820.00payee-on-approved-listPasswithin-approval-limitPassno-duplicate-paymentNone foundAI agents can produce more work than people can carefully review. Asking another model whether the first one did a good job does not close that gap.
So Excellent treats every “done” as a claim and goes to look. The repo, the tests, the build and the browser can each tell us something real about the result. What holds up leaves a receipt. What does not goes back to the agent with the reason. Software comes first because it leaves unusually good evidence.
Refund order 58213
Every attempt starts on the record, with its agent, model, task and repo captured before the work begins.
Claim · checks read the order and the payment API
done: refund ready, $48.00
order-foundPassrefund-to-original-methodPassamount-matches-items$48.00within-refund-windowPassThe check reads where the work landed, the order and the payment API, not the agent's report.
How checks decideHistory
Wrong work comes back with the reason: the unmet check, what was expected and what was observed.
This receipt
Signed: Ed25519 over a canonical hashAppend-onlyKept in ~/.excellent
Accepted work leaves a receipt, signed, append-only and kept on your machine.
Open a real receiptOpened by
Claude Code, through MCP ~/.claude.json
Excellent lives inside the agent you already use, as one MCP entry in each agent's own config.
Every agent and its config fileThis is the sample receipt from the Excellent docs: genuine output of the receipt pipeline, with a genuine signature, made from synthetic release evidence. Its verdict is FAIL. Point at any line to see what it binds.
What it binds
One of the six verification states (PASS, MISMATCH, FAIL, UNKNOWN, NOT_RUN, PENDING). Here: FAIL.
Value
"FAIL"
What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.
Point at a line, tap it, or tab to the receipt and use ↑ ↓.
Real receipt from the Excellent docs. Synthetic release evidence, genuine signature. Verdict: FAIL. A valid signature proves the receipt was not altered. It does not make the verdict good. Source
Fifteen checks: ten pass, three failing, one running, one blocked outside the run. One unresolved check sinks the set, so the receipt says FAIL.
What it binds
Value
"FAIL"See also
What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.
Point at a line, tap it, or tab to the receipt and use ↑ ↓. Enter opens a folded line.
Runs on a machine that has never had Excellent on it. Node 18+, no dependencies. The example pack is synthetic: the work it describes is invented, the envelope, hash, signing and anchor are the real pipeline.
These commands need an Excellent monorepo checkout (<repo>), which is not public. For a check any visitor can run, use the commands under Check one yourself.
A valid signature means the receipt has not been altered since the holder of that key signed it. That is tamper-evidence, and it is real.
It does not establish that the key is the tenant's key. If you obtained the key from the same system that issued the verdict, a forged receipt re-signed under an attacker's key verifies exactly as cleanly as a genuine one. Confirm the key's fingerprint through a channel this system does not control, then pin it.
A receipt does not prove every external source was truthful. It proves which records were bound and signed together.
To fetch a tenant’s published trust material:
excellent-mcp verification universal-trust-root --jsonThe CLI on npm today, 0.1.0 (checked October 27, 2026), predates excellent-mcp verification, so this command answers unknown command until the next release.
A verification system for agentic tasks. It runs beside the agent you already use, checks the work with independent evidence, and leaves a receipt you can inspect later.
No. Your agent does the work. Excellent starts the attempt, records what happened, checks the result against your repo and tools, and compares different ways of running it.
The one you already use: Claude Code, Codex, Cursor, Copilot, Cline, Gemini, OpenCode, or any other agent that does work you can check. Excellent observes the run instead of replacing it.
Whatever can prove the task: the git tree, tests, lint, the build, browser behavior, API responses, CI, and the deployment. When a check cannot run, Excellent says so instead of implying a pass.
The attempt is returned with the exact failure, expected behavior and observed behavior, and sent back to the agent. The original context and the retry history are kept on the receipt.
None of it reaches us. Excellent keeps your repository, attempts, evidence, and receipts in a local database on your machine, and sends none of it to Excellent. Model calls are the exception worth naming: they go from your machine to the provider you chose, on your own account, the same traffic your agent already makes. The security page has both paths in full.
Yes, for individuals. You install it and run it on your own machine, with no seats to buy and nothing metered for local verification. Team features are in early access; contact us to join.
We are building Excellent with Excellent, and the results page shows where that stands.
Paste one line into your terminal to install Excellent, then run a task and read what it found.
curl -fsSL https://excellent.so/install.sh | sh