---
name: carbon-decision-memos
description: Write structured decision memos for carbon project choices — registry selection, methodology selection, measurement architecture tradeoffs (estimation vs. in-situ), buyer/offtake structure, and other consequential project decisions where the tradeoffs need to be documented before locking in. Use whenever the user is weighing a carbon-project-specific decision and wants it written up formally, or says things like "help me think through whether to use X or Y methodology/registry," "document why we chose," or "write up the tradeoffs." Trigger proactively when other skills in this pack (pdd-generator, carbon-project-timeline) flag an unresolved decision blocking progress.
---

# Carbon Project Decision Memos

Writes the decision memo that should exist before a consequential, hard-to-reverse carbon project choice gets locked in. Methodology selection, registry choice, and measurement architecture decisions are expensive to reverse once a PDD is in validation, so the memo exists to force the tradeoffs onto paper before the team commits, not to retroactively justify a decision already made.

## When this gets triggered organically

Other skills in this pack should route here when they hit an unresolved fork:
- `pdd-generator` hits a methodology choice with no clear single answer.
- `carbon-project-timeline` flags that validation can't be scheduled because methodology/registry isn't locked.
- `carbon-legal-agreements` hits a structural choice (forward sale vs. spot ERPA, aggregator vs. direct landowner agreements).

When the user is mid-task in another skill and hits one of these forks, don't just pick an answer and move on. Flag it, offer to write the decision memo, and let the user decide whether they want the formal version or just a quick verbal call before continuing.

## Memo structure

Keep it tight. A decision memo that takes longer to read than the decision is worth defeats the purpose.

1. **The decision** — one sentence, framed as a question with a deadline ("Which methodology do we register under for the [project], needed before [date] to hit the validation window").
2. **Context** — why this decision matters now, what's forcing the timeline.
3. **Options** — 2-4 real options, not a strawman plus the obvious answer. Each option gets:
   - What it actually commits the project to
   - Cost/time/rigor tradeoff
   - What breaks if this turns out to be wrong
4. **Recommendation** — pick one. Don't hedge with false balance if one option is clearly stronger given the project's actual constraints; state the reasoning plainly.
5. **What this decision does NOT resolve** — name the follow-on decisions this unlocks or forecloses, so the team isn't surprised later. (E.g. "Choosing VM0044 forecloses the option to register under Gold Standard's parallel biochar methodology without restarting baseline work.")
6. **Reversal cost** — explicit statement of how expensive it is to change this decision later (cheap/moderate/expensive, with the actual reason why).

## Common decision types in carbon projects

- **Registry selection** — Verra vs. Gold Standard vs. ACR vs. CAR. Drivers: target buyer preferences (some buyers have registry preferences baked into procurement policy), co-benefit story strength, methodology availability, timeline.
- **Methodology selection** — see `references` in `pdd-generator` for the technical comparison; this memo documents the actual reasoning and tradeoffs for the project file.
- **Measurement architecture investment** — estimation-tier (cheap, fast, lower credit price/quality) vs. in-situ hardware-verified (capital intensive, slower to deploy, higher credit price and buyer confidence). This is a real capital allocation decision, not just a technical one, frame it that way.
- **Buyer/offtake structure** — spot sale post-issuance vs. forward sale for project financing. Forward sale solves cash flow but creates delivery risk if verification slips; document that tradeoff explicitly rather than defaulting to whichever a financing advisor suggested.
- **Aggregation structure** — single project vs. aggregated multi-landowner project under one PDD. Aggregation reduces per-unit transaction cost but increases monitoring complexity and concentrates non-permanence risk; this decision interacts directly with `carbon-legal-agreements` landowner agreement structure.

## Drafting principles

- No false balance. If the project's actual constraints (timeline, capital, existing infrastructure) clearly favor one option, say so directly rather than presenting all options as equally weighted.
- Lead with failure modes, not upside. What breaks first under each option matters more than what's exciting about it.
- Quantify wherever the project has real numbers (cost deltas, timeline deltas, credit price deltas). Don't leave tradeoffs purely qualitative if hard numbers exist.

## Output format

Short markdown memo, one to two pages. Not a slide deck, not a long-form report. This is meant to be read and acted on, not presented.

## Related skills

- `pdd-generator`, `carbon-project-timeline`, `carbon-legal-agreements` — the skills most likely to surface a decision needing this memo.