record-decision

Record Decision

/record-outcome closes the quantitative flywheel loop — predicted vs. realized EV/IRR/MOIC. This command closes the qualitative one: the reasoning an analyst gives when a deal reaches a decision point. "We passed because customer concentration was too high at 45%" is not capturable as a number, but it is exactly the kind of institutional memory that makes /similar-deals and /playbook-recall sharper over time — a future deal with the same concentration profile should surface this one, with the reason attached.

Every decision is recorded as its own row. Unlike outcome tracking (one row per deal, initialized once), a deal can accumulate several decisions over its life — a pass that gets reconsidered and later closes, a close that later gets unwound. Nothing is overwritten; the history stays queryable.

Usage

/record-decision <deal_id>

Arguments

• <deal_id> (required) — the deal this decision is about.

Execution

The instructions below are for the model executing this command.

1. Determine decision_type. Must be one of: closed, passed, exited, withdrawn. Infer it from what the user said (e.g. "we're passing on this" → passed; "we closed the deal" → closed; "seller walked away during exclusivity" → withdrawn; "we sold our stake" → exited). If it's ambiguous, ask.

2. Get decision_rationale. This is the one truly required field beyond the type — it must be at least 10 characters and should capture the actual reasoning, not a restatement of the decision. "Passed" is not a rationale; "customer concentration was too high at 45%, and the two largest accounts had no long-term contracts" is. If the user's message already contains the reasoning, use it verbatim (lightly cleaned up); don't ask them to repeat themselves.

3. Call record_deal_decision with deal_id, decision_type, decision_rationale, plus whatever of the following the conversation actually supports — never invent values for fields the user didn't mention:

   • key_risks_identified — risk tags that drove the decision (e.g. ["customer_concentration", "key_person_dependency"]).
   • key_opportunities_identified — opportunity tags, if the decision was opportunity-driven (e.g. a close driven by expansion potential).
   • assumptions_validated / assumptions_invalidated — which underwriting assumptions held up or didn't (e.g. {"revenue_growth": "held, actually beat by 3pp"} or {"synergy_estimate": "was roughly 2x too optimistic"}).
   • lessons_learned — freeform, for future deals of this shape.
   • would_reconsider / reconsider_conditions — if the user signals this decision isn't necessarily final (e.g. "we'd revisit if the price came down 20%").
   • deal_patterns — pattern tags for cross-deal learning, e.g. ["high_customer_concentration", "saas_rollup"]. These are what /similar-deals matches on later, so tag generously when the conversation supports it.
   • sector — only if the deal's own profile doesn't already carry the right industry; the tool auto-populates from the deal's company profile when omitted.