Tests
Plan, run, and prove verification.
Define test cases that prove requirements are met, organize them into plans, and record results from a run or from CI. Pipeline submissions land as automated evidence with provenance — a person promotes them to a signed Passed/Failed. Coverage and suspect stay live.
A test case as a governed record — its steps and expected results, its workflow state, and the approval it needs, on the same thread as the requirement it proves.
What it does
Verification that stays connected to what it proves.
The value of a test is not just its result — it is the live link between that result and the requirement it verifies.
Test cases with steps
Define exactly what gets verified and how, as controlled records that reference the requirements they prove.
Plans, runs & milestones
Organize cases into plans, execute human runs, and ingest CI results onto the same run record — pass, fail, blocked, or automated evidence, with provenance from the pipeline. Defects logged against a failure stay linked to the items they affect.
CI evidence ingest
A project-granted API key submits JSON or JUnit/xUnit/TRX; each success creates a new automated run. Attestations (optional unless required) verify PEMs or keyless OIDC against a pinned public-good Sigstore trust root, binding artifact digest and commit — not the result body. Trusted builders apply to both paths. GitHub private-repository Sigstore is not supported.
Promote to a signed verdict
Automated evidence is never Passed or Failed. Open the ingest run and record a signed human verdict before you treat it as approved. A CI key cannot sign or promote.
Live coverage
Because tests trace to requirements, coverage is something you measure and prove. Automated CI evidence is visible as automated; approve it with a signed verdict. Case Pass Rate uses the latest non-automated result so CI ingest does not displace a signed Passed.
On the thread
Coverage as a first-class signal.
Tests turn “is everything verified” from a hopeful yes into a defensible one, because the links are real.
Each test case references the requirements it proves, so coverage and suspect status stay current.
Runs connect to the model elements they exercise, tying verification to the design.
A release bundle carries its verification results, so what shipped is provably what was tested.
Derive with AI
Derive test cases from your requirements.
Point the governed derivation engine at a set of requirements and it proposes the verification they need — test cases and a plan — each cited to the requirement it covers. You review, cherry-pick, and accept; nothing is written until you do.
Prove it, and keep proving it.
Run verification in the product or ingest it from CI — then sign the verdict a person is accountable for.