> For the complete documentation index, see [llms.txt](https://dopameme.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dopameme.gitbook.io/docs/using-dopameme/operator-reads.md).

# Operator Reads

The operator read is the main explanation layer on a token page.

It explains what matters now, what changed, key levels, likely consequences, and where evidence is incomplete.

The read should feel like a focused market brief, not a backend dump. Evidence scan packets, market-context blocks, and raw data objects are important to the system, but users should see the interpreted result: what matters, why it matters, and what would change the read.

## Good Operator Reads

* Use the latest packet when available
* Fall back to a fresh scan when no packet exists
* Avoid raw system noise
* Explain levels in context
* Make uncertainty visible

## What To Look For

**What matters** should summarize the most important current evidence.

**What changed** should compare the current scan against earlier context when available.

**Levels** should identify relevant chart areas, not random numbers.

**Consequence map** should explain what likely matters next if price accepts, rejects, or breaks down.

The goal is not hype. The goal is a useful read.

## Latest Packet First

When a useful packet exists, the operator read should be based on that packet.

That keeps the token page connected to protocol memory. The user is not just seeing a fresh one-off scan. They are seeing the latest structured interpretation of the token, informed by what Dopameme has already recorded.

If no packet exists, Dopameme can scan and present the best available read. Once that scan becomes a packet, future reads should compare against it.

## What The Read Should Hide

The operator read should not expose backend clutter.

Raw scan evidence, packet internals, market-context blocks, and audit transcripts are useful behind the scenes, but they should only surface when they improve the user's decision. The visible read should be clean, structured, and easy to act on.

That means the token page should prioritize:

1. Current thesis.
2. What changed.
3. Key technical levels.
4. Consequence map.
5. Holder and wallet context.
6. Clear limitations.

The protocol can be complex. The user-facing read should make that complexity usable.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://dopameme.gitbook.io/docs/using-dopameme/operator-reads.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.