---
id: c9-proposal-design-template
title: Proposal Design Template
module: GROW-S9
module_slug: grow-s9-dao-governance
cluster: Coordination
type: template
version: v0.1.0
status: Gate-reviewed
tier: membership
contract_role: ""
canonical_url: "https://grow.goodcombinator.ai/library/registry/c9-proposal-design-template"
download_url: "https://grow.goodcombinator.ai/library/registry/c9-proposal-design-template.md"
license: CC-BY-4.0 (proposed — owner confirmation required)
source: GROW by Good Combinator
retrieved_at: 2026-05-29
---

# Proposal Design Template

The Proposal Design Template is the standard fillable scaffold for every governance action submitted to a DAO vote. A well-designed proposal is the governance equivalent of a well-specified agent task: it provides enough context for a voter to make an informed decision, carries verifiable evidence rather than assertions, names an executor and a timeline, and forces conflict-of-interest disclosure before the vote rather than after. This template provides both the fillable structure and the review checklist a Steward applies before the proposal enters the voting queue. Proposals that do not pass the review checklist are returned to the proposer; they do not enter the quorum or threshold calculation.

---

## 1. Standard Proposal Scaffold

Every proposal, regardless of decision class, must complete all required fields. Optional fields become required for specific decision classes as noted.

```yaml
# ─── PROPOSAL HEADER ───────────────────────────────────────────────────────────
proposal_id: <kebab-case, globally unique, e.g. pp-dao-prop-2026-011>
decision_class: <from c9-decision-rights-matrix §2, e.g. treasury-allocation>
title: <≤ 12 words; answer-first per Pyramid Principle>
submitted_by: <proposer identity; must satisfy proposer eligibility for the decision class>
submission_date: <ISO 8601>
review_period_opens: <ISO 8601; may equal submission_date>
voting_period_opens: <ISO 8601; must be ≥ minimum review period for this class>
voting_period_closes: <ISO 8601>

# ─── SUMMARY (Pyramid Principle: answer first) ─────────────────────────────────
summary: >
  <Lead with the decision you are asking for and the bottom-line outcome.
  2–4 sentences maximum. Supporting argument goes in §2. Detail goes in §3.>

# ─── DECISION REQUESTED ────────────────────────────────────────────────────────
decision_requested:
  type: <approve | reject | amend-and-resubmit>  # the voter is asked to approve or reject
  action: >
    <Specific action to be executed if passed. Must be implementable without further
    interpretation. "Allocate $X to Y for Z by date D" is valid. "Improve the system" is not.>
  amount_if_financial:
    currency: <USD | ETH | USDC | ...>
    amount: <number>
    tranche: <treasury tranche from c9-resource-allocation-framework>
  timeline:
    execution_start: <ISO 8601 or "within N days of pass">
    execution_deadline: <ISO 8601 or "within N days of pass">

# ─── EXECUTOR AND ACCOUNTABLE ──────────────────────────────────────────────────
executor_role: <role that will carry out the decision; must match c9-decision-rights-matrix Executor column>
accountable_role: <role held responsible for outcomes; must match Accountable column>
veto_holder: <role(s) that may veto; must match Vetoer column; "none" if no veto right>
veto_window_days: <integer; 0 if no veto right>
```

---

## 2. Supporting Argument and Evidence

This section provides the information voters need to evaluate the proposal. Evidence must be linked, not paraphrased.

```yaml
# ─── PROBLEM STATEMENT ─────────────────────────────────────────────────────────
problem_statement: >
  <What situation, gap, or obligation is this proposal addressing?
  Be specific: name affected systems, stakeholders, and timelines.>

# ─── PROPOSED SOLUTION ─────────────────────────────────────────────────────────
proposed_solution: >
  <How does the requested decision address the problem?
  State the mechanism, not just the goal.>

# ─── ALTERNATIVES CONSIDERED ───────────────────────────────────────────────────
alternatives_considered:
  - option: <Option A label>
    description: <one sentence>
    reason_not_chosen: <one sentence>
  - option: <Option B label>
    description: <one sentence>
    reason_not_chosen: <one sentence>

# ─── EVIDENCE PACK ─────────────────────────────────────────────────────────────
evidence:
  - id: <E1>
    type: <document | data | audit-record | on-chain-tx | signed-attestation>
    description: <what this evidence shows>
    uri: <resolving pointer; must be accessible to all voters>
    confidence_band: <high | medium | low | unknown>  # per glossary
  - id: <E2>
    ...
```

**Evidence rule:** Every factual claim in §2 must cite at least one evidence item by id. Claims without evidence citations are marked `[UNVERIFIED]` by the review Steward and may cause the proposal to fail the review checklist. Do not paraphrase evidence — link to the source so voters can inspect it directly.

