Platform

About thirty modules. Turn on the ones you need.

Each module does one job, runs on the AI model you choose and writes into tools you already use. Start with test generation and code checks, and add requirements and traceability once those are trusted.

Settings · Modules7 of 9 on

Requirements extractionBRD, Word, Excel, PDF, Jira

fast

Test case designScenarios, P1 to P4 cases, coverage

strong

Test generationUnit, integration, E2E, contract

strong

Live UI checksChromium, visual, WCAG

fast

Bug detectionTwelve categories, with fixes

strong

Threat modelSTRIDE, LINDDUN, PASTA

strong

TraceabilityRequirement to code to test

fast

Performance analysisk6, JMeter, Gatling results

fast

Codebase Q&AAnswers cited to file and line

fast

Sample configuration · the switches work

About thirty modules · all live

Every module, and how each one is checked.

Pick a group, then a module. The AI does the judging and the platform checks the result against your code before it's shown. We're deepening each module release by release.

Plan and design

Requirements

Live

Splits a BRD, Word, Excel, PDF or Jira export into atomic requirements, each with a priority and a reference to its section.

How it's checkedThe whole document is read in parts, with no first-page cutoff. Statements too vague to test are listed, never dropped.

In · DocumentsOut · Requirement list with source refs

BRD_Refunds_v3.docx· 14 pages42 requirements

REQ-12 · § 3.1 · second approver over 10,000critical
REQ-13 · § 3.1 · no self-approvalhigh
REQ-18 · § 4.2 · audit log kept seven yearsmedium
§ 5.4 "should feel intuitive"not atomised

3 statements too vague to test, listed for review

Illustration · sample data

Plan and design

Testability

Live

Scores each requirement as testable, needs work or untestable, suggests a rewrite and flags contradictions.

How it's checkedA score is shown only when the assessment actually ran.

In · RequirementsOut · Scores, issues, rewrites

Testability· Refunds31 testable · 9 need work · 2 untestable

REQ-12 · second approver over 10,000testable
REQ-14 · "the screen should be fast"needs work
REQ-20 · "approve as appropriate"untestable
REQ-7 and REQ-19 disagree on the limitcontradiction

Suggested for REQ-14: loads in under 2 s at p95 on staging

Illustration · sample data

Plan and design

Test scenarios

Live

Maps happy, alternate, negative, boundary, error, cross-feature and non-functional scenarios for every requirement.

How it's checkedThe platform computes which requirements have no scenario, or only one side covered.

In · RequirementsOut · Scenario map, coverage matrix

Scenario coverage· Refunds42 requirements

REQ-12 · 5 scenariosboth sides
REQ-13 · 3 scenariosno boundary
REQ-15 · 1 scenariohappy path only
REQ-21 · 0 scenariosuncovered

Illustration · sample data

Plan and design

Test cases

Live

Writes P1 to P4 cases using equivalence, boundary, decision-table and state-transition techniques.

How it's checkedCoverage is computed by the platform, and uncovered requirements are filled in a second pass.

In · Requirements or scenariosOut · Prioritised cases

Test cases· Refunds118 cases

P1 · TC-031 · exactly 10,000 needs no second approverboundary
P1 · TC-032 · 10,000.01 needs a second approverboundary
P2 · TC-040 · approver approves own refundnegative
Requirement coverage41 of 42

1 gap filled in the second pass

Illustration · sample data

Plan and design

Test plan

Live

Builds a risk-based plan: scope, a risk matrix over modules, test levels, entry and exit criteria, and an effort estimate.

How it's checkedRisk is grounded in measured code complexity, not the model's opinion.

In · Requirements and codeOut · Plan and estimate

Test plan· payments-servicev1 draft

refunds/ · complexity 38 · many callershigh risk
ledger/ · complexity 21medium
notifications/ · complexity 6low
Effort estimate14 days

Entry and exit criteria included

Illustration · sample data

Plan and design

Test data

Live

Creates fixtures from your schemas, stories or designed cases: valid, invalid, boundary and security values.

How it's checkedEach case is checked against your real schema. Sensitive fields are masked as environment variables.

In · Schemas, stories, casesOut · JSON fixtures

Fixtures· RefundRequest26 values

amount = 10000.00boundary
amount = -1invalid
approver_id = ${APPROVER_ID}masked
TC-032 expects 422matches schema

Checked against the RefundRequest model

Illustration · sample data

Plan and design

Threat model

Live

Builds a data-flow diagram from your routes, call graph and dependencies, then runs STRIDE, LINDDUN and PASTA over it.

How it's checkedA threat is corroborated only when a real scan finding shares its CWE. There is never a "secure" verdict.

