Continuous — not a release-time scan
Two questions, answered separately and never blended — intent against implementation, implementation against the tests that actually exercise it. Evidence builds as changes happen, then assembles itself the moment a release fires.
Why now
Confidence in a release used to be a by-product of the hours a human spent writing and reviewing it. The labour itself was evidence that scrutiny had occurred.
As agents generate more of the implementation, humans shift from authors to reviewers, and change volume grows faster than review capacity. The informal trust-by-labour signal disappears — nobody spent the hours anymore.
Dovada exists to manufacture the confidence that time used to generate for free.
What comes out
Every change validated against the request that asked for it. Every change verified by the tests that exercise it. Every test judged on whether it actually proves the behaviour, not merely that it ran.
Every verdict cites the exact evidence it was judged against — a pointer a query can follow, not a citation in prose. Re-run it after the criteria change and the earlier verdict stays on record beside the new one.
What it isn't
Who's building this
Josh Strimbu — thirty years across the software lifecycle, from manual testing to staff-level SDET and automation architect. I have assembled this evidence by hand more times than I would like to count, and watched teams ship on the strength of a green build that proved nothing about what was actually asked for.
Dovadă is Romanian for proof. It is also, as it happens, my grandparents' language.
Before it ships
If you are on the hook for a release — release management, QA leadership, engineering or a governance function — I would like thirty minutes to hear how you assemble evidence today, what breaks, and who asks you for it — then talk about where Dovada fits in your release cycle.
josh@dovada.dev