> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading the results

> What a queued run, an empty failure list, UNTRUSTED markers, and a partial failure report actually mean when your agent reports back.

These come up in almost every session. Knowing them saves you from re-asking.

## An empty failure list tells you why it is empty

When your agent asks Peeps what is failing and gets nothing back, the answer is not just an empty list. It leads with **which of three things happened**, because they are not interchangeable:

<CardGroup cols={3}>
  <Card title="Outside your window" icon="clock">
    Tests *are* failing, but none of them failed inside the period asked about.
  </Card>

  <Card title="Nothing failing" icon="circle-check">
    Every test's most recent run passed.
  </Card>

  <Card title="No visible history" icon="circle-question">
    The project has no completed runs Peeps can see.
  </Card>
</CardGroup>

The first one carries the **exact instant of the most recent failure**, so your agent widens the window in one more call instead of guessing 7 → 14 → 30 days blind.

A healthy project and a project that has never run are different answers, and they lead you somewhere different. The notice says which one you got.

<Note>
  **"Recently" means the last seven days.** Ask about a recent period without naming a range and your agent bounds the search to seven days back. Say "in the last 30 days" or "ever" if you want something wider.
</Note>

### "Nothing is currently failing" is narrower than it sounds

Peeps reports one row per test whose **latest** run failed. A test that failed on Tuesday and has passed since is absent from that list at any window size — widening the range will never surface it.

So this answers *what is broken now*, not *what failed during a window*. If you want the second, ask for the batch run rather than the failure list.

## A queued run has not started yet

When your agent kicks off a test run, Peeps confirms the run is queued — not that it is underway. Your agent polls until it settles and reports back.

If Peeps cannot tell whether a run reached CI, it reports that rather than guessing, and it will not dispatch again. The run may already exist, so a retry risks running your suite twice.

## Verification and publication are separate

A fix can be **verified** — passed or failed — without being **live**. Publication is its own axis.

* A passed fix is published by a person in Peeps, not by your agent.
* For newly generated scripts, Peeps automatically attempts publication after generation. A generated script may still remain a draft, so your agent checks both axes per script.

## Some text is marked untrusted

Your application's output, test titles and steps, and Peeps's own analysis text can all appear inside `UNTRUSTED` markers. Agents treat anything inside them as data, never as instructions.

That is deliberate: a failure screenshot or a DOM snapshot is content your application produced, and it should not be able to steer your agent.

## Partial is not broken

Each part of a failure report says whether it is **available**, **pending**, **omitted**, **truncated**, or **errored**.

Truncated history means older runs exist beyond what was returned, not that something went wrong. If something is pending, wait and ask again.