---

## 3. Milestone Plan (Required for Milestone-Gated Proposals)

Required when the decision class is `treasury-allocation` with a total amount exceeding the `max_single_disbursement` threshold defined in `c9-resource-allocation-framework`, or when any proposal spans more than 90 days.

```yaml
milestones:
  - id: M1
    label: <human description>
    deliverable: <specific, observable output — links to E# above if possible>
    evidence_required: <what the Executor must submit to the milestone reviewer>
    tranche_amount: <currency amount released on completion>
    reviewer: <role; may not be the Executor>
    deadline: <ISO 8601 or "within N days of prior milestone">
  - id: M2
    ...
reversion_rule: >
  <What happens to un-triggered tranches if a milestone is missed.
  Default: revert to unallocated pool after N days past deadline.>
```

---

## 4. Conflict-of-Interest Disclosure (Required for All Proposals)

Every proposer must complete this section. The governance steward verifying the proposal is responsible for cross-checking the declaration against the voter registry before the voting period opens.

```yaml
conflict_of_interest:
  proposer_financial_interest: <yes | no>
  proposer_financial_interest_detail: >
    <Required if yes: describe the financial relationship and how it was handled.
    If no: "None.">
  related_party_voters: >
    <List any voters who have a direct financial or personal relationship with
    the proposer or with the beneficiary of this proposal.
    If none: "None identified.">
  recusal_required: <yes | no>
  recusal_detail: >
    <Required if yes: identify who is recused and from which vote.>
  no_self_vote_applicable: <yes | no>  # yes if decision_class is retroactive-reward
```

**Self-vote prohibition:** For `retroactive-reward` proposals, the nominee's voting address must be excluded from the tally before counting. The milestone reviewer confirms the exclusion before publishing results.

---

## 5. Contract-Change Supplement (Required for contract-change Class)

In addition to all sections above, a `contract-change` proposal must complete this supplement.

```yaml
contract_change_supplement:
  artifact_affected: <canonical id of the artifact being amended>
  amendment_type: <MAJOR | MINOR>  # per the artifact's change-control rules
  old_text: >
    <Exact current text being replaced — copy verbatim; do not paraphrase>
  new_text: >
    <Exact replacement text — copy verbatim>
  impact_statement:
    consumers_affected:
      - id: <canonical id of consumer artifact>
        impact: <how this change affects it>
      - ...
  migration_plan: >
    <How in-flight governance processes relying on the prior version are handled.
    Must address: open proposals, active milestones, running agents.>
  required_sign_offs:
    - role: Technical Lead
      signed: <yes | pending>
      date: <ISO 8601 or "pending">
    - role: Legal/Compliance Reviewer
      signed: <yes | pending>
      date: <ISO 8601 or "pending">
  advance_notice_date: >
    <14-day advance notice required per c9-decision-rights-matrix §3b.
    Date notice was published: <ISO 8601>>
```

---

## 6. Proposal Review Checklist

Before a proposal enters the voting queue, a designated review Steward (not the proposer) applies this checklist. Proposals that fail any `blocking` item are returned to the proposer.

| # | Check | Blocking? | Pass Criteria |
|---|---|---|---|
| 1 | Proposer eligibility verified | Yes | Proposer meets token threshold and role requirements for the stated `decision_class` |
| 2 | Title is answer-first, ≤ 12 words | No | Advisory; return if misleading |
| 3 | `decision_requested.action` is specific and executable | Yes | Action must be implementable without further interpretation |
| 4 | Executor and Accountable match `c9-decision-rights-matrix` | Yes | Both roles must match the matrix row for the stated class |
| 5 | Voting period respects minimum review period | Yes | `voting_period_opens` is ≥ minimum for the decision class |
| 6 | All factual claims cite evidence items | Yes | No `[UNVERIFIED]` claims in §2; all evidence URIs resolve |
| 7 | Conflict-of-interest disclosure complete | Yes | All fields populated; `recusal_required` reviewed |
| 8 | Milestone plan present if required | Yes | Required for amounts > `max_single_disbursement` or duration > 90 days |
| 9 | Contract-change supplement complete | Yes | Required if `decision_class: contract-change`; all sign-offs present or dated "pending" with a plan |
| 10 | Treasury impact within tranche ceiling | Yes | Proposed amount does not exceed tranche ceiling or push treasury below reserve floor |
| 11 | No self-vote risk unmitigated | Yes | If `retroactive-reward`, nominee exclusion mechanism confirmed with voting platform |

---

## 7. Worked Example — PP DAO Infrastructure Proposal

