> For the complete documentation index, see [llms.txt](https://research.ambitiousimpact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://research.ambitiousimpact.com/ambitious-impact-eval/evaluative-criteria/evaluation-reports.md).
# Evaluation reports
Deep dive reports aim to rigorously examine an idea's prospects. We are no longer trying to refine a list of ideas; rather, we aim to equip decision-makers with as much relevant information as possible to decide whether to recommend an idea. The outputs of this stage are a deep dive report and a summary of key information inputted into a decision-making spreadsheet.
We have two main prioritized types of readers for our reports:
1. Decision-makers at AIM: Senior staff, researchers, and occasionally invited experts, who will gather information through the reports and vote/debate the merits of each idea.
2. CEIP incubatees: Individuals who will read recommended reports to understand the merits of a recommended non-profit intervention idea to prioritize it among others.
Our approach to these reports is flexible, responding to the specific research requirements of the research round and management needs. Each research tool/method and question we aim to address in our research aligns with the evaluative criteria discussed [here](/ambitious-impact-eval/evaluative-criteria.md).
### Standard Template and structure
The standard report template can be found [here](https://docs.google.com/document/d/1FaUEoUcTrX4mnWBs_OcRK4cZsbvB8jXAv5yafzwM4t0/edit?usp=drive_link). Round leads can amend the template as needed. Our [style guide](/other/style-guide.md) is also an important reference document for this stage.
### Process notes for a standard round
Before starting work across many reports, the round lead should ensure that the evaluation criteria and rubric are still relevant and useful.
Work-based on a coherent rubric and shared understanding of our priorities. One way to facilitate this is to conduct some early-stage work on the rubrics used for the [final-decision making spreadsheet](https://docs.google.com/spreadsheets/d/1CTzuSnAJxGoLDYWC38nFV7pmxG8COP8cZFwtHmYCOC4/edit?usp=drive_link). Researchers should understand the rubric, and use the language in it across their reports to clarify meaning (similar to how we should use the same words for verbal estimates of probability).
Report leads will be assigned to each report. Depending on the research round's staffing, leads may work with other researchers or individually. The round lead will assign reports based on the prioritization exercise undertaken in stage 4.
As always, report leads should stop working on reports (in consultation with the round lead and research director) if they identify a critical reason to do so. If an idea no longer looks promising to the report lead, they should trigger a discussion process with the leads to debate the merits of continued work on the idea.
### Quality Assurance and Review
Have regular reviews and check-ins. Don’t just work without a reviewer and rely on your advisor/manager/reviewer.
Each report should have a secondary reviewer. The author and reviewer should meet regularly (e.g., one short weekly meeting) to troubleshoot, check progress, and red team.
After each report is finished at stage 5, we will hold a meeting so that researchers can present their progress and ideas to the team and executive members. This aims to get some earlier stage views from final decision-makers and identify any concerns with an idea early on.
We aim to get at least one reviewer external to AIM who can read over and give feedback.
---
# 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://research.ambitiousimpact.com/ambitious-impact-eval/evaluative-criteria/evaluation-reports.md?ask=&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.