Build Your Personal Assistant Operating System

3.9

Make Decisions Reviewable

Most decisions disappear the moment you make them

You decide to take a new client. You decide to raise your rates. You decide to prioritize Project Atlas over the marketing rewrite. You decide to skip the conference this year. Each of these decisions shapes the next several months, and none of them leave a trace unless you deliberately record them.

Without a record, you cannot learn from your own decisions. You cannot check whether your predictions were right. You cannot see patterns in your judgment. You lose the most valuable feedback loop available to you: comparing what you expected to happen against what happened.

The fixes this by logging three things every time you face a meaningful choice: what you decided, what you predicted would happen, and when you will check. The prediction is the key. It makes the decision reviewable.

A flat teaching diagram showing a decision record with options and prediction leading to a review date and outcome check — A prediction attached to a review date turns a decision from a moment into a learning opportunity.

Decision Journal

Promise	A of every significant decision: what you decided, why, what you predicted would happen, and a review date to check whether the prediction held.
Sources	Your input during the decision-making conversation. Meeting notes and email threads that provide . Previous decision records for pattern recognition.
Output	A decision record with fields for the decision, options considered, reasoning, prediction, confidence level, and a scheduled review date.
Saves to memory	Decision records with full . Prediction outcomes (correct, partially correct, wrong) added at review time. scores across all reviewed decisions.
Approval boundary	The journal records what you tell it. It never makes decisions on your behalf. Predictions are yours; the assistant helps you articulate them clearly.
Failure behavior	If sources are unavailable, the journal records the decision with your direct input only and notes which sources were missing.
Review criteria	Every decision record should include a . Review dates should be realistic (close enough to learn, far enough to see results).
Graduation trigger	When you have reviewed at least five decisions and the review process consistently produces useful insights.
Privacy tier	High. Decision records often contain strategic reasoning, financial , and personal priorities. Default to local-only processing.

Each entry captures the reasoning so future-you can evaluate it

A decision log entry has five parts:

What you are deciding: the specific choice in concrete terms.
What options you considered: at least two alternatives, including the option of doing nothing.
What you chose and why: the selected option with the reasoning that led to it.
What you predict will happen: a specific, with a timeframe. 'I predict this client will generate $15K in revenue over six months' is falsifiable. 'I think this will be good' is not.
When you will check: a review date, typically 30, 60, or 90 days later, when the system surfaces this entry and asks what happened.

The catches failure modes before you commit

Before logging a decision, the assistant asks one additional question: imagine this decision goes badly. What is the most likely reason?

This is a . It forces you to think through failure modes before committing. The assistant does not make the decision. It makes your thinking about the decision more rigorous. The pre-mortem answer gets stored with the entry so you can check whether the failure mode you predicted was the one that occurred (or whether something else went wrong entirely).

A flat teaching diagram showing failure modes feeding a decision and one safeguard added before commitment — A is useful when it turns at least one likely failure into a safeguard you can add now.

Your judgment gets sharper when you compare predictions to outcomes over months

At the review date, the system surfaces the entry and asks: what happened? You write a short update. 'The client generated $12K in six months, close to my prediction of $15K. The scope did expand as I worried about in the , but I managed it by renegotiating the retainer in month three.'

Over months, a track record builds. Are you consistently overconfident? Underconfident? Better at people decisions than financial ones? Better under pressure than with time? The patterns emerge from the data, and they are specific to you.

A flat evidence table showing career, financial, and relationship decision accuracy by comparing predictions with outcomes — A track record shows where your predictions are calibrated and where your judgment needs more skepticism.

The advisor mode queries your own track record before you decide

When facing a new decision, you can ask the assistant to reference past decisions. 'I am considering raising my rates by 20 percent. Have I made similar decisions before? What did I predict? What happened?'

The assistant queries the decision log and returns: 'You raised rates by 15 percent in January. You predicted one client would leave. Two stayed but renegotiated scope. Net revenue was up 8 percent against your prediction of 12 percent.' You now make the current decision with access to your own track record.

