# Decision Log and Revisit System Builder

Create a lightweight decision record that captures rationale, assumptions, ownership, and evidence-based triggers for revisiting important choices.

## Prompt

You are a decision operations specialist who designs lightweight records that help teams remember why choices were made and when to reconsider them.

Inputs:
1. Decision or recurring decision type: {{decision_context}}
2. Options, selected choice, and date: {{choice}}
3. Evidence, assumptions, and constraints: {{reasoning_inputs}}
4. Stakeholders, owner, and affected work: {{ownership}}
5. Uncertainty, review horizon, and available systems: {{review_context}}

Do the following:
1. Separate the decision statement from implementation tasks, background information, and unresolved questions.
2. Record the options considered, selection criteria, evidence, assumptions, constraints, dissent, and why rejected options were not chosen without fabricating missing rationale.
3. Identify assumptions most likely to change and convert them into observable revisit triggers, threshold values, or review dates.
4. Define ownership for monitoring triggers, communicating changes, superseding the record, and linking follow-up outcomes without rewriting history.
5. Produce a concise decision record, trigger-monitoring table, review agenda, status taxonomy, and reusable template suitable for the specified system. Keep the record short enough that people will maintain it.

## Best for

Teams and individuals making consequential choices that may need to be explained, audited, or revisited as assumptions change.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Use one record for one decision.
- Include rejected options and real evidence.
- Turn uncertain assumptions into measurable triggers.
- Link later outcomes without editing the original history.

## Customization tips

- Choose a template short enough for routine use.
- Record dissent when it affects future interpretation.
- Assign one owner for trigger monitoring.
- Use superseded status instead of deleting old decisions.

## Example input

Decision: Use a managed search service instead of operating an open-source cluster for the customer portal. Choice date: July 15. Evidence: managed option costs EUR 4,200 monthly, saves an estimated 0.6 engineer, meets EU hosting needs, and handled twice projected peak load in testing. Alternatives: self-hosted cluster and database-native search. Owner: platform director; affected teams: product search and SRE. Uncertainty: traffic forecast, provider price changes, and relevance quality in German. Review horizon: six months; system: Notion.

## Example output

The record states the choice and separates it from migration tasks. It captures cost, staffing, hosting, load-test evidence, alternatives, and the unresolved German relevance risk. Revisit triggers include monthly cost above EUR 6,000 for two months, p95 latency above 400 ms, German relevance score below 0.82, or a 30% provider price increase. The platform director owns monitoring, and any replacement decision creates a linked superseding record while preserving the original rationale.