Vladimir Khegai

All work

Daviance

Proof of what an AI coding agent actually did.

Role
Co-founder
Years
2026
Stack
Rust, Tree-sitter, ed25519, MCP, GitHub App

Daviance is proprietary and in private evaluation.

Problem

AI coding agents can report success while deleting tests, adding skips, or weakening assertions. Reviewers need proof of what the agent actually did.

My role

Co-founder. I built Daviance with my co-founder.

Constraints

  • Daviance builds and tests a repository only from the repository’s own declared configuration: its CI workflows, package.json, pyproject, go.mod, or Makefile. If it finds none, the verdict is unsupported, never an accusation.

Architecture

Given a repository, a task, and the agent’s transcript, Daviance returns one of four verdicts: verified, suspect, failed, or unsupported. Every verdict is backed by an ed25519-signed evidence pack that anyone can replay on their own machine. Packs are currently signed with a development key; keyless signing through Sigstore is the next step.

  • Tamper analysis uses Tree-sitter across Python, JavaScript, TypeScript, and Go.
  • Held-out tests are committed to a public append-only transparency log before they are revealed: Sigstore Rekor in production, a hash-chained log in development.
  • The verdict engine is a pure function with no I/O. A dependency gate in CI enforces that.

Runs start from three entry points that share one pipeline: the command-line tool; an MCP server, where a coding agent calls Daviance on its own work as a rework loop; and a GitHub App, which picks up agent pull requests and reports the verdict as a Check run.

Daviance architecture A run starts from the command-line tool, an MCP server that a coding agent calls on its own work, or a GitHub App that picks up agent pull requests and posts a Check run. Each passes the repository, the task, and the agent transcript into tamper analysis and held-out tests. Both feed the verdict engine, a pure function with no I/O. It returns a verdict (verified, suspect, failed, or unsupported) with an ed25519-signed evidence pack, currently signed with a development key, that can be replayed on any machine. Held-out tests are committed to a public append-only transparency log. CLI daviance verify MCP server agent's rework loop GitHub App PRs · Check run Repository, task, agent transcript Tamper analysis Tree-sitter · Py, JS, TS, Go Held-out tests public append-only log Verdict engine pure function · no I/O · enforced by a CI dependency gate Verdict verified · suspect · failed · unsupported Signed evidence pack ed25519 · development key for now · replayable Daviance architecture A run starts from the command-line tool, an MCP server that a coding agent calls on its own work, or a GitHub App that picks up agent pull requests and posts a Check run. Each passes the repository, the task, and the agent transcript into tamper analysis and held-out tests. Both feed the verdict engine, a pure function with no I/O. It returns a verdict (verified, suspect, failed, or unsupported) with an ed25519-signed evidence pack, currently signed with a development key, that can be replayed on any machine. Held-out tests are committed to a public append-only transparency log. CLI daviance verify MCP server agent's rework loop GitHub App PRs · Check run Repository, task, agent transcript Tamper analysis Tree-sitter · Py, JS, TS, Go Held-out tests public append-only log Verdict engine pure function · no I/O enforced by a CI dependency gate Verdict verified · suspect · failed · unsupported Signed evidence pack ed25519 · development key for now replayable
How a run becomes a verdict.

Key decisions and trade-offs

A pure verdict engine

  • Chosen: the verdict engine is a pure function with no I/O, enforced by a dependency gate in CI.
  • Why: with no I/O and no outside world, the engine can be tested exhaustively and reasoned about adversarially.

Fail closed on accusation

  • Chosen: the verdict engine fails closed on accusation.
  • Why: a merge gate that cries wolf gets uninstalled in a week. Ambiguous rules fall to a warning and become accusations only with recorded corroboration, and a repository Daviance cannot build returns unsupported rather than an accusation.
  • Trade-off: Daviance gives up some recall to keep precision.

Signed, replayable evidence

  • Chosen: every verdict is backed by an ed25519-signed evidence pack that anyone can replay on their own machine. Packs are currently signed with a development key; keyless signing through Sigstore is the next step.
  • Rejected: asking reviewers to take Daviance’s word for the verdict.
  • Why: the pack, not Daviance’s word, is the source of trust. Its replay script reproduces the verdict on a clean machine without trusting Daviance at all.

Held-out tests behind a transparency log

  • Chosen: held-out tests are committed to a public append-only transparency log before they are revealed: Sigstore Rekor in production, a hash-chained log in development.
  • Rejected: timestamping the commitment in Daviance’s own database.
  • Why: an append-only public log timestamps the commitment before the tests are revealed, so any challenger can check the tests were not written after the fact.

Syntax-aware tamper analysis

  • Chosen: tamper analysis with Tree-sitter across Python, JavaScript, TypeScript, and Go.

Status and results

  • The current gate caught 42 of 42 planted cheats at 1.000 precision.
  • Cumulative to date: 0 false accusations across 1,793 honest cases from four sources, including 1,138 agent PRs (28 live and 1,110 merged).
  • Proprietary, in private evaluation.

What’s next

Keyless signing through Sigstore, replacing the evidence pack’s static ed25519 key.