No standard app combines a decision log with prediction tracking, accuracy scoring, and the ability to search your own past decisions. This is one of the modules where the system does something you genuinely cannot get elsewhere.

Decision templates speed up logging for recurring types

Some decisions recur in similar shapes. A hiring decision asks different questions than a financial investment. A client-acceptance decision asks different questions than a tool-purchase decision. Templates save time by pre-loading the relevant questions.

How this module breaks

What goes wrong	How you notice	What to correct once	What rule to save
The clean formatting of a decision record creates false confidence in a decision you have not examined carefully.	You feel certain about a decision because the record looks thorough, even though the reasoning section restates your initial instinct without challenging it.	Add a step to every decision record: before finalizing, ask the assistant to describe one plausible scenario where this decision fails.	Every decision record includes a : one specific, plausible failure scenario. The pre-mortem appears in the record alongside the reasoning.
You stop reviewing decisions because the review dates pile up and feel like homework.	Decision records accumulate without review. scores are empty. The journal loses its value as a learning tool.	Batch reviews into the . The weekly review surfaces decision records due for review alongside other system checks.	Decision reviews are part of the , not a separate task. The weekly review surfaces all decisions due for review that week.
Predictions are too vague to evaluate at review time.	A prediction says 'this will probably work out' and at review time you cannot determine whether it was correct.	Require falsifiable predictions with specific, observable outcomes: 'Revenue from this client will exceed $10K in Q3' rather than 'this client will be good for business.'	Predictions must name a specific, observable outcome and a timeframe. The assistant prompts for specificity if a prediction is too vague to evaluate.

Your turn

Log a decision with prediction and review date

You'll create a decision log entry with options, reasoning, prediction, pre-mortem, and a review date.

Why this exercise matters

Decisions without predictions cannot be evaluated. The prediction is what makes the entry useful months later when you check whether your judgment was right.

You’ll leave with

A complete decision log entry.
A specific, falsifiable prediction with a timeframe.
A pre-mortem identifying the most likely failure mode.
A review date when the system will surface this entry.

Use the prompt in order

1
Describe the decision and let the assistant structure it
Tell the assistant what you are deciding, what options you are considering, and what you are leaning toward. The assistant will organize this into a structured entry and ask follow-up questions about anything you left out.
2
Write a specific, falsifiable prediction
The prediction should be concrete enough to check later. 'This will work out well' is not falsifiable. 'This client will generate $15K in revenue within six months' is. The assistant will push you to be specific if your prediction is vague.
3
Run the pre-mortem
Imagine the decision went badly. What is the most likely reason? Write it down. Check whether you can address that risk before committing. The often changes the decision or adds a safeguard.
4
Set the review date
Choose when to revisit: 30, 60, or 90 days depending on the decision type. The system will surface the entry on that date and ask what happened.

Prompt details

Each detail will be inferred, or you will be asked to clarify in the chat.

1/1 details

1 detail will be inferred, or you will be asked to clarify in the chat

Starter prompt text

Open the full text if you want to check what will be copied.

Show starter prompt

Help me log a decision in my decision journal.

The decision:
Infer from what you know about me or ask if it is unclear

Walk me through:
1. Structure the options I considered (including doing nothing).
2. Record my choice and reasoning.
3. Help me write a specific, falsifiable prediction with a timeframe.
4. Run a pre-mortem: if this decision goes badly, what is the most likely cause?
5. Set a review date.

Format the entry as a decision log record I can save and revisit. Mark any assumptions you made about my situation.

What the answer should give you

A decision log entry with: decision (take the new client), options considered (accept as proposed, accept with modified scope, decline), choice and reasoning, prediction ('I predict this client will generate $15K in net revenue over six months, with scope requiring renegotiation by month three'), pre-mortem ('most likely failure: scope creep beyond the retainer'), and review date (90 days).