Community Driven RFPs

In DFR3 we started the process of Request for Proposal (RFP) -based project submissions. This was continued with 2 more RFPs in the Test Round and a pilot project for a Community-driven RFP with the topic of a SingularityNET & Deep Funding ‘Content Knowledge Graph’. 

With this experience in mind, we have been exploring ways to motivate and incentivize the community to actively participate in this process and to ensure high-quality outcomes. We discussed these ideas in the Town Hall / Listening session on Mar 14, 2024, which inspired us further to the processes outlined below. This is not a final definition, but an intermediate progress report of our emerging ideas on the topic. 

TLDR;
In this article, we explore a method where the specification of projects is separated from the development process, and the community can be involved more closely in the specification phase. This multi-step process will enable more people with different capabilities to contribute in a meaningful way AND at the same time ensure that the cost-to-value ratio of projects is optimized. 

Main differentiators and benefits of the (community-driven) RFP process

There are a few important aspects that make this process different than regular rounds and pools, and make it worthwhile to explore:

# Separation of ideation/specification vs. development
By separating ideation and specification from development, we can involve a richer collection of experts and enthusiasts in the ideation process. This will help us to ensure that the proposed solution is targeted at driving optimal value to the AI platform and related ecosystem. Without this separation, there is the risk that teams will request funding for things that are mainly self-serving or are more attuned to their capabilities than the actual needs of the platform and ecosystem

# Shifting community involvement from the final vote towards co-creation and ideation
By putting more emphasis on the ideation and specification phase and decoupling it from the development we can have a deeper involvement from the community during this phase. If desired or needed, the RFP owner can ask the wider community for expertise and support to help them in the specification process. Arguably, the right topic and a good specification are more important to the final impact of a project than the selection of the best development team. 

# Built-in filters and quality assurance.
Another driver of high-quality projects is having multiple filters and quality approvals throughout the process. This starts with selecting the best topics and ideas. There will be conditions and an approval process for the RFP completion. When the proposal submission period is over, the RFP team and/or the RFP Board will have the task to pre-filter the proposals, ensuring that any candidate that makes it to the final voting process will comply with the conditions of the RFP. This step may also filter out candidates based on more subjective criteria such as perceived experience, expertise, and ability to deliver. With these ingredients in place and less prominence of the final vote, we have the opportunity to decouple the entire process including the final vote from the regular rounds!

# Driving specialization in RFP specification vs development by allocating proper budgets
We may find that funding which is allocated to a good specification process brings just as much value as funding that is allocated to development. Of course, this will require conditions and quality standards for specification. We will learn how to define the conditions that guarantee high-quality RFPs, both from a business and a technical perspective. We can imagine a not-so-far-away future where some teams will specialize in ideation, exploration, and specification, while other teams specialize in a smooth and professional development process. Of course, this is not a given, and we will learn if individuals or teams are interested in specializing in this part of the process, and what compensation is reasonable.

# Allocation of higher budgets
With all these quality filters in place, it may be proper to reserve high-value grants for RFP-based proposals. We do see a continued value in regular open rounds, which have their own merit and may surprise us with projects from specialized, capable, and self-motivated teams. However, we can imagine that we will have a maximum reward in place for such projects, and at the same time open up the option of higher rewards for projects that go through the scrutiny of the multi-step RFP process. 

The process and the main participants

Below, I will sketch what the process might look like. Before doing so let me state the main participating entities.

Participants

  • The wider community: Everyone who likes to contribute, not limited to token holders.
  • The RFP Development team: This can be an individual, a team, or a collaboration of multiple teams and individuals, working together on the creation of the RFP. The RFP owner will be responsible for coordination, the distribution of the allocated budget among participants, and the final outcomes of the collaboration.
  • The All-Circles group: This refers to all members from the community-based operational layer of Deep Funding. Currently, this is around 20 people, divided over 4 Circles
  • RFP (advisory) Board: This group is still to be created. A group of senior professionals, hopefully including some SNET tech leaders. The deep Funding staff will be represented due to the budget responsibility. 
  • Expert Reviews & Voting Team' This is a new concept suggested by the community in a recent town hall. We can invite members to this group, based on their 'reputation' as value-adding contributors in the system. They can represent the wider community of token holders in making the final decisions in the RFP process. 

These groups will work together in a dynamic process to select and develop winning proposals in the DF program. See the following diagram for a schematic overview of tasks during the process: 

(Miro version )

Process steps

