> For the complete documentation index, see [llms.txt](https://admin-services.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://admin-services.docs.intersectmbo.org/guides/third-party-assurer-guides/reviewing-milestones.md).

# Reviewing Milestones

## Third Party Assurer (TPA) Verification Checklist

You can use this checklist as a final sense-check before submitting your Third Party Assurer Comments.

### Pre-assessment:

Before reviewing any deliverables, confirm the following:

* [ ] **Independence confirmed**\
  I have no financial, personal, or professional ties to the vendor or outcome of this milestone.
* [ ] **Right expertise**\
  I have the appropriate knowledge to assess this specific deliverable.
* [ ] **Proposal reviewed**\
  I have read the original proposal and understand the milestone acceptance criteria and deliverables in the signed contract. 
* [ ] **Scope is clear**\
  I know exactly what “complete” looks like for this milestone.

### Assessment: Evidence & Quality

When reviewing the milestone, validate both completion and quality:

* [ ] **Evidence provided**\
  The vendor has supplied clear, tangible proof (e.g. documentation, code, data, outputs).
* [ ] **Evidence is sufficient**\
  The materials provided are enough to confidently verify completion.
* [ ] **Matches the proposal**\
  The deliverable aligns with what was originally promised.
* [ ] **Quality standard met**\
  The output meets expected technical or professional standards (not just minimum effort).
* [ ] **Clarity & transparency**\
  Outputs are understandable, even for non-technical stakeholders where relevant.
* [ ] **No major gaps or risks**\
  Any issues, inconsistencies, or red flags have been identified.

### Final Attestation: Reporting

Before submitting your review, ensure your output is clear and actionable:

* [ ] **Clear outcome provided**\
  I have given a definitive result (e.g. Pass / Fail / Conditional).
* [ ] **Justification included**\
  My decision is supported by specific, evidence-based reasoning.
* [ ] **Actionable feedback (if needed)**\
  If not approved, I have clearly outlined what needs to be addressed.
* [ ] **Objective tone maintained**\
  My report is factual, unbiased, and free from personal opinion.

When reviewing your Vendor's milestones, consider the type of review that may be required. Here is an example of an assessment completed by an Independent Third Party for our Smart Contracts - <https://github.com/SundaeSwap-finance/treasury-contracts/tree/main/audits>

{% hint style="info" %}
Any documentation associated to the review may be requested to be made public at any point.
{% endhint %}

### Final Sense Check

Before submitting, ask yourself:

> **“Would someone outside this project feel confident that funds were well spent based on my review?”**

* ***Yes*** — the assessment is clear, evidence-based, and trustworthy
* ***No*** — further review or clarification is needed

{% hint style="info" %}

#### Key Reminder

You are the independent control in the process.

Your role is not to support delivery; it is to verify it objectively. If evidence is unclear or quality is not met, it is your responsibility to reflect that in your comments.

We want to ensure Treasury funds are being spent in line with the agreed contract.
{% endhint %}


---

# 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://admin-services.docs.intersectmbo.org/guides/third-party-assurer-guides/reviewing-milestones.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.