> 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/other/our-prioritization-funnel/stage-1-process-design-learning-and-brainstorming.md). # Stage 1: Process design, learning and brainstorming {% stepper %} {% step %} ### Scope the cause area by writing a background note The note should establish: * A problem or impact statement: a motivational note on why this cause area matters, why we should care, and the goals of the research process. * The scope: A well-defined scope statement that clarifies what is to be researched and what falls within and outside the scope of the round. Even within a broad cause area, we may want to consider some areas to be a focus (e.g., policy/direct/research/high-scale/etc.) and some out of scope. * Any adaptations required to the evaluative criteria and bar: Adapt the evaluative criteria described here to the research round. Consider: what is the standard charity in this space that new talent could go work out? What is the bar that funders are looking to beat? What has AIM done in the past? * A metric to use; consider DALYs, WELBYs, Suffering-adjusted Days (SADs) (animals), lives saved, BCR, $ moved, growth impact, etc. {% endstep %} {% step %} ### Broad reading and cross-applicable research Broad reading and research - as you read, list ideas in the idea spreadsheet (see below). As you read, make a note of experts that it may be good to reach out to for the brainstorming stage (or later) 5-30 minute presentation to the team on research done (optional) – when writing a presentation for others in the team, focus on conveying your understanding of the topic, your sense of the theory of change for a topic, and your take on critical uncertainties. Focus less on putting across context or key background information and facts. Consider contacting subject matter experts for an initial conversation into key topic-level uncertainties. Ask them for ideas. {% endstep %} {% step %} ### Generate charity ideas This step aims to develop a long list of potential ideas to investigate. Ideas can be sourced through: * Brainstorming (individual, group) * Stakeholder contributions (AIM staff and community experts) * Remember to check the scratchpad (private) where random ideas await rebirth. No bad ideas(ish) – if you have an idea but don’t think it can win, but it is interesting, feel free to list it anyway. Maybe others will have a better version of that idea. If we get many ideas from experts that need time to filter, then we spend less time internally generating ideas. {% endstep %} {% step %} ### Long-list clean-up Categorize ideas: * Make sure idea titles are descriptive and clear, ideally describing the theory of change (ToC) of the idea in a sentence. * Double up, split, and delete ideas to manage the list. Feel free to delete silly ideas. * Aim for as much clarity as possible in each idea to increase the chances that raters aren’t comparing apples to oranges. * Track where / who each idea came from: This is important as we want to be able to thank and acknowledge contributors (especially if outside of AIM), and to evaluate where the best ideas come from. * Before moving on to stage 2, one researcher should spend \~1 hour excluding duplicates, merging where obvious, and re-categorizing. The researcher should also ensure that all ideas have a clear scope and description. Unique numbering: Each idea should have a unique number associated with it. {% hint style="info" %} Each idea should be tagged according to mechanism and target outcome (as per our [taxonomy](/explainers-and-house-views/our-charity-taxonomy.md#id-2__target_outcome___mechanism)). If an idea has multiple potential mechanisms, it should be duplicated and assessed separately. {% endhint %} {% endstep %} {% endstepper %} --- # 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/other/our-prioritization-funnel/stage-1-process-design-learning-and-brainstorming.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.