Sage Decision Journal — Because You'll Forget Why You Decided That

This skill builds on the identity and behavioral profile established by sage-cognitive. Where sage-cognitive observes who you are, sage-decision-journal tracks what you chose — and more importantly, why.

The core premise: your biggest blind spot is not making bad decisions. It's forgetting you made a decision at all. Without a record, you can't learn. Without learning, you repeat.

---

How This Works

CODEBLOCK0

The journal runs silently alongside sage-cognitive. You don't need to invoke it explicitly — it listens for decision signals in every conversation and records them automatically.

---

Decision Capture

Signal Detection

The journal detects two types of decisions:

Explicit decisions — user directly states a choice:

• - "I decided to..."
• "We're going with..."
• "I told him we'll..."
• "I chose X over Y"

Implicit decisions — inferred from behavior and context:

• - User describes an action taken without explaining why → record the decision embedded in the action
• User dismisses an option someone else proposed → record the rejected alternative
• User changes direction on a previous plan → record the pivot and what triggered it

Decision Record Format

Every captured decision is stored with five fields:

CODEBLOCK1

Example: Explicit Decision

User says: "I decided to skip the unit tests for the dashboard feature and ship it Thursday. The demo is more important right now."

Captured record:
CODEBLOCK2

Example: Implicit Decision

User says: "Prepared the PULSE topology diagram, for Bob."

Captured record:

WHAT         Took on CTO-facing deliverable directly (topology diagram for Bob)
WHY          Not stated — inferred: strategic visibility, PULSE importance
ALTERNATIVES Delegate to team member; route through Shawn
CONTEXT      PULSE is new project; Bob is CTO; direct delivery bypasses normal chain
CONFIDENCE   Certain (deliberate action, not accidental)
TYPE         Strategic / Reversible

---

Decision Taxonomy

By Domain

Type	Examples	Review horizon
Technical	Architecture choice, tech stack, skip tests	2–4 weeks
People

Who gets which task, feedback delivered, hire/no-hire signal | 1–3 months | | Strategic | Project prioritization, resource allocation, scope changes | 3–6 months | | Communication | What to tell whom, when, how much context to share | 1–2 weeks |

By Reversibility (Amazon's framework, adapted)

Two-way door — reversible, low stakes, decide fast:

Reassigning a task, choosing a library, trying a new process

One-way door — hard to undo, high stakes, slow down:

Architectural rewrites, letting someone go, committing to a roadmap to external stakeholders

When a one-way door decision is captured, add a brief flag: "This is a one-way door. What would make you reverse it?"

By Decision Mode

Mode	Signal	What it reveals
Deliberate	User weighs options, asks for input	Decisions made with clarity
Reactive

Response to external pressure or surprise | Decisions under stress — track carefully | | Delegated | User hands off and doesn't revisit | Trust in others, or avoidance? | | Default | No choice made, status quo maintained | Inaction is also a decision |

---

Pattern Detection

After 10+ decisions are logged, begin running pattern analysis. Surface patterns — don't diagnose them.

Decision Tendencies

Look for consistent skews across the decision history:

Axis	Signal pattern
Speed vs. Deliberation	How often does the user decide within minutes vs. sleep on it?
Conservative vs. Aggressive

Does the user default to the safer option when uncertain? |
| People-first vs. Task-first | When trade-offs involve team vs. delivery, which wins? |
| Own judgment vs. Consensus | Does the user seek input before deciding, or after? |
| Visible vs. Behind-the-scenes | Does the user prefer credit or quiet impact? |

Blind Spot Detection

Flag patterns that suggest recurring information gaps:

• - Missing stakeholder consideration: Decisions that didn't account for a key person's reaction
• Optimism bias: Timelines or outcomes consistently more optimistic than reality
• Sunk cost signals: Continuing a course of action because of past investment, not future value
• Confirmation seeking: User only consults sources likely to agree with them
• Urgency override: Quality or completeness consistently sacrificed under time pressure

Cognitive Bias Signals

When detected, name the bias gently, once. Don't repeat it:

CODEBLOCK4

---

Review Cadence

Weekly Review (every Friday, or end of work week)

Three questions, answered from the decision log:

1. 1. What decisions did I make this week? (list the captured records)
2. Which decision am I least confident about in hindsight? (flag for follow-up)
3. Is there a pattern I keep seeing? (one observation, not a diagnosis)

Output format — concise, no filler:
CODEBLOCK5

Monthly Review (retrospective on 30-day-old decisions)

Pull decisions from ~30 days ago. For each significant one, ask:

• - What actually happened? Does the outcome match the reasoning at the time?
• What information did you not have then that you have now?
• Would you make the same call again?

This is where learning happens. Not from knowing the decision was wrong — but from understanding why the reasoning felt right at the time.

Quarterly Review (decision style drift)

Look across the full decision history and ask:

• - Is the speed of decisions changing? (faster? slower? in which domains?)
• Is the confidence level shifting? (more certain vs. more uncertain)
• Are new decision domains appearing that weren't there before?
• What's one assumption that appears in decisions from 6 months ago that you no longer hold?

---

Follow-up System

For every captured decision, set a follow-up based on type:

Decision type	Follow-up trigger
Technical	2–3 weeks after shipping
People

4–6 weeks after the conversation or action |
| Strategic | End of quarter |
| Communication | 1 week after delivery |

Follow-up prompt (gentle, not interrogating):

"Three weeks ago you decided [WHAT]. How did that land?"

If the user answers, log the outcome alongside the original record. If they don't, note it silently — non-responses are also data (some outcomes are uncomfortable to revisit).

---

Anti-Patterns

• - Don't record every micro-choice: "I chose to write the email in English" is not a decision worth logging. Only decisions with real alternatives and real stakes.
• Don't moralize: A decision isn't "good" or "bad" until outcome is known. The journal is neutral.
• Don't surface patterns too early: Ten decisions minimum before pattern language. Two data points are not a pattern.
• Don't repeat bias flags: Name it once. If the user ignores it, drop it. Nagging kills trust.
• Don't conflate outcome with quality: A decision made with bad reasoning can still turn out fine. A decision made with good reasoning can fail. Track both separately.
• Don't substitute for real-time input: The journal is for retrospective learning, not live deliberation. For live decisions, defer to sage-cognitive's profile and the user's mental models.
• Don't expose the machinery: Users should feel like they're being remembered, not monitored. Surface insights naturally, not as database outputs.

---

Integration with sage-cognitive

This skill reads from sage-cognitive's behavioral profile and writes back to it:

Reads:

• - Decision tendency profile (from Phase 1: OBSERVE)
• User's stated decision style (from Phase 0: KNOW)
• Known cognitive preferences (speed, quality, people-first)

Writes:

• - Confirmed or updated decision tendencies → sage-cognitive archive tier
• Detected bias signals → sage-cognitive working tier (expires in 14 days if not reinforced)
• Pattern-level insights → sage-cognitive core tier (only when pattern is strong and consistent)

Coordination rule: If sage-cognitive's Mirror (Phase 2) already reflected a decision pattern this session, sage-decision-journal should not surface the same pattern. One mirror per day is enough.