> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/build/testdrive/app-knowledge.md).

# Application Knowledge

What TestDrive has learned about your application, how facts get validated, and how to correct them

Every run records what it discovered about your application, and the workspace keeps it. That's what makes the tenth run faster and more accurate than the first: the agent isn't rediscovering where the login form is, it already knows.

The **Knowledge** tab is that record. On a new workspace it says *"Nothing learned yet. Runs record what they discover about the app here."*

## What Gets Learned

| Kind         | Examples                                                                             |
| ------------ | ------------------------------------------------------------------------------------ |
| **Route**    | The pages that exist and how you reach them                                          |
| **Flow**     | Multi-step paths — sign-up, checkout, inviting a teammate                            |
| **Auth**     | How this application is signed into                                                  |
| **Element**  | The controls that matter, and how to find them reliably                              |
| **Behavior** | How the app responds — what it validates, what it redirects, what it caches          |
| **Flaky**    | The parts that aren't reliable, so a test doesn't keep blaming your product for them |

## How a Fact Becomes Trusted

A thing observed once might be a coincidence. TestDrive tracks how confident it is in each fact.

| State          | Meaning                                      |
| -------------- | -------------------------------------------- |
| **Candidate**  | Observed, but not yet corroborated           |
| **Validated**  | Confirmed by evidence from more than one run |
| **Conflicted** | Later runs contradicted it                   |
| **Rejected**   | Ruled out                                    |

A candidate is promoted to **validated** automatically once evidence for it has come from at least **two distinct runs**. You can also mark a fact verified by hand, which validates it immediately — useful when you know something the agent has only seen once.

{% hint style="info" %}
**Only validated knowledge is used during a run.** A candidate fact is visible to you and available for review, but it can't quietly steer a test or a script build. That's the difference between a system that learns and one that accumulates mistakes.
{% endhint %}

## Correcting What It Learned

Open any fact and edit it. The panel is explicit about the weight of this: *corrections become the source of truth for future QA agents*.

Correcting knowledge is often the fastest fix for a test that keeps going wrong in the same way — the agent isn't confused about the test, it's confident about something untrue.

## Knowledge on a Run

Each run's **Knowledge graph** tab shows the concepts it used and the concepts it learned, which is the clearest picture of why a run behaved the way it did.

You can also download the workspace's knowledge as a bundle from the Knowledge tab toolbar.

## Next Steps

| Goal                                  | Documentation                                                    |
| ------------------------------------- | ---------------------------------------------------------------- |
| See knowledge in context of a run     | [Results & Evidence](/build/testdrive/results-and-evidence.md)   |
| Read or write knowledge from an agent | [TestDrive with Darcy](/build/testdrive/testdrive-with-darcy.md) |
| Improve the tests that produced it    | [Tests & Scripts](/build/testdrive/tests-and-scripts.md)         |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.darcyiq.com/build/testdrive/app-knowledge.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.