Keep a Log of What You Asked the AI

The habit that fixes the gap is small: keep one line per ask in an append-only plain-text file you own — the date, what you asked, and what you decided to do with the answer. Your AI tool already stores the conversation. Nothing stores your verdict about it: what you trusted, what you edited, what you threw out.

That verdict is the part worth keeping. The chat transcript is the model's record of the exchange. The decision is yours, and right now it lives nowhere — in your head until you forget it, then gone. This idea is not new. The enterprise version has a name, an academic literature, and a working definition. The personal version is one plain-text line, written by you, that survives switching tools.

This is a how-to, not a manifesto. It covers the fields worth recording, a five-minute version and a thirty-minute version, the mistakes that quietly kill the habit, and the honest limits of a log you write yourself. You bring an AI tool you already use. At the end you have a file you control.

What is an AI decision log, and why keep one?

A decision log records what you asked an AI and what you did with its answer. It is distinct from the transcript: the transcript is the conversation, the log is your judgment about it. The academic framing is an "audit trail" — scaled down to one person, that becomes a single dated line in a plain-text file you own.

The principle is recognized research, not a productivity fad. In a January 2026 paper, Victor Ojewale, Harini Suresh, and Suresh Venkatasubramanian define the idea precisely: "An audit trail is a chronological, tamper-evident, context-rich ledger of lifecycle events and decisions that links technical provenance ... with governance records ... so organizations can reconstruct what changed, when, and who authorized it." ¹ Your personal log is the low-tech, you-own-it version of exactly that ledger.

The same paper names why this matters now. Large language models "are increasingly embedded in consequential decisions across healthcare, finance, employment, and public services," yet "accountability remains fragile because process transparency is rarely recorded in a durable and reviewable form." ² That last phrase is the whole gap. A plain-text line closes it for one person.

What fields should each entry have?

Keep four fields per line: the date, the ask, your verdict, and why. The enterprise audit-trail literature records far more — but most of it serves compliance, not you. The skill is scaling down. Take the fields that help future-you remember and reconstruct, and drop the ones that exist only to satisfy a regulator.

The full enterprise field set is long. One practitioner guide lists "logging prompt text, data uploads, and the AI's generated responses," plus "metadata - such as model version, inference parameters, processing time, and confidence scores." ³ A cleaner minimum, from the same source's framework guide, is shorter: an audit trail should document "inputs, outputs, model versions, timestamps, and the entities responsible." ⁴ That is the menu. You order four dishes from it.

Here is the personal version, with the reasoning behind each field:

The enterprise pattern that makes this work is the append-only log. As one industry guide puts it, "the most reliable pattern is an append-only log where each entry represents one phase of a decision trace." ⁵ Append-only means you add lines and never edit old ones. Your date is the low-tech stand-in for what that literature calls a correlation ID — the thing that "ties all events from a single decision together." ⁶

The five-minute version

Open one plain-text file, name it ai-log.md, and add one line every time an AI answer changes what you do. Date, ask, verdict, why. That is the entire system. It works because the friction is almost zero — you are appending a sentence, not filling a form.

Follow these steps:

1. Make the file. One markdown file, stored on your own device. Call it ai-log.md. Pin it where you will see it.
2. Write the header once. A single line so future-you knows the shape: date | ask | verdict | why.
3. Append after a real decision. Not every prompt — only when the answer changed something you did.
4. Keep it to one line. If it needs two, you are writing a journal, not a log. Save the prose for elsewhere.
5. Never edit old lines. Wrong yesterday stays on the record; correct it with a new line today.

A worked example, copy-pasteable:

# AI decision log
date | ask | verdict | why

2026-06-23 | drafted onboarding email | edited | tone too eager, cut two lines
2026-06-23 | regex for parsing dates | used as-is | tested on 12 inputs, passed
2026-06-22 | "is this contract clause standard?" | rejected | not legal advice, asked a lawyer
2026-06-22 | summarize 40-page report | edited | missed the cost section, added it back
2026-06-21 | name for the new feature | rejected | three options, all generic

Read those five lines back in a month. The transcript could not give you that — it would give you five long conversations and no verdict. The log gives you the verdict and skips the conversation.

The thirty-minute version

The thirty-minute version adds two optional columns — the tool and a link — and a weekly read-back. Same one-line discipline, slightly richer. Use it when you ask several AI tools the same kind of question and want to notice which one you keep editing or rejecting.

The two added fields:

• Tool. Which assistant gave the answer. Worth it only if you use more than one; otherwise it is noise.
• Pointer. A short note or fragment that lets you find the original chat — the transcript still lives in the tool, and your log is the index into it, not a replacement for it.

The richer line looks like this:

date | tool | ask | verdict | why | pointer

2026-06-23 | assistant-A | rewrote API error copy | edited | too verbose | chat "error-copy"
2026-06-23 | assistant-B | same prompt, error copy | used | cleaner, kept it | chat "error-copy-2"

Then, once a week, read the file top to bottom. Count the verdicts. A column that is mostly "rejected" for one tool and mostly "used" for another tells you something no benchmark will. The pattern is in your own judgments, recorded over time — which is the whole reason to keep them where you can re-read them.

A tool worth knowing about already embodies this habit. Simon Willison's llm command-line tool "defaults to logging all prompts and responses to a SQLite database." ⁷ It is an ally example, not a competitor: proof that the people closest to these models also keep a local record, automatically. Your version trades the automation for portability — a plain-text line reads anywhere, with no database to open.

Common mistakes

