From Intention to Evidence
This checkpoint brings together tester-army/e2e’s first operating model: a natural-language goal, a semantic observation, a bounded action, a settled screen, and a proof that the requested outcome is visible. The useful judgment is diagnostic. When a test fails, the reader should be able to ask which layer lacked evidence or authority instead of treating every red run as either an application bug or an “AI failure.”
The greeting example makes the chain concrete. The test asks an agent to get the app to greet Grace. The semantic surface must expose a name field and a Greet control. The runner must authorize and perform the chosen actions. The app must settle into a state that exposes the greeting. An exact status expectation or a bounded model judgment must then decide whether that state is present. A failure at any one of those points changes what the test can legitimately conclude.
A complete step is a chain of authorities
Each participant knows something different. The test author knows the intended outcome and the value that should be used. The model knows how to interpret the current observation and choose among available paths. The semantic engine knows how the current platform represents controls, states, geometry, and actionability. The assertion system knows how to compare a current or eventually settled state with a stated condition. The runner knows whether the operation stayed within budgets, policies, capabilities, and lifecycle boundaries.
No participant has the whole truth. The test author cannot assume that a button named in a design document is present on the current screen. The model cannot see a control that semantic capture omitted, and it cannot treat a secret value as ordinary text. The engine can perform a tap but cannot decide whether “the account is ready” is the right business outcome. An expect matcher can verify a status string but cannot choose a route through an unfamiliar dialog. The runner can reject an ambiguous target but cannot repair an application that exposes two controls with the same name.
That division is what makes the hybrid design coherent. In the greeting flow, the test author expresses the outcome as “get the app to greet {name}.” The model receives the current tree and can choose a field and a button. The engine translates that choice into a browser or device operation. The observation feed waits for the screen to settle. The test then asks for the exact status text. The final claim is stronger than the model’s description because it is supported by a current semantic state that an independent matcher can inspect.
The same chain works for a form with a negative outcome. Suppose the user taps Greet without entering a name. The agent can locate the button, but the important state is not “a button was pressed.” It is that an alert says “Enter a name first.” If the alert never appears, the action may have been blocked, the form may have accepted an empty value, the app may have rendered the message somewhere the chosen locator cannot find, or the expectation may name the wrong role. The test’s layers help separate those possibilities.