decision_log
Log a strategic decision with its rationale, alternatives, proof action, and review date to persist across sessions and trigger review if assumptions change.
Instructions
Log a strategic decision so it persists across sessions. Every decision needs a reason, alternatives, and a proof action. Optionally capture the assumptions that make it true and the invalidate_if conditions that should reopen it — these turn a timestamped 'no' into a testable frame the system can reason about later.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | The real reason | |
| type | No | ||
| decision | Yes | What was decided | |
| entity_id | Yes | Entity this decision applies to | |
| supersedes | No | Decision IDs this new decision replaces (e.g. ['dec-007']). Only the IDs you explicitly pass will be marked superseded — there is no auto-deduction from type. Each target must belong to the same entity_id. | |
| assumptions | No | The premises that make this decision true — e.g. ['users want human approval before sending', 'model reliability not yet sufficient for autonomous send']. If these still hold, the decision likely still holds. | |
| review_date | Yes | YYYY-MM-DD — when to revisit | |
| alternatives | No | Options considered | |
| proof_action | Yes | One concrete, observable action that validates this decision — e.g. 'Run npm test and confirm all 41 tests pass'. Placeholders like 'Review in next session', 'TBD', or 'Revisit' are rejected. | |
| invalidate_if | No | Condition-based review triggers ('what would make this false') — e.g. ['users show sustained trust in autonomous drafts', 'target workflow shifts from external email to internal triage']. Distinct from review_date (a time trigger): decision_check matches proposed actions against these to flag the decision for review rather than enforcing it blindly. | |
| chosen_direction | No |