It tells you when it isn't sure.
Automated sanity runs that flag ambiguous steps and unresolved preconditions instead of guessing — so when it reports a clean pass, that's exactly what happened. Nothing is rounded up.
“I'd want it to flag ambiguous cases and give me reliable video/log evidence, not claim full automation.”— stakeholder interview, product constitution §1 / §3
Five rules it doesn't bend, even for a cleaner report.
Every run is governed by the same constitution, whether the build is a mobile webview or a PC browser. These aren't aspirations — they're the acceptance criteria the system is built and tested against.
Never rounds up to a clean pass
If any part of a run was ambiguous, blocked, or required an assumption, the result says so. Partial or uncertain outcomes are reported as partial or uncertain — never dressed up as success.
No result without the receipts
A screenshot at every verification step, a full run video, logs for the run's duration, and build metadata. A result that ships without that evidence isn't considered a usable result at all.
Game state, set on purpose and on record
Account level, currency, feature flags, server time — set deliberately per run through named presets like new-player or high-roller, with the exact applied values recorded alongside the evidence.
“It needs to show exactly what it changed.”
A human signs off before Jira does
Similar failures are grouped into one evidence-linked candidate defect. A reviewer approves, rejects, or splits it — the system proposes, it never files a ticket unattended.
Every result finds its way back to its case
Run, evidence, and candidate defect all link back to the originating Xray test ID and build number — nothing is reported as a free-floating result disconnected from the case that triggered it.
“When XRAY-482 fails, I need the result, build number, video, and grouped defect linked back to that case.”
Bad authoring isn't a product defect
A step with no resolvable target is an authoring gap, not a bug — it's flagged and routed separately, so it never quietly inflates the defect count or masks a real regression.
From CI trigger to a filed Jira bug — five steps, all logged.
Build triggers a run
A CI webhook fires the configured stable test subset against the new build (manual trigger also supported).
Target & state applied
Device/platform and a named precondition preset are resolved from one shared config, then applied and recorded.
Real canvas, real objects
Playwright and Appium drive the actual rendered scene graph directly — object lookup, not pixel-guessing.
Evidence captured
Screenshot per step, full video, logs for the run's duration, and build metadata — every time, pass or fail.
Classify, group, review
Outcomes are never binary. Failures group into candidate defects a human reviews before anything reaches Jira.
Not a native engine — a WebGL canvas, driven directly.
The game renders through PixiJS/WebGL, not a Unity, Unreal, or Godot binary — so it doesn't rely on an accessibility tree or an engine SDK that doesn't exist for this stack. It reads the live scene graph and clicks real coordinates on real objects, across a mobile webview and a PC browser alike.
For the people who have to sign off on adopting this.
Join the waitlist and we'll reach out when there's a build ready to walk through. Prefer email? Write to us directly instead.