In · Code, OpenAPI, scan resultsOut · Threat register with coverage

NextThreat-model diff on every change

Threat register· payments-serviceSTRIDE · LINDDUN · PASTA

POST /refund · denial of servicecorroborated · CWE-770
ledger DB · tamperinghypothesis
customer profile · linkabilityhypothesis
webhook endpoint · spoofingunverified

18 of 24 element and category cells assessed

Illustration · sample data

Generate tests

Unit and integration tests

Live

Writes pytest, Jest, JUnit 5 and Go tests for the files you choose, plus characterisation tests that pin current behaviour.

How it's checkedTests may only import symbols that exist. Python and TypeScript suites run in a sandbox; Java and Go are marked generated only.

In · Source filesOut · Test files with measured results

Test generation· payments-servicerun #1042

test_refund_handler.py · 14 tests14 passed
RefundServiceTest.java · 6 testsgenerated only
Line coverage, Python82%
Imports checked against real symbols0 invented

Illustration · sample data

Generate tests

End-to-end tests

Live

Writes Playwright, Cypress or Selenium (Java or Python) suites for the journeys and URL you give it, including behind login.

How it's checkedSelectors come from a live inspection of your app and every cited selector is checked against the page. Suites ship with config and run instructions.

In · Journeys, URL, repoOut · Runnable suite

NextAppium for Android and iOS

End-to-end suite· Playwrightstaging.yourapp.com

approval.spec.ts · 3 journeysgenerated only
Selectors found on the live page18 of 18
Lint: no hard sleeps, no empty assertsclean
playwright.config.ts · RUN.mdscaffold added

Grounded behind login with your saved session

Illustration · sample data

Generate tests

Contract tests

Live

Writes API tests from your OpenAPI or Swagger spec, one file per tag, covering every documented status code.

How it's checkedThe spec is the source of truth, not the model's guess about your API.

In · OpenAPI spec, live APIOut · Contract test files

NextGraphQL contracts and a mock server

Contract tests· openapi.yaml3 tags

POST /refunds · 201, 400, 409, 4224 of 4 codes
GET /refunds/{id} · 200, 4042 of 2 codes
PATCH /refunds/{id}/approve · 200, 4032 of 2 codes
DELETE /refunds/{id}not in spec

Illustration · sample data

Generate tests

Functional and BDD

Live

Turns user stories into tests: story-driven pytest, or real Gherkin with step definitions for pytest-bdd, cucumber-js or cucumber-jvm.

How it's checkedScenarios carry requirement tags, so the traceability matrix can follow them. pytest-bdd runs here; Cucumber is generated only.

In · Stories from a file, upload or the codeOut · Tests and .feature files

refund_approval.feature· pytest-bdd6 scenarios

Scenario: refund over the limit@REQ-12
Scenario Outline: 4 example rowsfrom test data
pytest-bdd run6 passed
cucumber-jvm step definitionsgenerated only

Illustration · sample data

Run against your app

Live UI test

Live

Runs a journey written in plain English in a real Chromium browser against staging or production.

How it's checkedThe verdict comes from the assertions, not from how many steps ran. A broken selector is repaired once and reported.

In · URL, journey, optional sessionOut · Step screenshots and verdict

Journey · refund approval· Chromiumstaging

Signed in as ops.managerpass
Entered 12,500 on charge ch_7f21pass
Approval banner shownpass
Approve button selector repaired oncerepaired

Verdict from 3 assertions: pass

Illustration · sample data

Run against your app

Visual regression

Live

Pins a baseline the first time and compares every later run pixel by pixel.

How it's checkedMissing screenshots show as not compared, never as a match.

In · URL, optional journeyOut · Diffs against the baseline

Visual check· refund journeybaseline 12 Sep

Screen 1 · refund formmatch
Screen 2 · approval bannerdiff 2.4%
Screen 3 · confirmationnot compared

Screen 3 had no current screenshot

Illustration · sample data

Run against your app

Page health

Live

Collects failed requests, mixed content, console errors and broken links, with no AI involved.

How it's checkedA page where nothing was observed reports no signal instead of a clean bill.

In · URLOut · Health report

Page health· /refunds142 responses

GET /api/fx-rates returned 503failed request
Image over http on an https pagemixed content
Link /help/refunds returns 404broken link
Console errorsnone

Illustration · sample data

Analyse code

Repo snapshot

Live

Runs test generation, bug detection, security and impact analysis in parallel over a repository or a set of changed files.

How it's checkedOne agent failing never blocks the other three, and each result carries its own label.

In · Repository or changesOut · Four reports in one run

NextGitLab and Bitbucket, alongside GitHub In build

Run #1042· payments-service4 agents

Tests · 20 written14 measured
Bugs1 open
Security1 high
Impact · Java callersinconclusive

Illustration · sample data

Analyse code

Bug detection

Live

Reads the code across twelve bug categories and proposes a fix for each finding.

How it's checkedThe code is read on its own first, then checked against complexity, the call graph and static-analysis hits. Files it didn't reach are listed.

In · Source filesOut · Findings with file, line and fix

Bug findings· payments-service3 findings

refund_handler.py:212 · null merchant_idnull safety
approvals.py:88 · limit compared with >logic
ledger.py:140 · file handle never closedresources

2 files past the batch limit, listed as not analysed

Illustration · sample data

Analyse code

Security scan

Live

Static analysis, dependency CVEs, leaked secrets and, when you give a URL, a non-destructive DAST scan.

How it's checkedSemgrep and Bandit run when present. A stage that couldn't run says "not scanned", never "clean".

In · Repo, optional URLOut · Findings mapped to OWASP and CWE

Security· payments-serviceSAST · CVE · secrets · DAST

search.py:48 · SQL built from input · CWE-89high
setuptools below 70.0 · CVE-2024-6345high
config.py:12 · access key in sourcesecret
Missing Strict-Transport-Security headerDAST

Illustration · sample data

Analyse code

Impact analysis

Live

Shows which callers, modules and tests a change can reach, with a risk score and the order to run tests in.

How it's checkedBuilt on resolved imports for Python, TypeScript, Java and Go. With no real diff the risk is N/A, not "low".

In · Changed filesOut · Blast radius and run order

Blast radius· refund_handler.py3 files changed

Direct callers3
Transitive callers5
Run first: tests/refunds, tests/ledgerrun order
Java service: explicit imports onlyinconclusive

Illustration · sample data

Analyse code

Custom review

Live

Reviews code against the dimensions you pick, or ones you describe.

How it's checkedEvery finding cites a file and line and a reference such as a PEP, a CWE or OWASP.

In · Code, your dimensionsOut · Referenced findings

Custom review· error handling, randomness3 findings

approvals.py:61 · bare except hides errorsPEP 8
tokens.py:22 · random used for tokensCWE-330
upload.py:40 · no size limit on uploadOWASP A04

Illustration · sample data

Analyse code

Code structure

Live

Maps imports and calls, finds dependency cycles, and ranks hotspots by fan-in and fan-out.

How it's checkedComputed from the code, with no AI in the graph itself.

In · RepositoryOut · Call graph, cycles, hotspots

Structure· payments-service64 modules · 186 edges

refunds → ledger → refundscycle
refund_handler.py · imported by 14 moduleshotspot
utils/money.py · imported by 22 moduleshotspot

Illustration · sample data

Diagnose failures

Bug tracer

Live

Takes a stack trace or bug report, separates root cause from symptom, and proposes a before-and-after fix.

How it's checkedEvery frame is resolved to a real file in your repository.

In · Stack trace or errorOut · Causal chain and fix

Bug trace· KeyError: 'merchant_id'7 of 7 frames resolved

ledger.py:140 · KeyError raisedsymptom
refund_handler.py:212 · split charges drop the merchantroot cause
Use primary_merchant_id, fall back to first splitfix

Illustration · sample data

Diagnose failures

Failure intel

Live

Triages a whole test-run report: groups failures by cause and splits product, test, environment and flaky.

How it's checkedReads JUnit XML, pytest and Jest output. Flaky is marked suspected until reruns confirm it.

In · Test reportOut · Failure clusters and causes

Nightly #311· JUnit report23 failures, 3 causes

Payment sandbox returned 503 · 14environment
Approval banner test id renamed · 6test
Rounding on split refunds · 3product
Search results order · 1flaky suspected

Illustration · sample data

Performance

Performance insight

Live

Reads k6, JMeter, Gatling, Locust or CSV results and says whether the run is valid, where the bottlenecks are, and its shape.

How it's checkedAn SLO verdict appears only if you set a threshold. Anything unmeasured is N/A, never zero.

In · Load-test resultsOut · Validity, bottlenecks, SLO

Load test· k6 summary20 min · 400 users

Run validityvalid
POST /refunds · p95 1.8 s, SLO 1.5 sfails SLO
Run shapespike
p99 latencyN/A · not in report

Illustration · sample data

Performance

Performance root cause

Live

Maps a bottleneck to the code most likely behind it.

How it's checkedFindings stay hypotheses until a person confirms them. A hotspot is confirmed only by a profiler frame in your code.

