Delivery Assurance Process and Best Practice Policy
1. Policy title: Delivery Assurance Process and Best Practice Policy
2. Version: 1.0
3. Effective date: 15 June 2025
4. Review date: Annually, next applicable June 2026
5. Policy owner: Head of Operations
6. Policy sponsor: Intersect Executive Director
7. Purpose:
This document is intended to provide guidance to all beneficiaries (as defined below) working under contracts administered by Intersect, including smart contracts and legal contracts. This guidance aims to clarify how beneficiaries can align with Intersect’s Delivery Assurance (DA) processes to ensure contracts are executed transparently, with accountability, and in line with community expectations.
8. Scope:
This policy applies to the beneficiary, as defined below, who enters into contractual relationships, transactions, or projects with Intersect or with Cardano Development Holdings (CDH) where Intersect is acting as its Administrator.
9. Principles:
This policy is founded on principles of openness, accountability, and the right to information, fostering trust among stakeholders/the community. It ensures a common understanding of Delivery Assurance requirements across all proposals.
10. Definitions:
Beneficiary: Individual or Company who will be receiving funds and/or entering into contractual relationships with Intersect or with CDH where Intersect is acting as its Administrator.
Cardano Development Holdings (CDH): CDH is a legal entity created to support the Cardano ecosystem by acting as the contracting counterparty for approved proposals by DReps.
Milestone(s) means the dates by which a part or all of the Services is to be completed, as set out in a Statement of Work.
Milestone Acceptance Form (MAF): This is a written attestation in the form of a standard template, submitted by a vendor, for each milestone.
Intersect: Intersect serves as an Administrator within Cardano’s funding ecosystem, helping to operationalize community-approved proposals by coordinating due diligence, contracting, and on-chain disbursements. This role is grounded in the principles of transparency, decentralization, and adherence to the Cardano Constitution.
Statement of Work means the document describing the Services and Deliverables to be provided by the Vendor, the Milestones, date of completion, expected quality standards, and associated fees.
11. Policy statements:
Beneficiaries remain fully responsible for delivering quality and value. Through transparency and sharing of milestone progress, reputation and open accountability keep the Cardano community is informed of development and treasury spend.
The MAF and invoice must be submitted within 5 business days of milestone completion.
If, in the opinion of Intersect (acting as the Administrator), the Milestone is incomplete or insufficiently completed, it is understood that payment may be delayed until the Milestone is complete. A consecutive failure to successfully complete a Milestone on two or more occasions may result in the termination of the Agreement or the corresponding Statement of Work.
12. Roles and responsibilities:
The person responsible for producing the work, e.g. Project Lead / Technical Owner - Responsible for executing the work. They confirm via the MAF that the completed milestone accurately reflects the milestone description and meets all defined acceptance criteria.
Third-party Assurance signature - Responsible for the secondary verification, ensuring the milestone has been reviewed and that its delivery meets the acceptance criteria defined in the contract ( examples of this are below).
Intersect Delivery Assurance - Responsible for overseeing the administrative process, ensuring adherence by both the vendor and the second attestor.
13. Procedures:
Contract initiation: When writing a SoW, consider how to clearly break up the work into tangible milestones. This will be checked and formally agreed with the Intersect Procurement team prior to contract signature.
Milestone description: When naming and describing a milestone, consider the following principles:
Be concise and specific - Avoid vague language or technical jargon. Aim for language that even a non-SME community member could understand.
Be outcome-based - Focus on what will be delivered, not what will be done. Think about what the end-user or Cardano community will receive as a result.
Use consistent naming and numbering - Number and name milestones clearly so they can be tracked and referenced easily throughout the project lifecycle.
Set realistic, achievable milestones - over-ambitious milestones can demotivate and cause delays.
Timeline - provide a realistic timeline that when the milestone will be completed by. Build in contingency to these dates where appropriate.
Acceptance criteria: Each milestone should have clear and testable acceptance criteria. These serve as the basis for milestone review and approval. Good acceptance criteria should be:
Measurable and objective – They can be independently verified by reviewers.
Output-driven – Evidence of delivery should be visible and public where appropriate (eg GitHub commits, documentation, videos, working demos).
Binary – Criteria should define whether the milestone is complete or not, leaving no room for interpretation.
Third-party assurance: To ensure adequate delivery assurance and oversight, each milestone is required to have a second capable vendor/person/organization who can help attest to the quality delivered and the milestone being complete. From the beneficiary’s perspective, this approach provides increased transparency to the Community and objective verification strengthening the quality of the milestone being delivered. This assurer does not need to be the same person throughout the contract if the beneficiary believes that a better person is suited to a particular milestone. Alternatively, if providing public evidence to the Community better demonstrates the milestone's achievement (eg, a Video, an X-post), this is also acceptable but the beneficiary may be asked to justify the reasoning behind this decision. When selecting the third-party assurer, please ensure:
The assurance provider is genuinely independent of the delivery team, from a different company, and independent of any key stakeholders with vested interests.
They have the necessary expertise relevant to the deliverable being assessed.
They are independent of an Intersect Committee.
Intersect Delivery Assurance team will verify with the vendor that the third party assurer is acceptable and falls within these conditions.
Contract management: Once the milestone is complete, a completed Milestone Acceptance Form (MAF) must be submitted to Delivery Assurance. Below is some guidance on what to include.
Milestone Name(s) & Number(s): To enable identification of the milestone, this should be written as per the contract.
Milestone Description: Include the milestone description as per the contract to help reviewers and the community to understand the milestone context.
Acceptance Criteria Met: Explain how the work meets the contract’s acceptance criteria and describe what was delivered. To facilitate approval by the Delivery Assurance team, please include supporting links where possible. Ensure they are visible to stakeholders to support progress tracking and communication and also to support the Delivery Assurance process in verifying your work. These may include:
GitHub repositories or pull requests
Testnet/mainnet deployment addresses
Public documentation
Demo videos
Reports or audits
Open community AMAs and demonstrations
Quality and Testing: Demonstrate how the milestone meets quality expectations (eg, responsive design, production deployment). Describe how the quality of this milestone was assessed; see below for some guidance:
Automated Testing
Manual Testing
Code Review / Peer Review
User Acceptance Testing (UAT)
Issue Tracking & Bug Fixes
CI/CD Validation
Security Testing
Stakeholder Feedback Collection
Community Review / Public Sharing
Expert or Committee Review
Public Communication Summary: This section can be useful for the community to follow the progress of the project. Write a summary that can be shared publicly. Use the following pointers as guidance: Project Purpose, Context, Milestone Achievement, Benefits to the Community. Include a link to where the community can find project or progress updates. Below is some guidance on how to do this:
Explain what the project is about
What was achieved in the milestone
Why it matters
How does it benefit the network or community
Transparent Project Planning and progress updates.
Public project board.
Maintain a public GitLab repo or equivalent.
Include a milestone roadmap / timeline and anticipated delivery dates.
Document progress, changes and blockers in GitLab or other publicly accessible platforms (eg a blog).
Community-friendly, plain English language.
Beneficiaries are also encouraged to host regular Ask Me Anything (AMA) sessions.
Signature Authorization: The final section of the form requires signature from three parties: The person responsible for producing the work, Third-party Assurance and Intersect Delivery Assurance. Where applicable, make sure any other policy or constitutional requirement deemed necessary by the administrator has been fulfilled.
Incomplete MAF: If a MAF is deemed to be incomplete by the DA team, including missing the third-party assurance without any clear justification, the beneficiary will be informed and requested to provide supplementary information. If this causes substantial delays, then the payment for the milestone in question may be deferred to the next payment cycle. As per the policy statement (section 11), if there is a consecutive failure to successfully complete a Milestone on two or more occasions, this may result in the termination of the Agreement or corresponding Statement of Work.
14. Monitoring and compliance:
Monitoring: Intersect, as the administrator, will monitor the completion of milestones, documentation, and payment throughout the contract lifecycle, overseeing that the appropriate delivery assurance is undertaken.
Compliance: Significant compliance breaches may be disclosed to the community through public reports and escalated to DReps as appropriate, in alignment with transparency commitments.
15. Review and amendment:
To ensure the policy remains current and effective, it will be reviewed at least annually. In response to significant organizational changes or regulatory updates, the policy will be updated as required by the Intersect Operational Services team and approved via the Intersect Executive team.
16. Related documents/references:
This policy should be read in conjunction with the following documents, guidelines and regulatory frameworks:
Cardano governance and policy documents
Transparency Policy
17. Examples
Last updated
Was this helpful?