### Proposal: AI Inference Hardware Refresh at Point Preserve

```yaml
proposal_id: pp-dao-prop-2026-003
decision_class: treasury-allocation
title: Fund AI inference hardware refresh at Point Preserve
submitted_by: technical-lead-role
submission_date: 2026-02-01
review_period_opens: 2026-02-01
voting_period_opens: 2026-02-08     # 7-day review period for treasury-allocation
voting_period_closes: 2026-02-15    # 7-day voting window

summary: >
  Allocating $52,000 (illustrative) from the infrastructure tranche to replace
  aging on-site AI inference hardware will reduce per-request latency by ~40%
  and cut cloud-inference costs by ~$14,000/yr. Disbursement is milestone-gated
  across three tranches. Execution authority rests with the Treasurer.

decision_requested:
  type: approve
  action: >
    Disburse up to $52,000 (illustrative) from the PP DAO infrastructure tranche
    to procure and install AI inference hardware at 725 J D Miller Road by
    2026-06-30, per the milestone schedule below.
  amount_if_financial:
    currency: USD
    amount: 52000     # (illustrative)
    tranche: infrastructure
  timeline:
    execution_start: "within 7 days of veto window close"
    execution_deadline: 2026-06-30

executor_role: Treasurer
accountable_role: Treasurer
veto_holder: Founding Steward Council
veto_window_days: 2

problem_statement: >
  The current inference server (installed 2023, illustrative) cannot handle
  simultaneous guest-demo and campus-member workloads; P99 latency exceeds
  8 seconds. Cloud overflow costs ran $22,000 in 2025 (illustrative).

proposed_solution: >
  Replace with a purpose-built inference node that handles 4× concurrent
  sessions at < 2-second P99. Surplus capacity can serve EcoGuardian.AI
  sensor-inference tasks, reducing cloud costs below $8,000/yr (illustrative).

alternatives_considered:
  - option: Continue cloud-only
    description: No hardware capex; scale cloud instances
    reason_not_chosen: Cloud costs project to $28,000/yr by 2027 (illustrative); no long-term cost improvement.
  - option: Lease colocation
    description: Rent rack space in a regional data center
    reason_not_chosen: Eliminates on-site AI campus demo differentiation; travel latency to site is comparable.

evidence:
  - id: E1
    type: data
    description: 2025 cloud inference cost report
    uri: "s3://pp-dao/evidence/2025-cloud-cost-report.pdf"   # (illustrative)
    confidence_band: high
  - id: E2
    type: document
    description: Hardware vendor quote, 2026-01-28
    uri: "s3://pp-dao/evidence/hw-vendor-quote-2026-01-28.pdf"   # (illustrative)
    confidence_band: high

conflict_of_interest:
  proposer_financial_interest: no
  proposer_financial_interest_detail: "None."
  related_party_voters: "None identified."
  recusal_required: no
  recusal_detail: "N/A"
  no_self_vote_applicable: no
```

**Milestone plan:**

| ID | Deliverable | Evidence | Amount | Reviewer | Deadline |
|---|---|---|---|---|---|
| M1 | Hardware ordered and delivered to 725 J D Miller Rd | Delivery receipt + asset tag | $18,000 `(illustrative)` | Site Manager | 2026-03-31 |
| M2 | Infrastructure operational; load test passed | Benchmark report, Technical Lead signed | $22,000 `(illustrative)` | Technical Lead | 2026-05-15 |
| M3 | 90-day uptime ≥ 99.5% | Monitoring dashboard export | $12,000 `(illustrative)` | Technical Lead | 2026-08-15 |

Reversion: any unspent tranche reverts to `unallocated` pool 30 days past its deadline.

---

## 8. Review Period by Decision Class

| Decision Class | Minimum Review Period | Minimum Voting Period |
|---|---|---|
| `treasury-allocation` | 7 days | 7 days |
| `contract-change` | 14 days (+ 14-day advance notice = 28 days minimum) | 7 days |
| `working-group-charter` | 5 days | 5 days |
| `membership-change` | 7 days | 7 days |
| `parameter-update` | 14 days (+ 14-day advance notice) | 7 days |
| `retroactive-reward` | 5 days | 5 days |
| `platform-partnership` | 7 days | 7 days |
| `emergency-ratification` | 0 days (immediate) | 24 hours |

## Usage Notes

Fill the proposal scaffold completely before submitting for review. Incomplete proposals waste reviewer time and reset the review clock. The review checklist in §6 is the acceptance gate; the proposer should self-certify before submitting. All financial figures, URIs, and dates used in examples are `(illustrative)` — replace with verified values before a live proposal.