> For the complete documentation index, see [llms.txt](https://productcommittee.docs.intersectmbo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-08-enterprise-delivery-partner-network.md). # RFP 08: Enterprise Delivery Partner Network Tender type: Request for Proposals Issued by: Cardano Product Committee / Intersect Research portfolio: Product Research Initiatives Final publication date, submission deadline, clarification window, expected project period, submission method, and contact will be confirmed on the Product Research Initiatives - Grants page before the call opens. *** ## 1. Executive Summary ### Strategic question What enterprise delivery partner network, certification framework, and go-to-market model would enable Cardano stakeholders to convert enterprise interest into implemented, supported, and measurable deployments? ### Evidence gap Cardano has enterprise-relevant infrastructure, ecosystem teams, and emerging enterprise and RWA opportunities. However, enterprise adoption depends on more than protocol capability, product interest, or pilot announcements. External clients usually need accountable delivery partners who can scope, implement, integrate, operate, support, and maintain solutions through procurement and production use. One of the most consistently cited barriers to Cardano enterprise adoption is the absence of a visible, trusted, and certified channel of delivery partners or system integrators. Cardano stakeholders do not yet have a decision-ready map of which firms can deliver Cardano solutions today, which sectors and regions they cover, what capabilities they can prove, what gaps prevent enterprise procurement confidence, and what type of certification or partner programme would attract and retain qualified delivery firms. The evidence gap is not whether a partner network sounds useful. The gap is what type of partner network would be credible, which firms could participate, what support and incentives they would require, what governance would protect quality, and which peer ecosystem models Cardano can adapt rather than invent from scratch. ### Decision unlocked This research should enable Cardano stakeholders to decide: * whether to create, fund, coordinate, or pilot a certified enterprise delivery partner network; * which partner categories should be prioritized, including specialist delivery firms, system integrators, consultancies, implementation agencies, regional delivery partners, and vertical specialists; * what certification criteria, partner tiers, training pathways, governance model, and quality controls should be used; * which geographies and sectors require urgent partner development; * whether co-funded implementation structures should be tested, and under what guardrails; * what prevents larger consultancies and system integrators from building a Cardano practice; * which pilot engagements, recruitment actions, enablement assets, or support mechanisms should be funded first; * what evidence should be required before Cardano stakeholders treat a delivery partner as enterprise-ready. ### Expected outputs The selected vendor will produce a partner landscape map, enterprise delivery capability model, partner certification framework recommendation, peer ecosystem reference-model benchmark, co-funded implementation model assessment, partner recruitment and go-to-market model, geography and sector gap analysis, larger-consultancy barrier analysis, training and enablement requirements map, partner governance and quality-control model, pilot engagement pathway, evidence threshold framework, executive decision memo, final research report, final presentation, public summary, and cross-RFP handoff memo. Vendors may combine deliverables where sensible, provided that every decision gate is answered and every required output is covered. ### Requirement priority The required core is to answer the decision gates with traceable evidence and produce the required decision outputs. Optional methods, templates, or stretch work should be separated from the core scope and budget. This RFP is not implementation delivery, enterprise sales execution, partner-program operations, legal advice, or generic partnership strategy. *** ## 2. Strategic Context The Cardano Product Committee has received funding to commission a portfolio of product research initiatives aligned with Cardano's long-term product direction and Strategy 2030 priorities. The purpose of the portfolio is to define the evidence Cardano needs before making product, adoption, funding, partnership, and strategic decisions. This RFP focuses on enterprise delivery partner capacity. Its purpose is to determine what kind of partner network Cardano would need in order to support external enterprise clients through scoping, procurement, implementation, integration, support, and production use. Enterprise adoption often requires an implementation channel. Buyers may not want to coordinate directly with protocol contributors, fragmented ecosystem teams, or unsupported open-source tooling. They may expect a vendor or delivery partner who can translate business requirements into architecture, manage delivery risk, support integrations, provide documentation, maintain service continuity, and remain accountable after launch. Cardano has some firms with relevant delivery experience, but the ecosystem does not yet have a clear global map of capability, sector coverage, regional coverage, procurement readiness, training needs, or certification standards. The research should determine whether Cardano can build a credible delivery channel from existing and recruitable firms, what partner categories are most realistic, and what investments would make the network useful rather than symbolic. The research should inform the Cardano Product Committee and the broader Cardano ecosystem, including enterprise adoption teams, RWA and government-market contributors, business development teams, infrastructure providers, grant allocators, delivery firms, system integrators, certification designers, and future research vendors. *** ## 3. Research Problem Statement Cardano lacks a decision-ready enterprise delivery partner network model. Current enterprise and adoption discussions can blur several different needs: * identifying a promising enterprise use case; * proving buyer demand; * building or configuring a technical solution; * integrating that solution into enterprise systems; * operating and supporting the deployment; * carrying procurement, accountability, and delivery risk; * creating a repeatable partner channel that can scale beyond one-off relationships. These are not interchangeable. A strong use case may fail if no delivery partner can implement it. A technically capable ecosystem team may not be suitable for enterprise procurement. A firm may claim Cardano familiarity but lack support capacity, integration experience, regulated-industry credibility, or geographic coverage. A certification badge may increase confidence only if it is tied to real delivery capability, governance, and customer outcomes. Cardano stakeholders need to know: * which firms can credibly deliver Cardano solutions today; * which firms could become credible with training, incentives, technical support, or certification; * which partner capabilities matter for enterprise procurement and production deployment; * which sectors and geographies are under-served; * which peer ecosystem partner models are relevant, including certification, co-selling, co-funding, implementation pathways, and quality controls; * what prevents larger consultancies or system integrators from building Cardano practices; * what partner governance model would protect enterprise trust; * which pilots should test the model before broader rollout. Without this evidence, Cardano risks: * pursuing enterprise opportunities without implementation ownership; * treating partnership announcements as delivery capacity; * creating certification that does not signal real readiness; * subsidizing consulting work without durable adoption outcomes; * relying on a small number of regionally concentrated firms; * losing enterprise opportunities because buyers cannot find qualified implementation partners; * duplicating adjacent research on enterprise readiness, government entry, use-case positioning, brand perception, or stablecoin/L2 dependencies; * failing to create a practical channel from enterprise demand to recurring on-chain usage. The selected vendor must close this evidence gap by producing a partner-network blueprint grounded in delivery-market evidence, enterprise buyer requirements, partner incentives, peer benchmarks, and decision-ready pilot recommendations. *** ## 4. Definitions For this RFP: **Enterprise delivery partner** means a firm or team capable of helping external clients scope, design, implement, integrate, operate, support, or maintain Cardano-related solutions in business, institutional, public-sector, RWA, regulated, or other enterprise contexts. **System integrator** or **SI** means a firm that integrates technology into enterprise systems, workflows, data environments, operational processes, or vendor stacks. For this RFP, SI includes global consultancies, regional integrators, specialist implementation firms, and applicant-justified alternatives. **Certified partner network** means a structured programme through which qualified firms are assessed, trained, recognized, supported, governed, and potentially co-sold or co-funded as delivery partners for Cardano-related enterprise opportunities. **Certification framework** means the criteria, tiers, evidence requirements, training requirements, renewal rules, governance controls, and quality standards used to determine whether a firm can be represented as Cardano enterprise delivery-ready. **Enterprise delivery readiness** means the degree to which a firm can support enterprise implementation needs, including technical capability, delivery management, integration experience, documentation, security and risk awareness, support model, sector experience, references, procurement fit, and accountability. **Partner tier** means a level or category within a partner programme, such as certified developer firm, implementation partner, enterprise delivery partner, regional partner, vertical specialist, or applicant-proposed alternatives. **Co-funded implementation** means an implementation funding structure in which cost, risk, or effort is shared between the target enterprise, the network, ecosystem funding, partner firm, or another sponsor. The selected vendor must assess whether such models are appropriate for Cardano and under what controls. **Co-selling** means a coordinated go-to-market motion where Cardano ecosystem actors and partner firms jointly identify, qualify, pursue, or support enterprise opportunities. **Training pathway** means the technical, commercial, delivery, documentation, support, certification, or vertical education needed for firms to become credible delivery partners. **Quality governance** means the mechanisms used to maintain partner credibility over time, including certification renewal, customer feedback, delivery reviews, conflict controls, complaint handling, suspension, escalation, and removal. **Delivery signal** means evidence that a firm has the capability and incentive to deliver production or pilot work, such as relevant implementation references, technical staff, sector experience, procurement fit, named delivery roles, delivery methodology, support model, and willingness to invest in Cardano capability. **Cosmetic signal** means activity that appears useful but does not demonstrate delivery readiness, such as generic partnership announcements, logos on a partner page, community presence, event sponsorship, non-binding interest, or unverifiable claims of enterprise access. The selected vendor may refine these definitions during the research design phase, but revised definitions must remain measurable, decision-useful, and evidence-based. *** ## 5. Objectives The selected vendor will be expected to: 1. Map the current and potential global landscape of firms capable of delivering Cardano enterprise solutions, by capability, sector, geography, team size, enterprise experience, and readiness level. 2. Define the enterprise delivery capabilities required for Cardano-related deployments to move through procurement, implementation, integration, support, and production use. 3. Determine what certification framework, partner tiers, training pathway, governance model, and quality controls would credibly signal delivery readiness. 4. Benchmark partner-network models from relevant peer ecosystems, including certification, enablement, co-selling, co-funded implementation, governance, and partner recruitment structures. 5. Assess whether co-funded implementation structures are suitable for Cardano, and define guardrails that prevent subsidy of weak demand or poor delivery. 6. Identify what prevents larger consultancies or system integrators from building a Cardano practice, and what interventions would change that. 7. Identify priority geographies and sectors where partner development is most urgent. 8. Define incentives, enablement assets, technical support, commercial support, and training pathways needed to recruit and retain delivery partners. 9. Recommend pilot engagements and partner recruitment actions that test the model with measurable adoption outcomes. 10. Produce evidence thresholds for future partner certification, partner funding, co-funding, co-selling, and pilot support decisions. 11. Identify dependencies and handoff findings for adjacent RFPs or workstreams. *** ## 6. Decision Gates Applicants must design their methodology around the following decision gates. A proposal that does not map methods and deliverables to these gates will be considered weak fit for this RFP. | Decision Gate | Evidence Required | YES Means | NO Means | Action Unlocked | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | What does the current Cardano-capable delivery partner landscape look like? | Partner landscape map covering named or anonymized firms, capability, sector, geography, team size, Cardano experience, enterprise references where available, and confidence level | Cardano has a baseline map of immediate and near-term delivery capacity | Partner recruitment remains anecdotal or dependent on informal networks | Prioritize outreach, enablement, and gap closure by firm type and region | | Which delivery capabilities must a credible enterprise partner demonstrate? | Enterprise buyer/operator input, delivery-firm interviews, procurement expectations, implementation lifecycle analysis, support requirements, and technical capability taxonomy | Certification can be tied to real enterprise delivery requirements | Certification risks becoming a symbolic badge without procurement value | Define capability requirements and readiness levels | | Can 10-50 person specialist delivery teams be credibly recruited and retained? | Interviews with target firms, incentive tests, opportunity-cost analysis, training/support needs, and commercial model assessment | A specialist partner channel may be a practical near-term route | The target segment may be inaccessible, under-incentivized, or too thin | Decide whether to recruit now, build demand first, or target another partner archetype | | What role should larger consultancies and system integrators play? | Interviews or expert input from consultancies/SIs, analysis of demand thresholds, practice economics, risk perception, internal enablement needs, and opportunity cost | Larger firms may be reachable with specific interventions or proof points | Major consultancy recruitment is not a practical near-term path | Decide whether to pursue global SI engagement, regional SI engagement, or specialist-first strategy | | Which peer ecosystem partner models are relevant to Cardano? | Benchmark of comparable ecosystems covering certification, enablement, co-selling, co-funded implementation, quality governance, and partner incentives | Cardano can adapt proven components rather than design from scratch | Peer models are not transferable or lack sufficient evidence | Select reference-model components for further design | | Would co-funded implementation structures work for Cardano? | Cost-sharing benchmark, enterprise willingness evidence, partner economics, funding governance, buyer contribution logic, KPIs, and stop conditions | Co-funding can be tested with guardrails tied to adoption outcomes | Co-funding may subsidize consulting activity without durable adoption | Define pilot co-funding rules, reject the mechanism, or defer pending stronger demand evidence | | Which geographies and sectors have the most urgent delivery gaps? | Gap map linking partner coverage to enterprise/RWA/government/use-case opportunities, regional procurement needs, sector capability, and confidence levels | Partner recruitment can be sequenced around adoption opportunities | Geographic or sector priorities remain speculative | Prioritize partner development by region and vertical | | What training, enablement, and support assets are required? | Delivery-firm needs assessment, technical documentation review, certification input, support expectations, and comparison with peer programmes | Cardano can define what partners need to become delivery-ready | Recruitment may fail because firms lack practical enablement | Fund or coordinate training, documentation, technical support, sandbox access, or partner toolkits | | What governance model protects quality and enterprise trust? | Certification renewal criteria, customer feedback loops, complaint handling, delivery review process, conflict controls, escalation, suspension, and removal options | Certification can remain credible over time | Poor delivery could damage Cardano's enterprise reputation | Define partner governance, oversight, and quality-control requirements | | Which pilot engagements should test the partner model first? | Candidate opportunity analysis, partner readiness, buyer access, implementation scope, co-funding fit, KPIs, risks, and decision value | Cardano can move from research to controlled pilots | The partner model remains theoretical | Select pilot pathways, funding triggers, and stop conditions | | What evidence should be required before funding, certifying, or co-selling with a partner? | Evidence threshold framework covering delivery capability, references, training completion, technical readiness, support model, conflicts, customer outcomes, and adoption KPIs | Future partner decisions can be made against a reusable standard | Partner decisions may rely on reputation, relationships, or enthusiasm | Create decision criteria for partner certification, funding, co-selling, and renewal | | Which findings should be handed to adjacent RFPs or workstreams? | Cross-RFP handoff memo mapping dependencies to enterprise/RWA readiness, government entry, customer segmentation, use-case positioning, brand perception, L2/interoperability, stablecoins, or AI | RFP #8 stays focused while routing demand, buyer, or product findings correctly | Scope expands into a general enterprise strategy study | Preserve useful dependencies without duplicating other RFPs | *** ## 7. Scope of Work ### In scope The selected vendor should cover: * current and potential Cardano delivery partner landscape mapping; * enterprise delivery capability taxonomy; * certification framework and partner-tier recommendation; * peer ecosystem partner-network benchmarking; * co-funded implementation model assessment; * partner recruitment and go-to-market model; * larger-consultancy and system-integrator barrier analysis; * geography and sector gap analysis; * training, enablement, technical support, and documentation requirements; * partner governance and quality-control model; * pilot engagement pathway; * evidence thresholds for certification, partner funding, co-selling, co-funding, and renewal; * public and confidential reporting. ### Screening-first scope Applicants should propose a screening phase before deep-dive research. The screening phase should identify: * candidate partner categories; * regions and sectors where partner capacity is most needed; * peer ecosystems worth benchmarking; * candidate certification models; * possible co-funded implementation models; * firms or respondent categories available for primary validation. A narrower proposal with credible access and strong decision value may be stronger than a broad proposal that attempts to map every possible delivery firm superficially. ### Partner categories to consider Applicants may propose their own categories, but should consider: | Partner Category | Research Purpose | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | Cardano-native delivery firms | Determine current implementation capability, support model, enterprise readiness, and scalability | | Specialist blockchain implementation firms | Assess whether non-Cardano firms can be recruited or trained into Cardano delivery | | Regional system integrators | Evaluate geography-specific delivery capacity and buyer access | | Vertical specialists | Assess capability in sectors such as RWA, government, supply chain, identity, financial services, or enterprise data | | Larger consultancies and SIs | Determine barriers to creating a Cardano practice and realistic intervention points | | Infrastructure and product vendors | Identify where product teams can support, train, or co-deliver with partner firms | | Peer ecosystem programme operators | Benchmark partner-network, certification, co-selling, and co-funding models | ### Out of scope and handoff boundaries This RFP is not: * a contract to run the partner programme; * a contract to certify firms; * a contract to implement enterprise deployments; * an enterprise sales campaign; * a legal review of partner liability or procurement terms; * a generic Cardano partnerships strategy; * a replacement for RFP #6 enterprise and RWA readiness work; * a replacement for RFP #5 government and emerging markets entry work; * a replacement for RFP #2 use-case and competitive positioning work; * a funding mechanism for delivery firms before evidence thresholds are defined. The selected vendor is expected to recommend a partner-network model and evidence thresholds. The vendor is not being asked to operate the partner programme, certify firms, or become the default implementation provider. ### Optional / nice-to-have stretch scope Applicants may propose optional stretch work if clearly separated from core scope and budget: * draft certification tier names and criteria; * sample partner onboarding checklist; * sample partner scorecard; * sample co-funded implementation term-sheet outline; * sample partner training curriculum outline; * mock partner directory structure; * pilot governance template; * draft RACI for partner programme ownership. Stretch scope should not replace the required research and decision outputs. *** ## 8. Required Methodology Applicants should propose a methodology that can answer the decision gates and produce decision-ready outputs. The methodology should be proportionate to the proposed budget and timeline. ### Core research hypotheses Applicants should test, refine, or reject the following hypotheses: 1. Cardano enterprise adoption is constrained by insufficient delivery partner capacity and visibility. 2. Enterprise buyers require accountable delivery partners before they will move from interest or pilot to production deployment. 3. A certification framework would be useful only if it measures real delivery readiness and is governed over time. 4. Specialist 10-50 person delivery teams may be more reachable in the near term than large global consultancies. 5. Larger consultancies may require stronger demand evidence, partner economics, support infrastructure, or lower perceived risk before building a Cardano practice. 6. Peer ecosystems have partner-network and co-funded implementation models that Cardano can adapt, but only after validating fit and guardrails. 7. Co-funded implementation may help enterprise adoption if buyer contribution, partner accountability, and post-project adoption outcomes are required. 8. Regional and sector gaps are likely uneven, and partner development should be sequenced around validated enterprise, RWA, government, or vertical demand. ### Required evidence types The research should include: * partner landscape evidence; * delivery capability evidence; * delivery-firm interviews or equivalent primary validation; * enterprise buyer, operator, or procurement input where feasible; * peer ecosystem benchmark evidence; * certification and governance model evidence; * commercial incentive and recruitment evidence; * co-funding model evidence; * geography and sector gap evidence; * negative-case evidence from stalled, failed, or non-adopted partner models where available. ### Primary research Applicants should propose a respondent plan that may include: * Cardano-native delivery firms; * non-Cardano blockchain implementation firms; * regional system integrators; * larger consultancies or former consultancy/SI practitioners; * enterprise buyers, operators, or procurement stakeholders; * RWA, government, supply-chain, identity, or other vertical stakeholders where relevant; * Cardano infrastructure, wallet, tooling, or product teams that partners would depend on; * peer ecosystem programme operators or knowledgeable experts; * organizations with experience in co-funded technology implementation. Applicants should state which respondent categories are confirmed, likely, speculative, or dependent on CPC/ecosystem introductions. If respondent access is uncertain, the proposal must explain fallback methods and the effect on confidence levels. ### Desk research Desk research should cover: * public information on Cardano delivery-capable firms; * public information on peer ecosystem partner programmes; * certification and partner-tier structures from comparable technology ecosystems; * case studies of delivery partner networks and implementation channels; * co-funding, co-selling, partner enablement, and customer-success models where available; * regional and sector signals relevant to enterprise delivery coverage; * public examples of successful and failed blockchain or enterprise partner-programme models. Applicants should avoid relying only on public partner pages, logo lists, or announcements. Those may be starting points, but they do not prove delivery readiness. ### Benchmarking requirements The selected vendor should benchmark relevant peer ecosystems and technology partner programmes. Benchmarks should include, where evidence is available: * partner types and tiers; * certification criteria; * training and enablement; * technical support model; * co-selling structure; * implementation funding or co-funding structure; * governance and quality controls; * partner incentives; * renewal requirements; * customer feedback mechanisms; * evidence of adoption outcomes; * limitations or failure modes. The RFP does not require any named peer ecosystem to be treated as a proven model. Applicants may include ecosystems mentioned by CPC stakeholders or other relevant peer ecosystems, but must validate each benchmark and explain transferability to Cardano. ### Co-funded implementation assessment If applicants propose assessing co-funded implementation models, they should examine: * who pays; * what the enterprise must contribute; * what the partner firm contributes; * what the ecosystem or network contributes; * what milestones trigger funding; * what evidence shows buyer commitment; * what delivery and adoption KPIs are required; * how conflicts and self-dealing are prevented; * how failed or stalled projects are handled; * when co-funding should not be used. ### Data sources to validate Potential data sources may include: * public firm websites and case studies; * partner programme pages from peer ecosystems; * enterprise procurement and implementation experts; * Cardano ecosystem directories and project lists; * grant, pilot, or enterprise engagement records where accessible; * public repositories, documentation, or tooling maturity evidence; * prior research from adjacent RFPs where available; * paid expert networks or proprietary databases, if justified and inspectable. If a data source is proprietary, paid, confidential, or uncertain, the applicant must label it as such and explain whether CPC can inspect it, whether it can be cited publicly, and what limitations apply. ### Minimum evidence expectations Applicants should propose sample sizes and coverage appropriate to their method. The proposal should justify the number and type of interviews, benchmarks, and partner profiles needed to answer the decision gates. At minimum, the research design should explain how it will cover: * current Cardano delivery-capable firms; * at least one non-Cardano delivery-firm category; * at least one larger-consultancy or SI perspective, if feasible; * enterprise buyer/operator or procurement expectations; * peer ecosystem partner models; * regional or sector gap logic; * negative cases or reasons firms would not participate. If any of these categories cannot be covered, the applicant must explain the limitation and its effect on decision confidence. ### Avoiding Cardano insider bias Applicants must separate: * Cardano ecosystem claims; * evidence from delivery firms seeking future funding or certification; * evidence from independent enterprise buyers or operators; * evidence from non-Cardano delivery firms; * evidence from peer ecosystem benchmarks; * vendor interpretation. The final report must label confidence levels and source basis for important findings. ### Distinguishing real adoption signal from cosmetic activity The research should distinguish delivery readiness from: * informal partnership language; * event participation; * advisory relationships; * logo placement; * community reputation; * non-binding interest; * theoretical implementation capability; * vendor self-promotion; * one-off proof-of-concept activity without support obligations. Real delivery signal should be tied to capability, references, technical readiness, delivery management, support model, procurement fit, customer outcomes, or willingness to invest in Cardano practice development. *** ## 9. Expected Deliverables The selected vendor should produce the following deliverables. Vendors may combine deliverables where sensible, provided that each required output remains identifiable. | Deliverable | Description | Format | Purpose | Acceptance Criteria | Decision Enabled | Failure Modes | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------- | | Partner Landscape Map | Map current and potential delivery firms by capability, sector, geography, team size, Cardano experience, enterprise readiness, and confidence level | Spreadsheet or table plus narrative summary | Establish baseline delivery capacity | Includes classification criteria, source basis, readiness levels, and confidence notes; does not rely only on logos or claims | Prioritize partner recruitment and gap closure | Becomes a directory without readiness evidence | | Enterprise Delivery Capability Model | Define capabilities required for enterprise-grade Cardano implementation and support | Framework and scoring model | Anchor certification in real delivery requirements | Covers technical, integration, delivery management, support, procurement, security/risk, documentation, and sector experience | Define readiness levels and certification criteria | Uses vague terms such as "experienced" without testable evidence | | Certification Framework Recommendation | Recommend partner tiers, criteria, evidence requirements, training, renewal, and governance | Framework document | Decide whether and how to certify partners | Ties every criterion to delivery readiness or procurement trust; includes renewal and removal logic | Launch or defer certification design | Creates a badge without quality controls | | Peer Ecosystem Reference-Model Benchmark | Compare relevant partner, certification, co-selling, and co-funding models from peer ecosystems or technology markets | Benchmark report and comparison table | Adapt proven models where transferable | Includes source basis, transferability assessment, limitations, and relevance to Cardano | Select model components to adapt | Copies a model without proving fit | | Co-Funded Implementation Model Assessment | Assess if and how shared-cost implementation structures could work for Cardano | Options analysis and guardrail framework | Decide whether to test co-funded pilots | Defines payer roles, buyer contribution, milestone triggers, KPIs, conflicts, stop conditions, and misuse risks | Approve, reject, or pilot co-funding | Subsidizes consulting without buyer commitment or adoption outcomes | | Partner Recruitment and Go-to-Market Model | Define target partner archetypes, incentives, outreach sequence, co-selling model, and retention logic | GTM model and action plan | Recruit and retain qualified firms | Identifies target firm types, value proposition, required support, incentive logic, and adoption link | Launch recruitment pathway | Assumes firms will join without evidence | | Geography and Sector Gap Analysis | Identify priority regions and sectors where delivery capacity is missing or urgent | Gap map and prioritization table | Sequence partner development | Links gaps to enterprise/RWA/government/use-case opportunities and confidence levels | Prioritize regional and vertical partner development | Treats all regions or sectors as equally important | | Larger-Consultancy Barrier Analysis | Explain what prevents larger consultancies/SIs from building a Cardano practice | Findings memo | Decide whether major-SI engagement is realistic | Includes demand, economics, risk, support, training, brand/perception, and opportunity-cost factors | Choose global SI, regional SI, or specialist-first route | Reduces barrier to lack of awareness | | Training and Enablement Requirements Map | Identify assets partners need to become delivery-ready | Requirements register | Fund or coordinate enablement | Covers technical documentation, reference architectures, training, sandbox access, support escalation, sales collateral, and vertical materials | Define enablement workstream | Produces generic training ideas not tied to partner gaps | | Partner Governance and Quality-Control Model | Define oversight, renewal, feedback, conflict, complaint, escalation, and removal mechanisms | Governance model | Protect enterprise trust | Includes accountability roles, evidence checks, renewal criteria, customer feedback, and handling of poor delivery | Govern certification and partner quality | Fails to manage low-quality or conflicted partners | | Pilot Engagement Pathway | Recommend pilot partner engagements, co-funding tests, KPIs, and stop conditions | Pilot roadmap | Move from research to controlled action | Identifies candidate pilot types, partner criteria, buyer contribution, delivery milestones, adoption KPIs, and risks | Launch pilot(s) or defer | Recommends pilots without measurable outcomes | | Evidence Threshold Framework | Define minimum evidence before funding, certifying, co-selling, co-funding, or renewing partners | Decision framework | Standardize future partner decisions | Provides testable thresholds and confidence levels for each decision type | Create reusable partner decision criteria | Leaves future decisions relationship-driven | | Executive Decision Memo | Summarize findings, confidence, options, recommended actions, and no-go areas | Short memo | Support CPC and ecosystem decision-making | States what to do, what not to do, what to test, and why | Decide next actions | Avoids hard recommendations | | Final Research Report | Full evidence base, methodology, findings, limitations, recommendations, and appendices | Markdown/PDF/report format | Preserve traceable research record | Answers every decision gate and includes limitations and source confidence | Publication and internal reference | Long report without decision utility | | Final Presentation | Present findings and recommended actions to CPC/designated reviewers | Slide deck or presentation | Enable review and discussion | Clear summary of decision gates, evidence, recommendations, and limitations | Approval or revision of next steps | Promotional deck lacking evidence | | Public Summary | Non-confidential summary for the Cardano ecosystem | Markdown/web-ready summary | Share useful findings while protecting sensitive data | Includes methodology overview, high-level findings, recommendations where publishable, and limitations | Ecosystem learning and transparency | Reveals sensitive data or says too little to be useful | | Cross-RFP Handoff Memo | Route findings to adjacent RFPs and workstreams | Memo or appendix | Prevent duplication and preserve dependencies | Identifies handoffs to enterprise/RWA readiness, government, use-case, brand, L2/interoperability, stablecoins, AI, or other workstreams | Coordinate action beyond RFP #8 | Expands scope instead of handing off | *** ## 10. Acceptance Criteria The final work will be considered acceptable only if it answers the decision gates with traceable evidence and decision-ready recommendations. At minimum, the final outputs must: * map current and potential delivery partners using explicit readiness criteria; * distinguish delivery capability from reputation, relationship, or announcement activity; * define enterprise delivery capability requirements in testable terms; * recommend or reject a certification framework with clear reasoning; * benchmark relevant peer models and assess transferability to Cardano; * assess co-funded implementation models with guardrails, KPIs, and stop conditions; * identify what would attract or deter specialist firms and larger consultancies; * identify priority geography and sector gaps; * define training, enablement, and technical support requirements; * define governance and quality controls for certification and partner management; * recommend pilot pathways or explain why pilots should be deferred; * include evidence thresholds for future funding, certification, co-selling, co-funding, and renewal decisions; * label confidence levels and limitations; * include public-summary and confidential-findings boundaries; * disclose conflicts and manage conflicted evidence; * include cross-RFP handoff logic. ### Decision linkage Each deliverable must state which decision gate it supports and what decision it enables. Deliverables that diagnose a problem without enabling a decision should be revised. ### Evidence quality Evidence should be source-labeled and classified by confidence level. Where evidence depends on confidential respondents, proprietary data, or vendor judgment, the final report must explain how reviewers can assess reliability without exposing sensitive information. ### Unacceptable outputs Outputs may be considered unacceptable if they: * provide only a generic partner-program recommendation; * list firms without readiness evidence; * assume certification is the correct answer without testing alternatives; * recommend co-funding without buyer contribution, delivery KPIs, conflict controls, or stop conditions; * rely mainly on Cardano insider opinion; * do not include non-Cardano or enterprise buyer/operator evidence where feasible; * present the vendor's own delivery services as the implied solution; * fail to disclose conflicts; * avoid negative findings; * cannot explain what Cardano stakeholders should do differently. *** ## 11. Vendor Eligibility Applicants may be research firms, strategy consultancies, ecosystem research teams, enterprise technology analysts, delivery-channel specialists, market research firms, or qualified consortia. Applicants should demonstrate capability in at least several of the following areas: * enterprise technology delivery or system integrator channel research; * partner programme, certification, or channel strategy design; * blockchain ecosystem, Web3, or open-source ecosystem research; * enterprise buyer, procurement, or implementation research; * partner recruitment and go-to-market analysis; * benchmarking of technology partner programmes; * qualitative interviews with senior commercial, delivery, or procurement stakeholders; * data handling for commercially sensitive respondents; * decision-oriented research for grant, product, or ecosystem strategy contexts. Subcontracting is allowed if roles, responsibilities, costs, and conflicts are clearly disclosed. Applicants should identify which team members will conduct research, interviews, analysis, benchmarking, and writing. Applicants that are themselves delivery firms, system integrators, consultancies, certification candidates, or potential beneficiaries of future partner funding may apply, but must disclose conflicts and explain how they will preserve research independence. *** ## 12. Proposal Submission Requirements Applicants must follow the shared Submission Pack and include the common documents: cover letter, technical proposal, budget proposal, team credentials, evidence access plan, ethics/data handling statement, and conflicts declaration. Applicants bidding on multiple Product Research Initiative RFPs must disclose shared staffing, shared respondent recruitment, shared evidence collection, and any assumptions that could create respondent fatigue or duplicated outreach. For this RFP, the technical proposal must also include: * partner category and screening approach; * delivery capability model approach; * firm, buyer, SI, or consultancy access plan; * peer ecosystem partner-model benchmark approach; * certification, governance, and quality-control design logic; * co-funded implementation assessment and guardrail approach. Budgets should explain how cost relates to delivery-firm access, peer benchmark depth, enterprise buyer input, sector/geography coverage, and decision value. ## 13. Evaluation Guidance Proposals will be assessed using the CPC standard research grant evaluation framework: Fit to Grant Objectives, Team Capability, Proposal Quality and Execution Plan, and Cost Efficiency. The full scoring framework is maintained on the shared evaluation page. For this RFP, strong fit means the proposal can define the delivery capabilities enterprise buyers need, map current and recruitable partner capacity, benchmark relevant peer models, and recommend a certification and partner-network model tied to real delivery outcomes. A strong proposal should test whether specialist delivery firms, regional integrators, larger consultancies, and vertical specialists can be recruited or enabled. It should define co-funded implementation guardrails and quality governance without becoming partner-program operations. Proposals should score lower if they rely on generic partnership strategy, symbolic certification, weak firm access, unverifiable delivery claims, or subsidy models without adoption thresholds. Cost should be judged against evidence value, not lowest price. Higher-cost proposals may be justified by stronger delivery-firm access, peer benchmark depth, enterprise buyer input, or more useful pilot and governance design. ## 14. Timeline and Milestones Final calendar dates will be confirmed on the Product Research Initiatives - Grants page before the call opens. | Milestone | Target Date / Timing | Purpose | | ----------------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | RFP publication | Confirmed on grants page | Open call for proposals | | Clarification window opens | Confirmed on grants page | Applicants may submit questions | | Clarification window closes | Confirmed on grants page | Final clarification responses issued | | Proposal deadline | Confirmed on grants page | Applicant submissions due | | Award notification | Confirmed on grants page | Selected vendor notified | | Kickoff | Project week 1 | Confirm objectives, decision gates, scope, workplan, communication cadence, confidentiality expectations, and public-summary expectations | | Research design alignment | Applicant-proposed timing | Align on respondent categories, partner taxonomy, benchmark plan, evidence standards, certification assumptions, co-funding assessment, and data handling before fieldwork | | Screening review | Applicant-proposed timing | Review initial partner categories, peer models, candidate regions/sectors, and deep-dive selection | | Stakeholder access check | Applicant-proposed timing | Surface recruitment issues, weak access, missing respondent categories, confidentiality constraints, or substitutions needed | | Early findings review | Applicant-proposed timing | Review initial partner landscape signals, certification requirements, peer benchmark lessons, and possible false positives | | Interim findings review | Applicant-proposed timing | Test whether evidence is answering decision gates and whether scope needs adjustment | | Draft deliverables review | Applicant-proposed timing | Review partner landscape, capability model, certification framework, peer benchmark, co-funding assessment, GTM model, and pilot pathway | | Final report and presentation | Applicant-proposed timing | Present final findings, confidence levels, limitations, decisions enabled, and recommended actions | | Public summary review | Applicant-proposed timing | Confirm what can be published and what should remain confidential | | Public summary | Applicant-proposed timing | Publish non-confidential summary | Applicants should propose a timeline appropriate to their methodology. Unrealistic timelines should be avoided, especially where primary external validation, larger-consultancy access, peer benchmark research, or commercially sensitive partner interviews are proposed. *** ## 15. Governance, Reporting, and Communication The selected vendor will participate in structured checkpoints. The process should protect research quality without turning the work into committee-managed consulting. | Checkpoint | Purpose | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Kickoff | Confirm objectives, decision gates, scope, workplan, communication cadence, confidentiality expectations, and public-summary expectations | | Research Design Review | Align on respondent categories, partner taxonomy, benchmark plan, certification assumptions, co-funding assessment, evidence standards, and data handling before fieldwork | | Screening Review | Review initial partner categories, peer models, candidate regions/sectors, and deep-dive selection | | Stakeholder Access Check | Surface recruitment issues, weak access, missing respondent categories, confidentiality constraints, or substitutions needed | | Early Findings Review | Review initial partner landscape signals, certification requirements, peer benchmark lessons, and possible false positives | | Interim Findings Review | Test whether evidence is answering decision gates and whether scope needs adjustment | | Draft Deliverables Review | Review partner landscape, capability model, certification framework, peer benchmark, co-funding assessment, GTM model, governance model, and pilot pathway | | Final Presentation | Present final findings, confidence levels, limitations, decisions enabled, and recommended actions | | Public Summary Review | Confirm what can be published and what should remain confidential | Before primary fieldwork begins, the vendor should align with CPC or a designated review group on: * respondent categories; * recruitment strategy; * partner landscape taxonomy; * delivery readiness criteria; * peer benchmark selection; * certification framework assumptions; * co-funding assessment criteria; * minimum evidence standard; * data handling and confidentiality approach; * treatment of commercially sensitive partner or buyer evidence; * public-summary boundaries. This review should protect research quality without directing the findings. The vendor should retain methodological independence and should be expected to report inconvenient or negative findings. The vendor should not wait until the final report to disclose: * weak respondent access; * unsupported partner capability claims; * evidence that certification would not be credible; * evidence that co-funding would create poor incentives; * evidence that larger consultancies are not reachable in the near term; * major regional or sector coverage gaps; * conflicts of interest; * scope creep into adjacent RFPs. *** ## 16. Risks, Bias Controls, and Safeguards Applicants must include a research integrity plan. | Risk | Required Control | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Cardano insider bias | Separate ecosystem claims from independent delivery-firm, enterprise buyer/operator, and peer benchmark evidence | | Vendor self-interest | Disclose whether applicant or subcontractors may seek certification, delivery work, co-funding, or partner status | | Cosmetic partnership signal | Require delivery capability, references, support model, training needs, and procurement fit evidence | | Certification theater | Tie certification criteria to measurable delivery readiness and governance controls | | Co-funding misuse | Require buyer contribution, delivery milestones, adoption KPIs, conflict controls, and stop conditions | | Large consultancy overfocus | Test major-SI feasibility against demand, economics, risk, support needs, and opportunity cost | | Partner directory trap | Use readiness scoring and confidence levels rather than simple firm lists | | Peer model overcopying | Assess transferability, context, limitations, and failure modes before recommending adaptation | | Weak access | Disclose recruitment limitations early and adjust confidence levels | | Conflicted respondents | Label evidence from firms seeking future funding, certification, or commercial advantage | | Regional blind spots | Identify geographic coverage limitations and confidence levels | | Scope creep | Use cross-RFP handoff logic for enterprise demand, government entry, use-case positioning, brand perception, stablecoins, L2/interoperability, or AI | | Confidentiality reducing public usefulness | Produce confidential full evidence plus publishable anonymized findings | The final report must include a limitations section explaining what the research can and cannot support. *** ## 17. Clarification Process Applicants may submit clarification questions during the clarification window. Questions may address: * partner categories; * certification scope and assumptions; * expected respondent categories; * treatment of named versus anonymized partner firms; * larger-consultancy or SI access expectations; * peer ecosystem benchmark scope; * co-funded implementation model boundaries; * treatment of confidential partner, buyer, or procurement evidence; * public versus confidential outputs; * overlap with enterprise/RWA readiness or government entry work; * budget format; * optional stretch scope. Responses should be maintained in a rolling Q\&A log where practical so applicants receive consistent information. If a clarification materially changes scope, deadline, eligibility, or deliverables, the RFP timeline may be adjusted. The clarification process also helps assess applicant judgment. Strong questions may demonstrate understanding of delivery-channel economics, certification credibility, enterprise procurement, partner governance, co-funding risks, and methodological tradeoffs. *** ## 18. Data Handling, Confidentiality, and Public Summary The selected vendor must provide a data handling plan covering: * informed consent for interviews, expert calls, workshops, or surveys; * recording and transcription policy; * anonymization approach; * raw notes and transcript handling; * storage and access controls; * retention and deletion plan; * treatment of sensitive partner, buyer, procurement, commercial, or delivery information; * treatment of proprietary, paid, or respondent-provided data; * separation of public findings, confidential findings, and raw data; * publication boundaries. Research outputs should distinguish: * public findings suitable for ecosystem publication; * confidential findings suitable only for CPC or approved reviewers; * sensitive respondent or firm information that should not be published; * raw data that should not be published; * proprietary data that CPC can inspect but may not publish; * vendor judgment where primary data cannot be disclosed. A public summary is expected unless specific findings cannot be published for justified confidentiality reasons. The public summary should include: * methodology overview; * respondent category summary; * high-level partner landscape findings; * publishable certification and governance recommendations; * publishable peer benchmark themes; * publishable co-funding considerations; * recommended next-step actions where publishable; * limitations and evidence caveats. The public summary should not expose: * confidential respondent identities; * sensitive partner capability assessments; * commercially sensitive pricing or practice-development details; * confidential buyer or procurement information; * proprietary benchmark data; * details that could undermine respondent trust. If proprietary, paid, respondent-provided, or locally restricted data is used, the vendor must state: * source; * access conditions; * whether CPC can inspect it; * whether it can be cited publicly; * what limitations apply; * whether it can be retained after project completion. If a finding depends heavily on data CPC cannot inspect, the vendor must label the confidence level accordingly. *** ## 19. Human Subject Research Ethics Because this RFP requires interviews or surveys with delivery firms, system integrators, enterprise buyers, procurement stakeholders, and potentially commercially sensitive respondents, the selected vendor must apply basic human-subject safeguards. At minimum, the vendor should: * tell respondents the purpose of the research; * explain who the research is for; * state how information may be used; * ask whether comments are attributable, anonymized, or confidential; * obtain consent before recording; * avoid publishing sensitive respondent information without permission; * allow respondents to clarify attribution status; * avoid misleading respondents about the purpose or audience of the work; * avoid exposing respondents to employment, commercial, regulatory, competitive, or procurement risk. *** ## 20. Conflicts of Interest Applicants and subcontractors must disclose any actual, potential, or perceived conflicts of interest, including: * paid work for Cardano ecosystem entities; * paid work for peer-chain ecosystems; * advisory roles; * governance roles; * financial exposure to Cardano or competitor ecosystem assets; * relationships with delivery firms, consultancies, system integrators, infrastructure vendors, enterprise buyers, or respondents; * ownership or commercial interest in a product, service, certification, consulting practice, partner programme, or implementation model that may be affected by the research; * intent to apply for future partner certification, co-funded implementation, grant funding, enterprise delivery work, or related opportunities; * subcontractor conflicts. Declared conflicts do not automatically disqualify an applicant, but they must be managed. Undisclosed conflicts may be grounds for rejection, non-award, payment holdback, or termination. Research outputs should separate: * evidence from conflicted respondents; * evidence from firms seeking certification, funding, or delivery work; * independent enterprise buyer/operator evidence; * peer benchmark evidence; * vendor interpretation; * commercially sensitive findings. *** ## 21. Terms and Conditions Standard terms and conditions will be provided through the shared tender process before award. Applicants should assume that final award terms will cover ownership and permitted publication of deliverables, confidentiality, payment milestones, termination, data protection, subcontractor approval, warranties or disclaimers, and the governing process. *** ## 22. Appendix A: Proposal Checklist Applicants should confirm that their proposal includes: * [ ] Cover letter * [ ] Understanding of the brief * [ ] Proposed methodology * [ ] Decision gate mapping * [ ] Partner landscape mapping plan * [ ] Stakeholder access plan * [ ] Peer benchmarking plan * [ ] Certification framework approach * [ ] Co-funded implementation model approach * [ ] Larger-consultancy/SI barrier approach * [ ] Geography and sector gap approach * [ ] Training and enablement assessment * [ ] Governance and quality-control approach * [ ] Pilot pathway approach * [ ] Data sources * [ ] Workplan * [ ] Deliverables plan * [ ] Team qualifications * [ ] Relevant experience * [ ] Risk and bias mitigation plan * [ ] Confidentiality and data handling approach * [ ] Ethics approach * [ ] Timeline * [ ] Budget breakdown * [ ] Conflicts declaration * [ ] Prior work examples, if applicable *** ## 23. Appendix B: Suggested Partner Landscape Map Template | Firm / Category | Partner Type | Geography | Sector Experience | Team Size / Capacity | Cardano Experience | Enterprise References | Delivery Capabilities | Support Model | Readiness Level | Evidence Source | Confidence | Recommended Action | | ---------------- | --------------------------------------------------------------------------------------------------------- | --------- | ----------------- | -------------------- | ------------------ | --------------------- | --------------------- | ---------------- | -------------------------------------------------------------- | --------------- | ---------------------- | ---------------------------------------------------------- | | \[Firm/category] | \[Cardano-native / Specialist blockchain / Regional SI / Large consultancy / Vertical specialist / Other] | \[Region] | \[Sectors] | \[Capacity] | \[Evidence] | \[Reference basis] | \[Capabilities] | \[Support model] | \[Ready / Conditional / Develop / Monitor / Not fit / Unknown] | \[Source] | \[High / Medium / Low] | \[Recruit / Train / Certify / Monitor / Defer / No action] | *** ## 24. Appendix C: Suggested Enterprise Delivery Capability Template | Capability Area | Readiness Question | Evidence Required | Minimum Standard | Nice-to-Have | Failure Signal | Certification Implication | | -------------------------- | ----------------------------------------------------------------------- | ----------------- | ---------------- | --------------- | ----------------- | ------------------------- | | Technical implementation | Can the firm build or configure Cardano-related solutions? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Integration | Can the firm integrate with enterprise systems and workflows? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Delivery management | Can the firm manage scope, milestones, risk, and client communication? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Support and maintenance | Can the firm support deployments after launch? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Procurement fit | Can the firm satisfy buyer procurement and accountability expectations? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Sector credibility | Does the firm understand relevant vertical requirements? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Security and risk | Can the firm manage enterprise security and risk expectations? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | | Documentation and training | Can the firm produce and use delivery documentation? | \[Evidence] | \[Minimum] | \[Nice-to-have] | \[Failure signal] | \[Tier/requirement] | *** ## 25. Appendix D: Suggested Certification Framework Template | Tier / Status | Purpose | Eligibility Criteria | Evidence Required | Training Required | Renewal Requirement | Governance Control | Permitted Claims | Recommended Use | | -------------- | ---------- | -------------------- | ----------------- | ----------------- | ------------------- | ------------------ | ---------------- | --------------- | | \[Tier/status] | \[Purpose] | \[Criteria] | \[Evidence] | \[Training] | \[Renewal] | \[Control] | \[Claims] | \[Use] | *** ## 26. Appendix E: Suggested Peer Reference Model Benchmark Template | Peer Ecosystem / Programme | Partner Types | Certification Structure | Enablement Model | Co-Selling Model | Co-Funding Model | Governance Controls | Evidence of Outcomes | Transferability to Cardano | Limitations | | -------------------------- | ------------- | ----------------------- | ---------------- | ---------------- | ---------------- | ------------------- | -------------------- | -------------------------- | -------------- | | \[Ecosystem/programme] | \[Types] | \[Structure] | \[Enablement] | \[Co-selling] | \[Co-funding] | \[Controls] | \[Evidence] | \[High / Medium / Low] | \[Limitations] | *** ## 27. Appendix F: Suggested Co-Funded Implementation Assessment Template | Model | Buyer Contribution | Network / Ecosystem Contribution | Partner Contribution | Eligible Project Type | Funding Trigger | Delivery KPI | Adoption KPI | Conflict Control | Stop Condition | Recommendation | | -------- | ------------------ | -------------------------------- | -------------------- | --------------------- | --------------- | ------------ | ------------ | ---------------- | -------------- | ---------------------------------- | | \[Model] | \[Contribution] | \[Contribution] | \[Contribution] | \[Project type] | \[Trigger] | \[KPI] | \[KPI] | \[Control] | \[Condition] | \[Fund / Pilot / Monitor / Reject] | *** ## 28. Appendix G: Suggested Partner Recruitment and GTM Template | Target Partner Archetype | Value Proposition to Partner | Required Enablement | Incentive / Commercial Model | Target Geography | Target Sector | Recruitment Channel | Proof Needed | Risk | Recommended Action | | ------------------------ | ---------------------------- | ------------------- | ---------------------------- | ---------------- | ------------- | ------------------- | ------------ | ------- | ------------------ | | \[Archetype] | \[Value proposition] | \[Enablement] | \[Incentive] | \[Geography] | \[Sector] | \[Channel] | \[Proof] | \[Risk] | \[Action] | *** ## 29. Appendix H: Suggested Pilot Engagement Pathway Template | Pilot Type | Partner Requirement | Buyer / Client Requirement | Scope Boundary | Funding Model | Milestones | Delivery KPI | Adoption KPI | Evidence Produced | Stop Condition | Next Decision | | ---------- | ------------------- | -------------------------- | -------------- | ------------- | ------------- | ------------ | ------------ | ----------------- | -------------- | ------------- | | \[Pilot] | \[Requirement] | \[Requirement] | \[Boundary] | \[Model] | \[Milestones] | \[KPI] | \[KPI] | \[Evidence] | \[Condition] | \[Decision] | *** ## 30. Appendix I: Suggested Evidence Threshold Template | Decision Type | Minimum Evidence | Confidence Requirement | Required Controls | Approval Path | Renewal / Review Trigger | | ------------------------- | ---------------- | ---------------------- | ----------------- | ------------- | ------------------------ | | Certify partner | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | | Fund enablement | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | | Co-sell with partner | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | | Co-fund implementation | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | | Renew partner status | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | | Remove or suspend partner | \[Evidence] | \[Confidence] | \[Controls] | \[Path] | \[Trigger] | --- # 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://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/product-researches-initiatives-grants/rfp-08-enterprise-delivery-partner-network.md?ask=&goal= ``` `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.