In · Bottleneck, profile, repoOut · Ranked hypotheses

Root cause· POST /refunds is slowpy-spy profile

ledger.py:140 · 38% of wall timehotspot confirmed
N+1 query in approvals.py:52hypothesis
Serialisation in api/views.py:77hypothesis

Hypotheses wait for a person to confirm or reject

Illustration · sample data

Coverage and traceability

Requirements and code

Live

Marks each requirement implemented, partial or missing with code evidence, and flags code no requirement asked for.

How it's checkedEvidence is cited from the code, not inferred from file names.

In · Spec and repoOut · Alignment score and gaps

Alignment· BRD v3 vs main81% aligned

REQ-12 · approvals.py:40implemented
REQ-15 · partial refundspartial
REQ-21 · refund reasonsmissing
export_csv() · no requirement asks for itorphan code

Illustration · sample data

Coverage and traceability

Requirements and tests

Live

Matches requirements to your existing tests and judges whether each is verified, shallow, inferred or uncovered.

How it's checkedA tag is treated as a claim, not proof. The matrix downloads as a real Excel RTM.

In · Requirements and testsOut · Traceability matrix

NextXray, Zephyr and Azure Test Plans export In build

Traceability· payments-platform212 requirements

PAY-114 · 14 UI and 6 unit testsverified
PAY-118 · 1 unit testshallow
PAY-121 · no testsuncovered
test_misc.py tagged REQ-30, which doesn't existdrifted tag

Download as an Excel RTM

Illustration · sample data

Coverage and traceability

Suite optimiser

Live

Finds assertion-less, skipped and redundant tests, and requirements covered many times over.

How it's checkedAssertions are detected from the code's structure, so comments can't fool it. It recommends and never deletes.

In · Test suiteOut · Clean-up list

Suite optimiser· tests/1,240 tests

test_utils.py · 7 tests assert nothingassertion-less
4 tests skipped since Marchskipped
3 near-identical login testsredundant

Recommendations only, nothing is deleted

Illustration · sample data

Knowledge and insight

Codebase Q&A

Live

Answers questions about your code from an index you build on demand.

How it's checkedAnswers cite file and line and label anything inferred. An unindexed repo says so.

In · QuestionOut · Cited answer

Q&A· "Where is the refund limit set?"indexed

config/limits.py:8 · REFUND_APPROVAL_LIMIT = 10000cited
Read again in approvals.py:40cited
Can be overridden per merchantinferred

Illustration · sample data

Knowledge and insight

Documentation

Live

Writes README, architecture, API and module documents from the code.

How it's checkedWritten to a separate output folder, never into your repository.

In · RepositoryOut · Markdown documents

Documentation· payments-service4 documents

README.mdwritten
ARCHITECTURE.mdwritten
API.md · 14 endpointswritten
MODULES.mdwritten

Saved to an output folder, not your repo

Illustration · sample data

Knowledge and insight

Project dashboard

Live

Rolls every repository in a product into one view, with history and trends across runs.

How it's checkedEach figure says how many repositories it rests on. Unmeasured is N/A.

In · All runs in a projectOut · Dashboard, history, trends

payments-platform· project dashboard4 repositories

Requirements verified · 3 of 4 repos78%
Open security findings1 high
notifications · coverageN/A
Requirements verified, 8 weeks+12 points

Illustration · sample data

Knowledge and insight

Cost analytics

Live

Shows real token usage and spend per run, module and project.

How it's checkedCounted from actual calls. A model with no known price shows N/A, not $0.

In · Every AI callOut · Usage and cost

Cost analytics· Septemberby module

test-gen · strong tier$2.20
threat-model · fast tier$0.18
Run #1042 · 412k tokens$3.10
internal-model-xN/A · no list price

Illustration · sample data

Live

Project dashboard and analytics.

Group a product's repositories into a project, and the dashboard takes the latest run of each check in each repository. Coverage, bugs, security and impact sit side by side, and every figure says how many repositories it rests on. A repository that wasn't measured shows N/A, so an average can't hide it.

Coverage you can quoteRequirement coverage and test health per repository, with "3 of 4 measured" beside the number instead of a blended guess.
History across every runCoverage, findings and test health plotted run by run. A run that measured nothing leaves a gap, not a drop to zero.
Analytics per product and repositoryTrends over weeks and releases, so a regression shows up the week it happens.
Run history in plain wordsEach run says what it found, such as "2 bugs, 1 threat" or "78% of requirements verified", not just "completed".

payments-platform· project dashboard4 repositories · last run 9 min ago

Requirements verified

