Watches commits, specs and live errors
Connects to GitHub or GitLab, Jira and production logs. Formatting tweaks are ignored; changes to business logic, API contracts or error rates trigger a run.
assuregraph
Autonomous quality engineering for high-velocity software teams.
assuregraph turns every code change, product spec and production signal into verified unit, API and UI tests automatically. Eliminate QA bottlenecks, quarantine flaky builds and deliver auditable release proof inside your own cloud perimeter.
Scenario · PR #482 refunds.py3 behaviours · 1 high riskqueued
- if amt <= order.total:+ paid = ledger.refunded(order.id)+ if amt + paid <= order.total:
refund within the totalmedium risk
refund after a partial refundhigh risk · money out
refund of the exact totallow risk
Test requirements · REQ-3113 requirements · unit levelqueued
TR-1 A refund up to the remaining total succeedsunit
TR-2 Refunds after a partial never exceed the orderunit · high
TR-3 A refund of the exact remaining total succeedsunit
Test cases · 3 generated3 tests · validated and judgedqueued
test_refund_within_totalgeneratingvalidatedjudged ✓
test_refund_over_total_after_partialgeneratingvalidatedjudged ✓
test_refund_exact_totalgeneratingvalidatedjudged ✓
Execution · run 51282 of 3 pass · 1 failurequeued
2 of 3 pass · 2.6 s1 failed
test_refund_over_total_after_partialFAILED
Bug · AG-19 from the failing testAG-19 opened · trace attachedqueued
After a 50% refund, a full refund pays 150% of the orderdefect
Cause: the cap checks the request, not what was already refunded
Ownerpayments team · trace attached
Fix PR #483 · refunds.py#483 approved by a personqueued
- if amt <= order.total:+ if amt + paid <= order.total:
Reviewawaiting a personapproved · payments lead
Fix verified · run 51293 of 3 passqueued
3 of 3 pass · 2.3 sgreen
Ship · lineageshippedqueued
RequirementREQ-311cumulative cap
Changes#482 · #483fix included
Tests3unit
Run51293 of 3
EvidenceSignedjudge · review
Shipped · release gate open · lineage complete
Scenario · Jira PAY-77 refund policy v43 behaviours · policy changequeued
- Refunds allowed within 14 days+ Refunds allowed within 30 days+ Partial refunds count toward the cap
refund on day 29new behaviour
refund on day 31boundary
partial refunds in the caphigh risk · money out
Test requirements · PAY-773 requirements · api levelqueued
TR-1 A refund on day 29 succeedsapi
TR-2 A refund on day 31 is refusedapi
TR-3 Partial refunds count toward the capapi · high
Test cases · 3 generated3 tests · validated and judgedqueued
test_refund_day_29_succeedsgeneratingvalidatedjudged ✓
test_refund_day_31_refusedgeneratingvalidatedjudged ✓
test_partial_refunds_count_toward_capgeneratingvalidatedjudged ✓
Execution · run 5130 against current code1 of 3 pass · 2 unmetqueued
1 of 3 pass · 1.9 s2 failed
the code still enforces 14 days and ignores partialsunmet
Change request · AG-20 from the failing testsAG-20 opened · 2 requirementsqueued
TR-1 and TR-3 are not implementedopen
The tests are ready; the code has to catch up with the policy
Ownerpayments team · tests attached
Developer PR #491 · refund window and cap#491 approved by a personqueued
- WINDOW_DAYS = 14+ WINDOW_DAYS = 30+ cap -= ledger.partial_refunds(order.id)
Reviewawaiting a personapproved · payments lead
Fix verified · run 51313 of 3 passqueued
3 of 3 pass · 2.1 sgreen
Ship · lineageshippedqueued
RequirementPAY-7730-day window
ChangePR #491policy v4
Tests3api
Run51313 of 3
EvidenceSignedjudge · review
Shipped · policy v4 live · lineage complete
Where traditional test suites fall behind
Code-only test generators write passing tests for existing bugs
When a tool only reads the function in front of it, it assumes the implementation is right. If a developer forgot the partial-refund cap, the generated test forgets it too. assuregraph reads the Jira ticket and API spec alongside the diff, checking what the feature was meant to do.
Coverage drifts on the paths that matter
Checkout, login and core workflows change with every release while test suites stay frozen. Manual test authoring rarely keeps pace with release velocity, leaving busy production paths exposed.
Triage is manual and slow
Flaky tests and broken assertions are worked through by hand, one build log at a time. Engineers stop trusting a red build, re-run failed jobs until they pass, and releases slip.
From code or spec change to a ready pull request
- Change: commit, pull request, Jira spec, design or log signal
- Route: Policy Brain selects an approved model under configured rules
- Generate & verify: tests written, executed and checked before review
- Smart placement: placed at the fastest test layer that proves the behaviour
- Release proof: requirement to test to CI run to human approval
Picks the right model for the job
Routes across approved LLM endpoints, matching each task to the right model tier so frontier-model budget is never wasted on routine unit tests.
Runs its own work before asking for review
Every candidate test is executed against the build first. Any test that fails to compile, flakes, or misses the requirement is discarded automatically.
Opens a normal pull request
Writes unit tests where unit tests suffice, API tests where contracts matter, and UI tests only when necessary, delivered as a clean PR ready to merge.
Reports change failure rate, mean time to recovery, time to green, flaky reruns and test-suite acceptance out of the box.
What it looks like
Runs
Change failure rate4.1%
Mean time to recovery38 min
Time to green11 min
Flaky reruns6
Suite acceptance91%
| Run | Trigger | Tests | Result | Verdict |
|---|---|---|---|---|
| 5128 | PR #482 · refund cap | 3 generated | 3 pass | PR opened |
| 5127 | nightly | 2,418 | 2,415 pass · 3 fail | 2 flaky quarantined · 1 ticket |
| 5126 | PR #480 · login lockout | 4 generated | 3 pass · 1 fail | held · regression |
| 5125 | spec PAY-77 | 2 generated | pending code | ahead of the code |
| 5124 | PR #479 · search index | 6 maintained | 6 pass | merged |
Traceability
RequirementREQ-311Cumulative refund cap
ChangePR #482refunds.py · 3 lines
Tests3unit · placed by policy
Run51283 of 3 pass · 2.4 s
EvidenceSignedjudge ok · reviewed by a person
| Requirement | Tests | Last run | Evidence |
|---|---|---|---|
| REQ-311 · Cumulative refund cap | 3 | 5128 · pass | complete |
| REQ-298 · Login lockout after 5 tries | 4 | 5126 · 1 fail | regression held |
| PAY-77 · 30-day refund window | 2 | pending | awaiting code |
| REQ-240 · Search index rebuild | 6 | 5124 · pass | complete |
Coverage
| Path | Production traffic | Tests | Priority |
|---|---|---|---|
| checkout / refund | high | 11 | covered |
| auth / lockout | high | 4 | generate 3 tests |
| search / index | medium | 6 | covered |
| billing / invoice export | low | 1 | low priority |
| profile / avatar upload | low | 0 | watch |
Ranked by how often production hits the path against how much of it has tests. UI tests are only proposed where a lower level cannot prove the behaviour.
Setup
Sources
- GitHubconnected · read
- Jiraconnected · read
- CIGitHub Actions · read
- Logschoose a source
- Designsoptional
Your model
- Endpointyour tenant · in VPC
- Approved modelssmall · mid · large
- Outputpull requests only
Policy
route: accuracy: ≥ 0.95 latency: ≤ 2 s cost: prefer lowest data: no customer data to external placement: levels: [unit, api, ui] prefer: lowest that proves it review: human: refunds, auth, payments
Illustrative data. The screens show the product's views with example values, not results from a customer.
What is inside
Coverage Graph
Line coverage is a vanity metric if the busiest checkout path is barely tested. Coverage Graph combines code changes, Jira specs and real production traffic so revenue-critical workflows get tested first.
Policy Brain
Not every diff needs the slowest, most expensive model. Rules for accuracy, speed, budget and data residency are defined once; Policy Brain selects the right approved model for each task and logs the rationale.
Traceability Ledger
Links the Jira requirement to the pull request, the pull request to the tests, the tests to the passing CI run, and the run to the human reviewer. When an auditor or VP asks how a release was verified, the proof is a single link instead of a spreadsheet.
What it handles for an engineering team
- Spec-aware test generation. Writes new unit, API or UI tests whenever a pull request or Jira requirement lands, verifying what the feature is meant to do rather than just mirroring the code.
- Self-healing test maintenance. Updates broken or outdated tests automatically when a product or API contract evolves, opening a clean pull request so engineers stop fixing assertions by hand.
- Flaky-test quarantine & root cause. Spots tests that fail without a relevant code change, isolates the culprit (timing, test ordering or environment) and quarantines them so a red build always means a real bug.
- Traffic-weighted coverage ranking. Focuses test generation on the production user journeys and endpoints that carry the heaviest live traffic and highest business risk.
- Instant failure diagnosis. Attaches a clear root-cause summary to red CI runs before an engineer even opens the build log, cutting mean time to recovery.
- One-click audit & release evidence. Assembles requirement coverage, test execution results and human approvals into one verifiable record for release managers, CISOs and auditors.
Security and deployment
Approved models only
Runs on existing, approved LLM endpoints. Zero code, specs or customer data ever route through an unapproved external model.
Private cloud perimeter
Deploys inside a private cloud VPC or as an isolated single-tenant instance, keeping every artefact inside the security boundary.
Read-only by default
Connects with read-only access to GitHub or GitLab, Jira, CI and log streams. The only write path into a repository is a pull request for human review, with secrets masked throughout.
Full RBAC & audit trail
Role-based access control and a complete governance log covering every model call, generated test, CI run and pull request.
Try it on your own pipeline
assuregraph is in early access. For engineering teams where broken builds and manual test maintenance slow every release, join the waitlist or book a working session with eonai.