What is uatgpt.com and what does it help you do?

uatgpt.com is a working page for turning a product request into a written acceptance criterion, then keeping the expected and observed results side by side. It is a drafting and evidence aid, not a test runner: the site itself says the criterion frame "exposes missing parts; it does not decide whether a product meets them." Use it if you need to prepare acceptance evidence and a release conversation; it will not execute tests or produce a pass/fail on its own.

What the page actually does

The core action is a five-part frame. You write down:

1. Person — whose task is this?
2. Action — what changes?
3. Result — what can be observed?
4. Starting state — what is true before the action?
5. Coverage — which acceptance statement is being checked?

The page's own summary of the frame: "Write the actor, starting condition, action and visible outcome." A feature request becomes a useful criterion only when these pieces connect. The frame's value is that a missing piece becomes visible — for example, an outcome nobody can observe.

The site also draws a line that matters for how you use it: "A drafted test, an observed result and a release decision are different events. Keep each one tied to the product you actually checked." So the tool holds the draft and the observation notes; it does not invent a test outcome for you.

The stages it covers

The page organizes work into six stages, each with a "use the check" action and a local draft:

Two things to note. First, drafts stay on the page — the site labels them "Local draft" and "Private draft," so this is not a shared team workspace by default. Second, the stage names describe the artifact you produce, not an automated check; "Coverage" means trace links you record, not a coverage report generated from a test run.

Why "visible" is the recurring theme

The page argues that "a visible result is stronger" — "intuitive" cannot be observed the same way as a named message or a changed state. That is the practical test for whether a criterion is ready: can someone else see the outcome without asking you what you meant? If the answer is no, the frame is incomplete.

A concrete example of the gap: a request says the checkout should "feel fast." Under the frame, that fails the Result step until you name something observable — a specific state change or message a tester can record. The page does not tell you which threshold to pick; it only forces you to state one.

What it references and what it isn't

The page points to ISTQB acceptance testing, Cucumber Gherkin, and Playwright as its reference points, and notes that Playwright is about visible behaviour. Those are pointers for how to phrase scenarios and where observable outcomes come from — the page does not claim to run Gherkin or Playwright.

It also does not publish pricing or account details. Nothing on the page indicates whether drafts persist beyond the session or require a login, so treat "local draft" as exactly that until you confirm otherwise.

When it fits your workflow

• Good fit: you have a requirement in prose and need to convert it into an acceptance criterion with a checkable outcome; you want a lightweight place to record what you expected versus what you saw before a release conversation.
• Poor fit: you need automated test execution, shared team dashboards, or a system of record for test results across builds. The page is explicit that a visible result is stronger than a vague one, but it leaves running and storing results to your existing tools.

The fastest way to judge it is to take one real requirement and try to fill all five parts. If you get stuck on "Result," that is the frame doing its job — and a sign the tool suits the problem you have.