This is what the process could look like, supported by functionality on the platform:

  1. Ideation: The community (anyone) can put forward ideas they would like to see developed. Other community members can discuss the merits, give ideas and comments, and give a rating. (Perhaps we can think of some incentive scheme for anyone who is offering valuable feedback.)
  2. Selection: The All-Circles in coordination with the RFP Advisory Board will select ideas and topics that should be turned in to RFPs. Sometimes the Advisory Board can initiate a selection, and the All-Circles can give their consent (or challenge the decision), sometimes the All-Circles could initiate a selection and ask the RFP Board for consent. Both groups also have the responsibility to guard against undesired overlap and redundancy of ideas and projects. In the end, the RFP board will have the responsibility to balance the pipeline of new projects against the expected budget requirements and the importance and urgency of the ideas. 
  3. Conditions and reward definition: The RFP Board will list the conditions for the final RFP and offer a fitting compensation for the team that creates the RFP. Part of this reward could be allocated as a kickback fee once a proposal has been awarded by the community and/or once it has been completed, to incentivize further guidance during the proposal submission and development process. During this step, the idea owner can collect more interested people to help, and the RFP Board can also be instrumental in bringing people and teams together. The All-Circles will approve the budget based on consent, and the RFP owner will ultimately decide how the rewards are distributed among members of the RFP Development team.
  4. RFP development: The RFP is developed and during this process, the community can give feedback on the emerging specifications
  5. Approval and budget allocation: When done, the RFP Board will approve the RFP (or request further improvements). The RFP board will also assign a maximum budget for the proposals that are submitted to the RFP. Together with the RFP team, a submission period will be determined. The All Circles will approve based on consent.
  6. Filter best proposals: When the submission period is over, the RFP team (if not proposing themselves) will select the best-fitting proposals based on objective and subjective criteria. Alternatively, the RFP Board will take this role
  7. Final vote: The community, or the Expert Reviews & Voting Team will make the final decision on which team will be awarded for for the development.

Extending the system with partnerships

We can take this one step further by exploring ways of collaborative funding. 

Jointly funded projects with partners.

When engaging in a partnership with Deep Funding, an organization can decide to co-fund a project that will benefit both Deep Funding (by helping the AI platform grow) and the partner (by developing an AI-based solution which will be useful to the partner). Partner-based funding can have different shapes and forms but in the context of this article, we’ll focus on how partners can collaborate in the RFP process. 

Step One; RFP creation with partners:

Route A; starting with an idea: partners can submit their own ideas to get community feedback AND to have the idea adopted by an RFP team. This is an additional step, compared to the process of community-funded ideas outlined above. However, both in the case of partner-originated ideas and community-driven ideas, there is the possibility that the person who submits the idea is not available for the next step of RFP Development. This means that the process above should be extended with an extra step: Adoption of an idea by an RFP development team. 

In this scenario, an idea will first be selected for the next step of RFP development, by the RFP board and the All-Circles. It will then be marked as ‘Available for RFP development’. Multiple teams can submit their interest. The RFP Board can support this process by inviting teams to submit their interest or inviting multiple teams to collaborate on the RFP. Based on the popularity, the size, and the professionality of the team, as well as the complexity of the RFP, the RFP board will define a reward and conditions after which the RFP development team can get to work. 

Route B: Starting with a ready-made RFP: Alternatively a partner may already have the expertise in-house and know exactly what they want. In this case, they can skip the RFP creation phase completely, and publish their predefined RFP. They can still invite community feedback if so desired. 

Step Two: RFP budget allocation and proposal submission 

When the RFP is final, whether by route A or B, the RFP board will assign a budget, and the All-Circles can give their consent. By default both Deep Funding and the partner would both offer 50% of the funding, but we could deviate from this distribution if desired.

When proposals come in, the RFP development team or the RFP Board can still advise on the best proposals, but the final selection of suitable candidates would be up to the Partner. They can best decide which proposals have their confidence. After this, the Expert Reviews & Voting Team can make the final selection and award the winning team, thereby ensuring that the ‘voice of the Deep Funding community’ is part of the decision process.  

Projects funded completely by third parties

We can imagine a not-so-far-away future where this RFP program is attractive for third parties that would like to accomplish a certain goal. We can think of NGO’s or Government grants or corporates in need of some AI-based solution. They could leverage the expertise of the Deep Funding communities in specification tasks and/or apply the Deep Funding program for the selection of a good Development team. This way an arm of Deep Funding could develop into a procurement system for AI-based development work!

Obviously, when a third party completely funds a project, this party should also be able to decide independently who will be granted for the work involved, without dependency on a community vote. In this case, the Ideation step can be used to invite RFP development teams to submit their interest in RFP creation. The third party can select the best team, and guide the RFP development process. When done and approved, the third party can allocate a maximum budget, invite development teams, and select the best team to do the work.

What’s in it for Deep Funding?
You might ask why Deep Funding should facilitate this process for third parties. The answer is simple. For all projects done through the Deep Funding program, the main condition remains the same: 'Help the Decentralized AI-platform grow' **. This means that any solution that is funded by a third party would still be required to onboard and/or or utilize an AI service on the platform. 

What’s in it for a Third Party?

  • We expect that, over time, the Deep Funding program will attract a growing workforce of professional and capable teams both in the area of specification and of development. Any third party that uses the deep Funding program would thereby have access to these teams and their expertise
  • Third parties, especially NGOs or entities that are aligned with the mission and vision of SingularityNET can use their resources to support the development of beneficial decentralized AI. They can work with like-minded teams and people and leverage the AI services already on the platform, or contribute to a better decentralized AI infrastructure by onboarding new services themselves. 
  • Companies can use the program to comply with CSR / ESG  rules (Corporate and Social Responsibility / Environmental, Social, and Governance)
  • Companies can use the branding of Deep Funding and SingularityNET to their advantage, by contributing to our cause. 

** With the launch of Hyperon Alpha, we may extend the goal of Deep Funding towards ‘supporting the development of OpenCog Hyperon’. This will still help the platform grow by having Hyperon as a service on the platform but might be seen as a wider interpretation of this goal.

More information: