Questions people ask before they start.

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.

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.

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.

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.

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.

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.

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.

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.

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.

No. STVI does not test accessibility and says nothing about the accessibility of your software. Accessibility needs its own specialised checks.

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.

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.

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.

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.

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.

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.

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.