Spec vs Reality

How faithful is your code … to the PRD?

Verifii reads your code and produces a verifiable features inventory — every capability traced to the exact file and line that implements it. Spec drift, surfaced in minutes.

  "Password reset enforced"   —   auth/reset.py:112
  "Rate limiting on login"   —   No matching implementation found
~  "Audit logging for admin actions"   —   Present for 4 of 7 admin routes
Every finding links to the exact line of code. You can verify it. That is the standard.
{% if analysis_enabled %} Analyse your code {% else %} Request early access {% endif %} See it on a live project
The problem

Nobody notices spec drift. Until it's too late.

Every team has the same gap: a PRD that says one thing, and code that does another — with no way to verify without weeks of manual investigation.

Tests are written against the code, not the spec — they only confirm the code behaves consistently. Tests can pass while entire features are missing or mis-scoped. Green CI does not mean faithful to the PRD. It never did.

The gap compounds silently — through every sprint, every release, every handover — until it surfaces as a compliance failure, a security incident, or a customer complaint about a feature that was "definitely shipped."

Why Verifii?

A verifiable answer to: is this what we set out to build?

Run Verifii against your release code. Get a verifiable features inventory — what's implemented, what's absent, what's partial. Every finding traced to the exact line of code. Ask serious questions about your code and get detailed, code-traceable answers.

✓ Implemented

Confirmed in code.

The feature is present, behaves as documented, and Verifii can cite the exact lines. Not assumed — evidenced.

✗ Not Found

No matching implementation.

The spec describes it. The code does not contain it. That gap is now visible rather than buried in a ticket backlog.

~ Partial

Present, but incomplete.

The scaffolding is there. The full requirement is not. Verifii shows exactly which parts are missing and where.

Six lenses

Each role zooms in on what matters to it — from the same code.

One analysis. Six views.

Product Owner

"Which features we spec'd are actually in the code — and which aren't?"

Architect

"How is this system actually structured? Where are the real module boundaries?"

Engineer

"What does this module do? Who calls what, and where does every execution path go?"

Security

"What's exposed? What's validated? Where are the actual trust boundaries?"

Management

"What does this system do, in plain English? What's our technical exposure?"

Tester

"What behaviours are present and testable? Where is coverage thin or missing?"

How it works

Three steps. Minutes, not weeks.

01

Point Verifii at your code

One CLI install. Point it at a GitHub URL or local path and go.

02

It reads your code precisely

AST parsing for structure, dependency graph for relationships, LLM synthesis with sourced citations for every finding. No guessing. No filling gaps.

03

Browse, query, ask.

Role views for six different perspectives. A live Q&A on every project — ask anything in plain English and get a sourced answer from the actual code. "Is rate limiting implemented?" returns a citation, not a guess.

See it on real code

Five open-source projects, fully analysed.

No login required. Every project includes role views and a live Q&A. Ask what's implemented, what's missing, what's partial.

Live Q&A on every project

Ask "Is authentication enforced?" or "What does the cache do?" and get a sourced answer from the actual code. No guessing.

End the ambiguity.

Point Verifii at your code. Get a verifiable features inventory traced to a line in a code file — in minutes.

Request early access See how it works