The log dies from four predictable mistakes, and all four are about discipline, not tooling. The habit's value is the friction of writing down what you decided. That same friction is why people skip it. Name the failure modes and you can route around them.

• Logging the prompt, not the decision. A list of questions you asked is a worse transcript. The verdict — used, edited, rejected — is the only column the tool cannot give you. If you drop it, delete the file.
• Writing paragraphs. A log you have to compose is a log you abandon. One line, four fields. The moment an entry needs editing for prose, the habit is dead.
• Editing old lines. Append-only is the point. A log you rewrite is a story you tell yourself, not a record you can trust. Wrong entries get corrected by new entries, never by deletion.
• Trusting it to be more than it is. A self-written log is not tamper-evident and not legally accurate; you could fudge it, and only you would know. Its honest value is recall and portability, not proof.

That last mistake deserves its own section, because the gap between a personal log and an enterprise audit trail is where over-claiming happens.

What a personal log is not

A personal log is not a compliance system. The audit-trail literature describes organizational accountability — cryptographic signing, retention rules, regulatory attestations. The arXiv definition itself specifies "tamper-evident" ¹. A plain-text line you write is none of that. It gives you portability and recall. It does not give you proof.

Three honest limits, stated plainly:

• It is human discipline, not auto-capture. Nothing records the line for you. The friction is the feature and the flaw — it makes you decide what mattered, and it makes the habit easy to skip. If you want the counterweight argument, read the case for deleting your second brain before you commit.
• It is not tamper-evident or compliance-grade. You are borrowing the field list, not the legal weight. For anything an auditor or court would touch, you need the real system, not a markdown file.
• It is not medical, legal, or financial advice — and your log does not make it so. If the ask was about health, money, or the law, the line is a memory aid. The professional you should still consult is a professional, not your notes.

Inside those limits, the value is narrow and real: a portable, grep-able record of your own judgment that outlives any single tool's history panel.

How this fits with your transcript and your agent log

This log is one of three records, and it owns the human-decision layer. The other two are siblings: the transcript (the conversation) and the agent log (the machine's actions). Keep all three and you can reconstruct not just what was said and done, but what you chose. Keep only the transcript and your judgment vanishes.

The trio divides cleanly:

• The transcript is the raw conversation. Getting it out of the vendor and into files you keep is its own task — see how to own your AI chat history. That is the model's record of the exchange.
• The agent log is the record of what an AI did on your behalf — the actions, not the chat. When an agent acts and something breaks, the only durable record is the one you keep. That is the machine's record of itself.
• This decision log is what you trusted, changed, or rejected. It is the human's record, and it is the one nothing else writes for you.

The demand for all three is loud right now. In June 2026, a Hacker News post titled "AI agent bankrupted their operator while trying to scan DN42" reached 1,467 points ⁸ — one of several high-vote threads asking the same question: when an AI acts, what is the record? The honest answer keeps coming back to a file you own.

How this works in MNMNOTE

A decision log wants exactly what MNMNOTE provides: a plain-text, append-only file that stays on your own device and reads in any tool. MNMNOTE is local-first and works offline — your log lives in open Markdown on your device, not in a vendor's hidden activity history. No account stands between you and the line you just wrote.

The fit is structural, not promotional. The whole point of the log is that it outlives any single AI tool's history panel — so the file has to be one you control, in a format any editor can open, today and after the next tool shuts down. A markdown file on your device is that. The grep that finds every "rejected" line works the same in five years as it does tonight.

Frequently asked questions

How should I keep track of what I asked an AI and what I decided to do with its answer?

Keep a one-line-per-ask, append-only log in a plain-text file you own: date, the ask, your verdict (used, edited, or rejected), and one clause of why. The conversation lives in the tool; this records your judgment, which the tool does not. Append after any answer that changed what you did.

How is this different from just keeping my ChatGPT history?

Your chat history is the conversation, stored on the vendor's servers. It can be disabled, and deleting a chat queues permanent removal. The history is a view you rent; your decision is a record you keep. The two are complementary — export the transcript if you want it, but log your verdict separately, in a file you control.

What should I actually log about my AI usage?

Four fields are enough: date, the ask, your verdict, and why. The enterprise audit-trail literature records far more — model versions, parameters, confidence scores ³ — but most of that serves compliance, not recall. Log what future-you needs to reconstruct a decision, and skip the rest.

Does a personal log replace my AI chat transcript?

No. It complements the transcript and the agent log. The transcript is the conversation, the agent log is what an AI did on your behalf, and this is what you decided. Each captures a different layer; none replaces the others. The decision log is simply the only one nothing else writes for you.

Is a self-written log trustworthy or tamper-proof?

No, and that is honest. A log you write yourself is not tamper-evident and not compliance-grade — you could change it, and only you would know. Its value is recall and portability, not proof. For anything an auditor, court, or clinician would rely on, you need a real audit system, not a markdown file.

Where does my log go if I switch AI tools?

Nowhere — that is the point. A plain-text file lives on your own device, independent of any AI vendor. Switch tools, delete a chat, lose access to a history panel: the log is untouched. It is portable across every AI tool precisely because it belongs to none of them.

Your AI tool will remember the conversation long after you have forgotten why you trusted it. The one line that records your verdict is the part only you can write — and the only part worth keeping.

This habit builds on the audit-trail framing of Ojewale, Suresh, and Venkatasubramanian ¹, the append-only pattern from the enterprise decision-trace literature ⁵, and Steph Ango's case that "apps are ephemeral, but your files have a chance to last" ⁹.

To keep your own log as a file you control, mnmnote.com opens to a blank plain-text page.