Portal walkthrough
Release evidence, assembled automatically.
A tour of the Dovada portal - the same product, seeded with sample data so every screen shown here is real, not a mockup.
Landing
One page per install
Two questions, framed plainly
What this install watches, and the two questions Dovada keeps separate, never blended : did we build the right thing, did we prove it works.
The flow, drawn
Intent, implementation and verification evidence feed two separate correlation cores - never one blended score - into a single append-only package.
Every release, at a glance
The most recent releases, open or closed, each with its package status, when it was assembled, and how many of its records have both answers.
The newest records
The newest tracked records, closed ones included - and a closed record's blanks stay blank. Dovada stops watching once a ticket reaches its terminal status; evidence that shows up after - a test added once the backlog catches up - never gets stitched in after the fact.
CER View
One record, every answer
Search and browse
Every record Dovada is tracking - searchable by CER, ticket or pull request, closed ones included on request.
A real progress strip
What's actually happened to this record, dated as it happened - created, linked to a pull request, assessed, closed.
Two axes, never blended
Validation and Verification, judged and shown separately - this record's Validation reads Aligned , but Verification catches what Validation structurally can't see: a real, linked test exists, but its assertions are too weak to prove the behavior - so the verdict reads Discrepancy .
Every answer has its basis
Expand to the actual requirements judged, the Verification behaviours judged separately, and the pull requests behind them - nothing here is just a label.
How each answer gets made
Two verticals, assessed separately
Validation
Did we build the right thing?
Every requirement a ticket states, read against the pull requests that claim to satisfy it - judged one requirement at a time, never rounded up into a single score.
Verification
Did we prove it works?
From the code that changed, traced through real imports and calls to the tests that actually exercise it - then judged for whether that link is meaningful, not just present.
Every "judged" above is a real model call - Claude, under your own Anthropic account and contract, not Dovada's. Configured for Anthropic today; choice of provider is coming in a future release.
Release View
Every release, watched
Search and browse
Every release Dovada is watching, open or closed - searchable by release, ticket, CER or pull request.
The branch, and the dates
The release branch, when it was cut and closed, and a one-line progress summary - but only across tickets that actually shipped code.
Every record it holds
Each ticket with code behind it, with its current Validation and Verification state, linking straight to the CER - including one where Validation reads Aligned but Verification caught a real Discrepancy.
What the summary can't see
A second ticket reached Done with no pull request behind it - so it never became a record, and the clean summary above never counted it. Dovada names the gap anyway, as an Unshipped Ticket finding: not a guess, not a silent omission.
Package View
The one document Dovada delivers
Search and browse
Every release's newest package - Draft or Final - searchable by release, ticket, CER or pull request.
Status, at the top
When it was assembled, and Draft or Final as its own badge - never buried in the document below.
The package itself, embedded
The real, stored Release Evidence Package , sandboxed and framed here exactly as it was rendered. Once a release closes, its package locks Final and is never re-rendered.
Or skip the portal chrome entirely - open this exact package standalone , the same file a customer gets attached to a release tag.
Inside the package
Opens with the facts
Scope, stated exactly
The release, its trigger, when it was assembled, and precisely which tickets it includes - never "everything since last time."
Both axes, one line each
Validation and Verification status, counted by ticket - still shown separately, even in the summary.
What this method cannot see
Stated plainly, not buried: how code was found, and what kind of code this discovery method structurally cannot reach.
Inside the package
Every claim, worst first
Counted, and distributed
How many claims this release makes, across how many tickets, and the worst band present - ordered worst to best, so two real problems can't get buried under eleven passes.
Grouped your way
By severity or by ticket, sorted either way, jump straight to one by key - the same claims, organized however you're reading them right now.
Inside the package
Verification, opened up
A Verification claim, in full
Every Verification claim judged the same way: a verdict, Dovada's own reasoning, and the exact behavior it concerns - nothing summarized into a single pass or fail.
Not every linked test counts
A second test is linked to this exact code by a plain import, and Dovada says so - it just isn't the one the verdict rests on, because it never actually exercises this behavior. A link is not an assertion; meaningfulness is.
Inside the package
Validation gets the same treatment
Validation, judged the same way
Every Validation claim gets the identical shape the Verification claim just got - verdict, reasoning, cited evidence - on the exact same ticket, DEMO-101.
Every ticket, not just one
DEMO-102 continues right below - its own Verification and Validation, both itemized the same way. Nothing in this release is summarized away.
Inside the package
What Dovada didn't find
Tests that might be missing
The opposite of every other sheet: not a verdict about code that exists, but a code location the change touches with no test Dovada could find linked to it at all.
Not every record gets an answer
DEMO-103 is docs-only - there's no code to ask this question about, and the sheet says so plainly rather than guessing or staying silent.
Inside the package
Two tickets, three real gaps
Named, with a location
A missing test isn't a vague warning - it's one sentence and the exact file and function it concerns, so a reviewer knows precisely where to look.
More than one gap, one ticket
A single ticket can carry more than one open question - both of DEMO-102's concern the same function, from two different angles.
Inside the package
What actually ran
Every reported test, by declared type
The Full Results tab: the release branch's own test results - passed, failed, not executed - grouped by the test types this deployment declares, Unit among them. No test here is judged against the release's code.
A failure stays visible
Named, not hidden - and no Claims-sheet verdict changes with it. What ran and what Validation judged are two different questions.
Inside the package
The same run, a different question
Both say "Unit" - for different reasons
Full Results trusts your own declared config. This tab trusts nothing but what Dovada's graph proved: only 2 of the run's 4 tests were judged to actually exercise this release's changed code.
Tagged with the ticket it covers
Only the tests Dovada judged to actually exercise this release's code appear here - each one tagged with the ticket whose claim it backs.
Release Notes
The same release, plain language
Search and browse
Every release Dovada is watching, by number - with whether its Customer Facing notes are written yet.
Two readings, one evidence base
A Technical tab that accumulates as tickets ship - no model call, just what's pinned to the package - and a Customer Facing tab, written once in plain language when the release closes. Never two different stories about the same release.
Configuration
What Dovada evaluates against
What counts as ready
Which Jira transition moves a ticket into Validation's reach, and what each possible exit from that status means - declared, not guessed at.
How often Dovada looks
Minutes between ticks, bounded 5 to 60 - a setting that moves real spend, editable right here, with every save checked against the whole configuration before it takes effect.
Glossary
One glossary, everywhere
The same definitions the package embeds, now a page of its own - every term Dovada prints is hover-linked back to it, on every view across the portal.
Evidence, not verdicts.
Dovada doesn't make the release decision. It gives the person who does something concrete to point to - for every ticket, every release.
Validation - did we build the right thingVerification - did we prove it works
Open a real sample package, standalone - no portal chrome, just the document.
