> For the complete documentation index, see [llms.txt](https://docs.projectcatalyst.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.projectcatalyst.io/open-funding/decision/pilot-selection-process.md).

# Pilot Selection Process

This page explains how 117 applications became twelve funded teams. It also explains how the results are shared.

#### 1. Curators narrowed 117 applications to 31

Curation took place while applications were still open. Fifty-two community curators reviewed the applications. They flagged the problems they found.

Every flag was checked. Teams could resolve confirmed flags before submissions closed. Proposals with confirmed flags still unresolved at that point were archived. Their teams received the full rationale and feedback privately at the time.

By the end of curation, 31 proposals remained.

#### 2. Panelists scored the 31 proposals

There were 35 active panelists, of which 28 were from the community and 7 were from the Cardano Foundation.

Each proposal was reviewed by 11 to 19 panelists. Some assessed the business case. Others assessed the technical case. Proposals were assigned to panelists at random.

Panelists scored [each question](https://drive.google.com/file/d/1P-sdqY_xkqfpAppsT9t8q8zYCbSO9Vs-/view) from 1 to 5. In total, 466 reviews were accepted that met minimum standard requirements. 

#### 3. Scores were adjusted for different scoring styles

Every proposal was reviewed by several people, and every reviewer has their own style: some rarely give top marks, others are generous by default. Proposals were assigned to reviewers at random, so which reviewers a proposal landed with was a matter of chance. If we simply averaged the raw scores, a proposal could rise or fall depending on who happened to review it rather than on its merits. To correct for this, we used a mean-centred scoring approach. 

For each question, we looked at how each reviewer scored across all the proposals they assessed and used that as their personal baseline. A proposal's score then reflects how it compared to that reviewer's typical assessment, not just the raw number they wrote down. A "good" from a strict reviewer and a "good" from a lenient one end up carrying the same weight. The corrected scores were then combined across the business and technical committees, and the highest-scoring proposals form the list you see.

#### 4. Scores were combined into one result

Each question has its [own weight](https://drive.google.com/file/d/1P-sdqY_xkqfpAppsT9t8q8zYCbSO9Vs-/view). Business questions make up 70% of the final score. Technical questions make up the other 30%.

#### 5. Twelve teams were selected

The Pilot aimed to fund around ten teams. As such, the ten highest-scoring proposals were selected first. Their combined requests left room in the budget for more.

The remaining budget funded two more proposals. These extra were chosen using a separate question every panelist answered but did not feed into the primary score: "Should this proposal be funded?" Only proposals meeting a minimum technical standard were considered.

#### 6. How results are shared

The public [results page](https://app.projectcatalyst.io/campaigns/6c4b4dd9-0000-5575-a5d3-d2ef6765893d/results) lists proposals in alphabetical order only. It does not rank them.

Every team that reached the decision stage can see its own results on the Catalyst platform. Teams see their score for each question. They see how those scores compare with the average across all 31 proposals. They also receive written feedback.

These results are shared privately. This gives each team space to take in the feedback and improve. The complete record is kept in case the process needs to be checked.

<br>


---

# 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://docs.projectcatalyst.io/open-funding/decision/pilot-selection-process.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.