> 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-2-quick-prioritization.md).
# Stage 2: Quick prioritization
This stage relies on aggregate rapid scores from reviewers that provide intuitive scoring to ideas and may do some light desk-based research for a handful of minutes. The idea is that aggregate scores and review meetings where those scores are discussed help narrow the list and exclude underperforming ideas.
{% stepper %}
{% step %}
### Prepare rubric
Prepare a simple rubric for scoring to help researchers think through the key aspects of each idea and ensure that scores mean roughly the same for all researchers.
See rubric suggestion here.
{% endstep %}
{% step %}
### Test
Run through stage 2 with about 5-20 ideas chosen randomly and see if it works well before running it fully. Set a time for how long each researcher should spend on each idea. 1 to 15 minutes per idea per person, depending on the timings of the round.
{% endstep %}
{% step %}
### Independent reviews
One reviewer looks at the idea at a time, if the first reviewer rejects the idea, then the idea goes to an arbiter. To pass, an idea has to be approved by both reviewers, or rescued by the arbiter.
{% endstep %}
{% step %}
### Review meetings
The round lead (or other) chairs a succession of meetings where ideas are organized by the average score across reviewers and classified into discrete criteria based on consensus and scoring relative to the alternatives:
* Yes
* Probably Yes
* Maybe
* Probably no
* No
* Merge
* Bump to S4/5
{% endstep %}
{% step %}
### Additional research and data cleanup
Some ideas may require some short follow-up research to clarify any critical uncertainties. Many ideas will have changed from the initial list; they may have been rewritten and combined and recategorized, there may be new ideas, and so on. Some work might be needed to turn this into a final spreadsheet that can be used in:
* Decision making. Each idea should be clearly separate and top ideas should be distinct enough to support future researchers to know what they are researching.
* Data analysis. We may want to analyse what ideas from what sources were successful, tracking all data points (source, category, idea number, etc) is useful.
* Sharing. We may want to share this with external stakeholders to get their feedback on the ideas list. (There may be a case for publishing this eventually)
{% endstep %}
{% step %}
### Final decision meeting
The round lead (or other) chairs a final meeting to select the top-performing ideas for stage 3. The number of ideas selected will depend on the round type and human resource capacity. Usually, the range of selected ideas is between 20% and 35% (\~ 50 ideas).
All long-listed ideas are to be considered based on their score and category.
The round lead should look out for red flags, such as a wide variation in the team members’ views, or views on ideas that regularly change or are very different in different meetings. Where there are red flags, consider putting in additional time to resolve uncertainties and seek expert input.
{% endstep %}
{% endstepper %}
🤖Using Consensus AI / Elicit / Perplexity can be very useful here. We also have a QP project in our internal GPT that has custom instructions that support scoring. We have not been able to get good automated scores from LLMs, but we will keep trying🤖
---
# 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-2-quick-prioritization.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.