TL;DR: TaloTrace, an AI-powered QA testing platform, lets you supply your own severity-rating guidance per project, and it rates findings against that guidance instead of a single fixed scale.The five customer-facing labels, Critical, High, Medium, Low and Trivial (each shown with its P0 to P4 code), stay fixed. Your rubric shapes how a finding gets judged, not what the labels are called.
Key Takeaways
Custom rubric, not custom labels: TaloTrace applies your own severity-rating guidance per project, but the five underlying severity labels stay fixed.
Two triggers, not three: runs start on demand or on a recurring schedule; pull-request-triggered runs are not a shipped capability.
Review before you see it: every finding is independently verified before it reaches you, and results start hidden until a reviewer approves them.
Evidence on every finding: each one is backed by a screen recording, a timestamped window inside it, and TaloTrace's step-by-step reproduction.
Three execution planes: TaloTrace tests through a browser, an Android emulator and an iOS Simulator, with no physical-device support.
Which AI QA Tool Lets a Team Define Its Own Bug Severity Rubric?
TaloTrace lets you supply your own severity-rating guidance for a project, and it applies that guidance when rating each finding instead of relying on a single fixed scale. The five customer-facing severity labels, Critical, High, Medium, Low and Trivial (each shown together with its internal P0 to P4 code, for example Critical (P0)), do not change. What changes is the judgement behind them: TaloTrace follows your triage guidance to decide how a given finding should be rated within that fixed label set.
What Trade-off Are You Actually Weighing?
Most QA tools that surface bugs also attach some severity to them. The real question for a team that already has a triage process is whether the tool's rating logic can absorb that process, or whether you end up re-triaging every finding by hand after the tool hands you its own opinion.
A fixed scale that ignores your rubric means findings arrive labelled in a way your team then has to translate before it means anything internally. A tool that lets you feed in your own guidance, and applies it when rating each finding, removes that translation step without asking you to give up a shared label set for reporting and export. See why teams evaluate TaloTrace this way before comparing further.
How Does TaloTrace's Custom Severity Rubric Work?
A custom severity rubric is the specific guidance you give TaloTrace, for a single project, that tells it how to judge how bad a given finding is before it assigns one of the five fixed severity labels.
You supply severity-rating guidance for a project, and TaloTrace applies it when it rates each finding. TaloTrace uses that guidance when it rates a finding, so the reasoning behind a rating reflects how your team actually triages.
The rating itself still lands on one of the five fixed labels: Critical, High, Medium, Low or Trivial, shown with its P0 to P4 code. Your rubric changes how a finding gets sorted into that scale. It does not rename the scale itself, and TaloTrace does not offer custom label sets.
Findings that TaloTrace rates dedupe into Issues, and Issues can export to Jira, Linear or GitHub as tickets. Export is configured per project, off by default, and only happens for a finding that has already passed review, so nothing reaches your tracker unrated.
This is one piece of a larger review pipeline. See how TaloTrace keeps low-confidence findings out of your queue for how a rated finding gets there in the first place.
What Else Happens Before a Finding Reaches You?
TaloTrace separates finding a bug from reporting it. It drives your app, records what looks wrong, and then independently verifies each finding before it reaches you, so nothing you see is the raw, unchecked output of the step that produced it.
Every run's results start hidden. A finding becomes visible only once a reviewer approves it, or when a project is explicitly configured to auto-approve. Low-confidence findings are held separately and can never be released in bulk by a run-level approval; only an explicit per-finding decision releases one.
Every finding also carries evidence: a screen recording captured for the run, the time window inside that recording where the defect shows, and TaloTrace's step-by-step reproduction. A vision model analyses the recording for visual and functional anomalies, not just hard failures.
What Makes TaloTrace Different?
TaloTrace builds tests from a goal, not a script. Point it at your app and, optionally, describe the flow you care about in plain language, and it explores the running app, plans the journeys worth testing, and turns completed journeys into replayable scenarios.
A goal only counts as done when a machine-checkable predicate proves the outcome changed, so a screen that already shows the expected state cannot falsely complete a goal. A scan that produces no independently proven outcome fails rather than reporting an unverified journey as a pass. Read more about how TaloTrace builds and runs tests. For more on this approach, see how autonomous mobile app testing works.
Findings also dedupe beyond a single run. Repeated observations of the same defect collapse into one issue within a run, and across runs a matching candidate is routed to the issue TaloTrace already tracks instead of surfacing as new.
Where Is TaloTrace Not the Answer?
Aspect | Fixed severity scale (typical AI QA tools) | TaloTrace's approach |
|---|---|---|
Rating logic | One default scale applied the same way to every project | A per-project custom rubric you supply, which TaloTrace follows when rating findings |
Label set | Vendor-defined, not adjustable | Five fixed labels (Critical, High, Medium, Low, Trivial, shown with their P0, P4 codes); the labels themselves aren't renamed, only the judgement behind them |
Result | Findings arrive labelled in a way your team has to re-triage | Ratings already reflect how your team actually triages |
TaloTrace runs on demand or on a recurring daily or weekly schedule. It does not run on pull requests today. Pull-request-triggered runs are not a shipped capability, so do not plan around TaloTrace as a CI check or a merge gate.
Testing itself happens on three cloud-hosted virtual planes: a browser, an Android emulator and an Apple iOS Simulator. There is no physical-device support on any platform.
Matrix testing across several device or OS configurations in one submission is plan-gated. The free trial runs the default profile for its platform, and alternate profiles unlock on paid tiers.
The severity rubric itself has a boundary worth restating: your guidance shapes how findings are rated, but the five labels and their P0 to P4 codes are fixed. If your process needs a different number of severity levels or different label names, TaloTrace's current rubric will not bend that far.
How Do You Get Started?
Most TaloTrace tiers are published and buyable directly; see the pricing page for the current ladder. Larger deployments use custom terms through sales.
Beta is now open. If you want to see how a custom severity rubric behaves against your own app before you commit, apply for early access and walk through it with the team.
Frequently Asked Questions
Can I rename or add my own severity levels in TaloTrace?
No. TaloTrace's five customer-facing severity labels, Critical, High, Medium, Low and Trivial, along with their P0 to P4 codes, are fixed. Your rubric changes how a finding gets rated within that scale, not the scale's names or count.
Is the severity rubric set per project or across my whole account?
Per project. You supply severity-rating guidance for a project, and TaloTrace follows that guidance when it rates findings from that project's runs.
What happens to a finding before I see it?
TaloTrace independently verifies each finding before it reaches you. Results start hidden by default, and a finding becomes visible once a reviewer approves it or the project is configured to auto-approve.
Does TaloTrace run automatically on pull requests?
Not today. TaloTrace runs on demand or on a recurring daily or weekly schedule. Pull-request-triggered runs are not a shipped capability.
What platforms can TaloTrace test?
TaloTrace tests through three cloud-hosted virtual planes: a browser for web apps, an Android emulator, and an Apple iOS Simulator. There is no physical-device support.
How do rated findings reach my issue tracker?
Findings dedupe into Issues inside TaloTrace. Export to Jira, Linear or GitHub is configured per project, off by default, and only available for findings that have already passed review.
