> 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/protocol/packet-audits.md). # Packet Audits Packet audits review observation history as one case. The goal is to judge the packet over time instead of treating every observation as isolated. More observation history gives the audit better context. An audit should not be a wall of text at the bottom of a packet. It should be a structured review of what the agents saw, what they disagreed on, and what the judge decided. The user should be able to understand the audit without reading raw backend output. ## Audit View A useful audit view should show: * Evidence * Lead agent reasoning * Skeptic agent reasoning * Judge decision * Final action or recommendation The judge should be able to reference prior audits so repeated issues can be recognized across tokens. ## Why Audits Exist Audits are how Dopameme improves its own reads. If the system repeatedly misses the same kind of evidence, the audit trail should expose that. If a read was correct for the wrong reason, that matters too. The point is not to produce a wall of text. The point is to turn review into better future behavior. ## How Audits Feed Learning The audit history should become part of protocol memory. If a judge sees the same problem across multiple packets, that repeated weakness should matter. For example, if several audits show that holder concentration was underweighted before breakdowns, future packets should make holder concentration more visible. If audits show that certain wallet clusters were repeatedly low quality, the wallet trust model should become more skeptical of that behavior. This is how Dopameme can improve without pretending every output was perfect. The protocol should be able to say, in effect: we saw this problem before, we judged it, and the next read should account for it. ## What Good Audit Output Looks Like Good audit output is organized by role: 1. The lead agent explains the strongest case for the read. 2. The skeptic agent challenges missing evidence, weak assumptions, and bad framing. 3. The judge decides what should be accepted, rejected, or watched. 4. The packet records the decision so future scans can use it. That structure turns review into actionable memory instead of a long transcript. --- # 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/protocol/packet-audits.md?ask=&goal= ``` `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.