How STVI works
From what your software should do to what the evidence shows.
One workflow, seven steps. You provide the evidence. STVI does the verification work and tells you plainly what remains unverified.
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.
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.
What to give STVI
STVI works from what you supply. The more evidence it has, the more it can settle. None of it is required, and STVI never asks you questions mid-way: it makes the safest labelled assumption or says what it could not do.
Source code
The thing being verified. Without it nothing can be run.
Requirements (PRD, PSD, user stories)
What the software is supposed to do. Without them STVI infers requirements from the code and labels them as inferred.
API documentation
Helps STVI state expected inputs, outputs and errors.
Existing tests and test results
STVI maps them to the behaviour they check. Results count only where they can be tied to your declared build.
Build identity
A Git commit SHA is preferred. It lets STVI tie evidence to the exact build you want assessed.
When something is missing, STVI says so
| If this is the case | STVI does this |
|---|---|
| Only code, no requirements | Infers requirements from the code, labels them as inferred, and lowers its confidence. |
| Only a description, no code | Writes down the requirements and claims. Everything that needs running is reported as could not be checked. |
| No tests | Writes tests for the behaviour it can run, and says they were written by STVI. |
| A term or requirement is vague | States the reading it used, or says the requirement cannot yet be tested and what is missing. |
| Two documents contradict each other | Records both, chooses neither, and lowers confidence for anything that depends on it. |
| A secret is found in a file | Records the file and line and stops reading that file. |
| The software needs a database, key or service STVI does not have | Reports the check as could not be checked and says what would unblock it. |