All resources
Discovery5 min read

Ground the AI in your real app

Feed Project Brain your documents, screenshots, and imported stories, and let app discovery map your running product, so generation uses real selectors and journeys instead of guesses.

A generated test is only as good as what the generator knew about your application. Give it a sentence and it improvises. Give it your requirements, your documents, and a map of your running product, and it builds from facts instead of guesses. That grounding is the difference between a demo that impresses and a suite you can run on Monday, and in AxonQA it comes from two things working together: Project Brain and app discovery.

Project Brain · grounding
Checkout requirements.pdf
12 sections extracted
PROJ-456 story + acceptance criteria
grounds generation
Product screenshots
UI facts read by AI
Knowledge healthGood
Project Brain grounds generation in your real requirements and app.

Project Brain is where your context lives

Project Brain is a knowledge base you feed. Put your requirements documents, your imported stories and their acceptance criteria, and even screenshots of the product into it, and it becomes the shared context Axon, your AI assistant, reads whenever it generates cases or automation. Instead of leaning on the wording of a single prompt, Axon draws on what your product is supposed to do, described in your own materials.

  • Requirements and specs, so generation reflects what correct behavior actually is.
  • Imported stories and acceptance criteria from Jira or Azure DevOps.
  • Uploaded documents and screenshots, read for the UI facts they contain.
  • The discovered structure of your app, kept alongside the rest as one context.

App discovery maps the product for you

Documents say what the product should do; app discovery records what it actually is. It explores your running application the way a careful new tester would, following links and flows and noting the pages it reaches, the forms and controls on them, and the journeys that connect them. The result is a living map of the real app, including the pages nobody remembered to document, and areas behind a login when you provide credentials.

Real selectors and real journeys, not inferred ones

Grounding changes what a generated test is made of. The page it starts on is a page that exists. The button it clicks is found the way that button is actually identified in the markup, preferring stable attributes like dedicated test ids over anything guessed. The path it walks is a journey a user can really take. When every part of a test traces to an observed fact, Axon is describing your product rather than improvising one, and the tests hold up against the real thing.

Why grounding pays off twice

Context saves you at both ends. Up front, tests are correct more often, because they reference elements that exist and flows that work, so far fewer fail for reasons that have nothing to do with your product. Later, maintenance is cheaper, because the same context that built a test helps repair it: when a locator breaks, the healer already knows the recorded alternatives for that element and can fix it deterministically instead of guessing again. Guessed tests are expensive because the guessing never stops; grounded tests spend the effort once, on real facts.

When you judge how any tests were generated, ask what they were grounded in. If the answer is a prompt, you have text shaped like tests. If the answer is your requirements, your documents, and a discovered map of your running app, held together in Project Brain and read by Axon, you have tests that know your product. Those are the ones worth trusting.

See these practices inside AxonQA

Generate structured test cases from your stories, then validate them with real runs on your own app.