> 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 conditionally selected teams. It also explains how the results are shared and what comes next. #### 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 conditionally selected The Pilot aimed to fund around ten teams. As such, the ten highest-scoring proposals were conditionally selected first. Their combined requests left room in the budget for more. The remaining budget conditionally selected 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. #### 7. What's next? **Actual funding depends on completing onboarding.** The first payment is released only once all of the following are done: * team's KYB/KYC verification is approved; * team's written response to the panel's feedback is submitted; * onboarding call is scheduled where feedback and next steps are established; * the issues raised in project's decision scorecard are addressed to the program's satisfaction. If any of these is still outstanding, the first payment will be deferred until it is complete. If the program believes the issues raised in project's decision scorecard haven't been addressed satisfactorily, or onboarding can't otherwise be completed within reasonable timelines set out in onboarding schedule, it may not proceed with the next steps and may withdraw the conditional selection. --- # 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://docs.projectcatalyst.io/open-funding/decision/pilot-selection-process.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.