78%3 of 4 repos

Open security findings

31 high

Test health

94%4 of 4 repos

Repository	Coverage	Bugs	Security	Impact
payments-service	81%	1	1 high	medium
checkout-web	74%	0	0	low
ledger-api	79%	2	2	high
notifications	N/A	0	0	N/A

Requirements verified · last 8 weeksmeasured runs only

W31W32W33W34W35 · N/AW36W37W38 · 78%

#1042	on demand · payments-service	1 bug · 1 threat
#1041	nightly · checkout-web	88 UI tests passed
#1039	load report · payments-service	N/A · no k6 report

Illustration · sample data

How a result is made

The AI judges. The platform checks the judgement.

This is the part most tools skip. A model can say anything, so nothing it says becomes a result until the platform has checked it against your code and seen what ran.

1 · Inputs
Your material
Source code, requirements, OpenAPI specs, CI reports, load results, a running URL.
2 · AI
Judgement
Extracts, classifies, designs tests, diagnoses. Routed to the model tier you set.
3 · Platform
Verification
- Every cited file and line resolved
- Selectors checked on the live page
- Framework and assertion gates
- What can run is run
4 · Label
Evidence state
Measured, generated only, inconclusive or N/A, decided by step 3.
5 · Output
Your tools
Test files ready to commit, findings cited to file and line, an Excel traceability matrix.

Bring your own model

Your models, your keys.

Anthropic, OpenAI, Google, or any OpenAI-compatible endpoint, including a gateway in front of Bedrock or Azure. Give a cheap fast tier to classification and a strong one to test design. Every run records which model did the work, and your provider bills you directly.

# config/modules.yaml · read live, no restart
# the provider is detected from the model name
default_model: ""            # "" = the platform default
model_tiers:
  fast:   gemini-3.5-flash-lite
  strong: claude-sonnet-4-5
modules:
  test-cases:    { enabled: true,  model: fast }
  test-gen:      { enabled: true,  model: strong }
  bug-detection: { enabled: true,  model: strong }
  threat-model:  { enabled: true,  model: strong }
  performance:   { enabled: false }

Roadmap

What we're building next.

Customers help set the order in a monthly release review. Alongside each release we keep working on accuracy, AI cost per run, speed and scale.

01 · Next

Run what we generate

Playwright, Selenium, JUnit and Go suites run in the platform
GitHub Actions and Jenkins steps
Two-way Jira, scheduled runs
Roles, API keys, audit trail, branding

02 · Then

Your tools, your repo

Cloud grid execution
Test manager with Jira and Azure DevOps
ServiceNow and ALM export
Accuracy benchmark on your journeys

Mobile and assistants

Appium for Android and iOS on grid devices
Sahasa.AI inside Claude Code, Cursor, Copilot
Manual runner linked to the matrix
Single sign-on

API breadth, video to test

GraphQL contract tests, mock server
A recorded journey turned into a suite
Load-test creation for k6 and JMeter
Import from TestRail, Zephyr, Xray, qTest

Complex journeys and load

Branching and cross-app flows
Event-driven and async API tests
Load tests run against baselines and SLOs
Release-readiness view

Scale and packaged apps

Salesforce, Dynamics and SAP Fiori
Distributed runs on your runners
Core Web Vitals and performance alerts
Dashboard v2, SOC 2 readiness

Not on the plan: a device farm, a proprietary step language, a full ALM, desktop or TV apps.

Next step

Bring one repository.

We'll walk you through Sahasa.AI on a sample project and talk through how it would fit your stack. If it looks useful, we can scope a pilot together.

01
A short call. Your stack, your frameworks, and where quality hurts today.
02
A demo. The platform on a sample project, and how it would connect to your tools.
03
A pilot, if it fits. Scoped with you around one service.

About thirty modules. Turn on the ones you need.

Every module, and how each one is checked.

Requirements

Testability

Test scenarios

Test cases

Test plan

Test data

Threat model

Unit and integration tests

End-to-end tests

Contract tests

Functional and BDD

Live UI test

Visual regression

Accessibility

Page health

Repo snapshot

Bug detection

Security scan

Impact analysis

Custom review

Code structure

Bug tracer

Failure intel

Performance insight

Performance root cause

Requirements and code

Requirements and tests

Suite optimiser

Codebase Q&A

Documentation

Project dashboard

Cost analytics

Project dashboard and analytics.

The AI judges. The platform checks the judgement.

Your models, your keys.

What we're building next.

Run what we generate

Your tools, your repo

Mobile and assistants

API breadth, video to test

Complex journeys and load

Scale and packaged apps

Bring one repository.