Verify tests the running system the way your users, your integrations and an attacker would. One agent drives a real browser end to end, one exercises every API, and one probes for security weaknesses. Every test traces to a requirement, and anything that fails goes straight back to Build as a ticket, with the requirement attached.
Orlian’s own regression suite was written and run by these agents.
Three ways of breaking the same build, run against staging. What survives all three is ready to release.
Each one has a codename, one job and a record of everything it did. These views show a sample project.
It drives a sandboxed browser against staging: it explores the app, proposes test cases from the requirements and runs them, with a live view you can watch. When something blocks it, it says so plainly instead of reporting a pass it did not earn.
It reads the API and data design written in Plan, asks which environment to run against, and tests every endpoint for status, schema, speed and side effects. A failing call becomes a ticket on the Build board, traced to the requirement it breaks.
Dynamic security testing runs against the live staging app. It crawls the routes, probes for injection, broken authentication, weak sessions and missing protections, and grades every finding. Findings go to the same board as any other defect.
A person reviews the evidence: every requirement in the build, the tests behind it and the security results, and accepts it, or sends it back. This is the last gate: accepting the evidence approves the build for release.
A response that breaks the API contract comes back to Build as ticket #171, already linked to the requirement it breaks. When the fix lands, the same test proves it.
We open Orlian on a live project and walk you through the Verify wing: what goes in, what the agents produce, and where a person signs. No slides.
