- Your software
- STVI
- Verification report
Why verification
Know what your tests actually prove.
- A test can pass.
- A requirement can remain uncovered.
- A test can exist without testing the right thing.
- Evidence can exist without proving the assessed build.
A large test suite can still leave important behaviour unverified. STVI connects intended behaviour, existing tests, additional tests, execution evidence and verification status into one traceable picture.
STVI does not ask “Did a test pass?”
It asks “What evidence do we have that this software does what it is supposed to do?”
The STVI method
One verification workflow. From intent to evidence.
Understand
Read requirements, specifications, code and available evidence.
Reconcile
Identify conflicts, ambiguities and missing information.
Claim
Turn intended behaviour into explicit verification claims.
Plan
Determine what should be tested and how.
Test
Assess existing tests and generate additional tests where needed.
Execute
Run applicable checks in the permitted environment.
Verify
Evaluate evidence, assign status and explain what remains unresolved.
What STVI can verify
From one small function to an entire product journey.
Not every assessment performs every method. Which methods apply depends on your project, your evidence and the environment STVI is permitted to run in. Where something cannot be run, the report says so and says what would settle it.
Unit Testing
Verify focused behaviour in individual functions and modules.
Shown Run on a real project, on small self-contained parts.
Module & Integration Testing
Check whether components work correctly together.
Planned Where the environment permits. Not yet shown on a real project.
API Testing
Verify inputs, outputs, errors and contract behaviour.
Planned Where the environment permits. Not yet shown on a real project.
End-to-End Testing
Follow complete user journeys where the environment permits.
Planned Where the environment permits. Not yet shown on a real project.
Regression Testing
Check whether existing behaviour remains intact.
Planned Needs an earlier build to compare against. Not yet shown on a real project.
UI Testing
Assess observable interface behaviour and user-facing flows where the environment permits.
Planned Where the environment permits. Not yet shown on a real project.
Negative & Boundary Testing
Look for failure conditions, edge cases and boundary behaviour.
Shown Run on a real project, on small self-contained parts.
Security & Access-Control Checks
Check input handling, signatures and access rules where the evidence and environment permit.
Limited Input-handling and signature checks only. This is not a security assessment.
The verification gap
Your test count isn’t your verification coverage.
100 Tests100 Requirements Verified
- Requirements
- Claims
- Existing Tests
- Coverage
- Missing Tests
- Execution
- Evidence
- Verdict
STVI looks across the entire chain instead of treating the existence of tests as proof that the product is verified.
Why STVI
Why not just ask an AI chatbot?
Different tools do different jobs. STVI is built for one of them.
General AI
Generates plausible answers.
STVI
Requires evidence and preserves provenance.
Test management tools
Track tests.
STVI
Determines what needs verification and why.
Code test generators
Generate tests.
STVI
Connects tests to claims, evidence and verdicts.
Traditional QA reports
Tell you what was tested.
STVI
Shows what was tested, what remains unverified and why.
How it works
You provide the evidence. STVI does the verification work.
Provide your project
Code, PRD, PSD, user stories, API documentation, tests and/or available test results.
Declare the build
Provide the version, commit SHA or other accepted build identity.
STVI builds the verification model
Requirements → claims → coverage → verification plan.
STVI tests
Existing tests are assessed. Missing tests may be generated. Applicable tests may be executed in the sandbox.
STVI evaluates evidence
Execution alone does not automatically establish a verdict.
Receive the report
Executive summary, detailed evidence, gaps, recommendations and a technical reference.
See STVI in action
A report you don’t need an engineer to explain.
“Could not be checked” does not mean “failed”. It means the evidence or environment did not allow the question to be settled, and the report says what would settle it. Knowing what to check next beats pretending you already know.
Verification summary
- 0Confirmed
- 2Partly confirmed
- 1Not confirmed
- 12Could not be checked
- 0Found not to work
One real assessment. 15 behaviours assessed. 26 existing tests mapped. 4 verification gaps surfaced.
Early-access assessment. Results are provisional and not independently validated.
What the report contains
Executive Summary
What was checked and what STVI found.
Verification Status
Clear status for each important behaviour.
Coverage
What the project’s own tests cover.
Verification Gaps
What is missing or insufficiently covered.
Tests STVI Wrote
Additional checks generated by STVI.
Execution Evidence
What was actually run and what happened.
Findings
Issues and areas requiring attention.
Recommended Next Actions
What would settle unresolved questions.
Technical Reference
IDs, evidence and technical details for engineering teams.
Who STVI is for
Built for the people responsible when software meets reality.
Founder / CEO
“Is this product actually ready to put in front of customers?”
Product Manager
“Did we verify the behaviours we promised?”
Engineering Leader
“Where are our real verification gaps?”
QA Leader
“What are our existing tests missing?”
AI / Vibe-Coded Product Team
“Did AI build something that actually works?”
Enterprise Buyer
“What evidence do we have before approving this software?”
When to use STVI
Use STVI before confidence becomes expensive.
Before Launch
Know what remains unverified before customers find it.
After AI / Vibe Coding
Assess what an AI-built product actually does.
After a Major Release
Check whether the new build still satisfies its intended behaviour.
Before Customer Delivery
Create evidence around important claims.
Before Enterprise Procurement
Understand verification coverage before adoption.
After a Critical Change
Focus verification on changed and affected behaviour.
The STVI principles
Verification without guesswork.
- Evidence before assertion
- Intent before language
- A test is not proof by itself
- Missing evidence remains missing
- Build provenance matters
- Observations and inferences stay separate
- “Could not verify” is a legitimate outcome
- Without independent validation, results remain provisional
- Security, accessibility and compliance claims require appropriate specialized validation
- STVI explains its limitations
See what STVI actually produces.
Don’t take our word for it. Read a real STVI assessment and see how the system separates evidence, findings and unresolved questions.
FAQ
Questions people ask before they start.
What exactly does STVI verify?
STVI checks whether your software does what it is supposed to do. It turns your requirements, or what it can infer from your code, into specific claims, then looks at what evidence exists for each claim and gives each one a status: confirmed, partly confirmed, not confirmed, could not be checked, or found not to work.
The result is provisional. It describes what the evidence shows. It is not a statement that the software works in every case.
Can STVI test my source code?
Yes. STVI reads your code, works out what it is meant to do, and checks what your existing tests cover. It can run tests on the parts of the code that can run safely in isolation. Parts that need installed packages, a database, a running server or a browser cannot be run yet, and the report says so for each claim.
Can STVI generate tests?
Yes. When a behaviour has no test, STVI can write one and connect it to the claim it is meant to check. Generated tests have so far been run on Python code and on JavaScript or TypeScript code that uses only built-in modules.
Can STVI run tests?
Yes, in a safe, isolated environment. Python tests run with the network blocked. JavaScript and TypeScript tests run only on code that needs no installed packages, and the network is not blocked for those runs. Running a test produces evidence. It is not automatic proof: the evidence still has to be judged convincing.
What if my application cannot run in the sandbox?
Then STVI says so, claim by claim, and says what would settle the question. In the one real assessment we have done, 12 of 15 claims could not be checked because the project needed packages that were not available in the safe environment. Most real web applications will be affected the same way today.
What does “Could not be checked” mean?
It means the check could not be run or settled: for example the software could not be run, or the evidence could not be tied to the exact build you declared. It does not mean the software failed. Missing evidence stays missing; STVI does not turn it into a pass or a fail.
Does STVI guarantee that my software is bug-free?
No. A report does not establish that the software is correct, secure, accessible or compliant. It says what the supplied material and the checks STVI could run do and do not show. In the one real assessment so far STVI found no defect, and it also could not run most checks.
Does STVI replace QA engineers?
No. STVI is in early access: results are produced and checked by AI sessions, with no person reviewing them, so they are provisional. Every verdict shows its evidence. They are meant to show your team what is covered, what is missing and what to check next, so that people spend their time on the right questions.
Can STVI perform security testing?
Only in a narrow sense. STVI has checked input handling and signature rules on small self-contained parts of code, such as file-name handling and token generation. That is not a security assessment or a penetration test, and STVI makes no statement about the security of your software.
Can STVI verify accessibility?
No. STVI does not test accessibility and says nothing about the accessibility of your software. Accessibility needs its own specialised checks.
What happens to my source code?
STVI reads your material using AI model sessions, so it is processed by an AI model service. The records of those sessions can contain what they read.
STVI’s intake rules check supplied files for secrets before analysis: when a secret is found, the file and line are recorded and reading of that file stops.
We have not yet written a data-retention, deletion or encryption statement, and we make none here. This page will state them only once they are implemented and tested.
How is my build identified?
You declare it, preferably as a Git commit SHA. STVI ties its evidence to that build. If no build is declared, or results cannot be tied to it, the claims that depend on it are reported as not confirmed with that reason.
Can I upload a PRD without source code?
Yes. STVI can work out requirements and claims from a PRD or description alone. Without code nothing can be run, so every claim that needs execution is reported as could not be checked.
Can I provide existing test results?
Yes. Results count as evidence only where they can be tied to the build you declared and where STVI can judge that they actually establish the behaviour. Otherwise they are reported as not confirmed, with the reason.
How long does an assessment take?
We have not yet measured this for the web product. The one real assessment so far, on a project of about 600 files, took about 76 minutes of analysis time. We will state a range here once we have measured it.
What does the full report contain?
An executive summary in plain language, a status for each important behaviour, what your own tests cover, the gaps, the tests STVI wrote, what was actually run and what happened, findings, recommended next actions, and a technical reference with IDs and evidence for engineers.
Is the report independently validated?
Not yet. STVI is in early access. Reports are produced and checked by AI sessions of one model family, with no person reviewing them, so every report is marked provisional and not independently validated, and STVI’s methods have not yet been validated. What each report does give you is the evidence behind every verdict, so your team can check it.
Stop asking whether your tests passed. Start asking whether your software is verified.
Bring your software. STVI helps you verify what the evidence supports, and shows what it doesn’t and what to check next. Early access is open.