The Research Logbook Method

The Research Logbook Method (RLM) is the practice Cuaderno implements. It distils habits common to prolific researchers — Faraday’s notebooks, Darwin’s dated entries, Hamming’s “important problems,” Knuth’s and Tao’s working logs — into eight concrete practices across two tracks (seven in RLM 1.0; see Method version). Each maps onto one or more note types the tool manages.

Two tracks

Research is two jobs at once. Inquiry is open-ended, driven by questions and evidence. Operations is delivery — deadlines, collaborators, promises. Most systems handle one and force the other into its shape. The RLM keeps them separate and lets them share a substrate: the daily log, the weekly review, and one set of projects that bridges the two.

Track 1 — Inquiry: how you investigate

1. A chronological log (Faraday). A single append-only stream of what you did, observed and thought, in the order it happened. Past entries are never edited; a change of mind is a new entry referencing the old one. The one exception is an address: when a page is renamed, every reference to it is corrected to the new name, the old name is kept on the page, and the rename is itself an entry. It removes the “where do I put this?” decision, preserves the reasoning and not just the result, and keeps you honest against hindsight. Unified across contexts — the regularisation weight and the plumber go in the same day.
2. Evidence portfolios (Darwin). One folder per active question, accumulating whatever is relevant. The log interleaves many questions; the portfolio aggregates one. Name the folder practically, but phrase the question at the top of its index: “sparse models” names a topic, “does the sparse variant outperform the dense baseline out of distribution?” tells you when you are done. Don’t organise inside — accumulate, and file as things arise, while your reaction is still the most valuable part.
3. Important questions (Hamming). The few questions that would genuinely change your situation if answered. Not tasks — questions. They sit above projects: one question may spawn several over time and persists as they finish or get shelved. Two short lists, research and life, reviewed monthly: are these still the right questions?

Track 2 — Operations: how you deliver

A question and a project are not the same thing. A question is open-ended and may branch or turn out to be the wrong question. A project is bounded — a deliverable, a deadline, people counting on you. One question can span several projects; a project can draw on several portfolios; either can exist without the other. Keeping them apart stops deadline pressure polluting open-ended inquiry, and stops open-ended inquiry dissolving operational commitments.

4. Project maps (Knuth). A mutable one-pager per piece of finite work — the page you open after a two-week gap. It answers: where was I, what do I believe and what would change my mind, what are my next actions, what is time-sensitive, where is everything. Tasks live here, embedded in the project that gives them meaning. Maximum five active projects, at most three next actions each — fifteen tasks as a ceiling, not a backlog. A project map is not a history (the log is), not a long checkbox list (eighteen unchecked boxes reads as failure), and not a timeline.

   Parking, clarified (1.1). A parked project map is a complete map. Parking changes two things only: the project does not count against the five, and it is read at the monthly review rather than daily. Everything else a map does, it keeps. You may write next actions on a parked map, update its state, note a milestone, note who you are waiting on. A hard-dated milestone on a parked map, or a dated action on it, is still a promise and stays in the commitments register.

   A map you start work on is a map that counts: being in the middle of something is the strongest sign you are moving it yourself. If you find yourself working on a parked map, or picking up work you had set down on it, it is not parked; activate it, parking another if you must.

   On adopting this clarification, read the parked maps once: every stale date on them is dropped, with its entry in the log, or re-dated.

5. Stewardships. Dashboards for perpetual responsibilities — health, finances, household — that never finish. The critical distinction: projects end, stewardships do not. If health and finances occupy project slots you permanently lose two of five to things that cannot complete. They run in the background with periodic commitments and get a scan at the weekly review, without competing for slots.

6. A commitments register. One flat, date-sorted list of everything with a hard external deadline, whichever project or stewardship it came from. This is not a to-do list, and the distinction matters: a to-do is something you decided to do, a commitment is something someone else is counting on. Mixed together, the commitments drown and you break promises you meant to keep.

7. Energy-matched scheduling (Tao, Wolfram). Tag work deep, medium or light and match it to your current cognitive state. Forcing deep work when your brain wants something mechanical is not discipline, it is waste — the alternative to deep work on a low day is usually paralysis, not virtue. The exception: if you never have deep days, that is environmental, and the fix is protecting blocks rather than trying harder.

8. Handing off (1.1). A project map answers: where was I, what do I believe and what would change my mind, what are my next actions, what is time-sensitive, where is everything. It gains one more question: whose move is it?

   A project you have handed to someone else carries their name at the top of its map: held by: the harbour office, held by: a colleague, held by: the contractor who has the hull. The holder is whoever you could write in Waiting On. A map with no name on it is yours; a map that names you is yours. The page stays where it is; only the name changes.

   Why: if a project someone else is moving holds one of your five, the cap counts their attention as yours, and you will either raise the number or stop writing such work down. Both are worse than a name on a page.

   The count. Count the maps that are neither parked nor handed off. A handed-off project is still open: it keeps its map, keeps logging, keeps its dates in the register, and is still read at the weekly review, and at the daily orientation when something has come back. It is not a sixth slot; it is a project that is not a unit of your attention this week.

   The review. Yours: did it move? Handed off: what came back, and what is waiting on your decision? The second is asked in a week when the map changed.

   The log. Handing off and taking back are dated entries in the chronological log naming the project and the holder; taking back strikes the name. Taking back a parked map only strikes the name; to work on it, activate it as well, as its own entry.

   The cap is checked whenever a map that did not count begins to count: activating a map nobody else holds, or taking back an active one.

   Three guards. If you cannot name who has it, it is yours. A handed-off map says what you are waiting for; a name over an empty Waiting On is a parked map wearing a name, and the weekly review parks it or takes it back. And handing off is never the answer to “the cap is full”: doing a thing on a handed-off map does not make it yours, doing most of its work does; at the weekly review, a handed-off map you worked on yourself on two or more days is taken back, or its name changed to who really has it. You do not hand off a map while you are in the middle of its work.

   The asymmetry. Parking is your decision about now, so starting work on a parked map undoes it at once; a holder is a fact about someone else, which one afternoon’s work on the map does not change.

   The map already has a Waiting On section for single items. Handing off is Waiting On lifted to the whole project, which is why the method already half-had it. Its ancestry is GTD’s Waiting For, kept per project rather than as a separate list.

The bridge

The log feeds both tracks: an observation becomes evidence in a portfolio, a realisation that something must be rerun before a deadline becomes a next action on a project map. The weekly review governs both — retrospective and forward scan. Projects reference the portfolios they draw on, and commitments decompose into milestones that surface as next actions at the right time.

The daily orientation is where the tracks meet: check what is urgent, glance at what is important, check your energy, and pick one thing.

Actions, not tasks

The RLM speaks of actions, not “tasks,” on purpose. The default form of an action is a single inline bullet on a project map — not a heavyweight per-item note. You only “promote” an action to its own note when it grows into an investigation spanning multiple days and evidence artefacts. This keeps the friction of capturing the next step near zero. See Actions.

Designed for ADHD working styles

The method is deliberately shaped to be sustainable when executive function is unreliable:

• Leads with what is there, not what is missing — no guilt engine, no red overdue counts.

• Permission to park or drop. Projects park, complete or drop, questions retire, actions and milestones drop, commitments get fulfilled or dropped — all first-class, and none of it is a failure state.

  “Reversible” is worth stating precisely, because it means less than it might sound like. Parking is genuinely two-way: a parked project activates again, and a retired question does too. Dropping is not — there is no un-drop verb for an action, a milestone or a commitment, and none is planned. It is re-decided rather than undone: if a dropped thing turns out to matter, make it again, and the record honestly shows two decisions rather than pretending the first never happened. That is the same reason a drop is logged as a drop and not as a completion.

  Projects are the one named exception. A dropped project keeps its slug, its map and its history, so cdno project activate brings it back, and a project dropped in error can later be completed, or the reverse. Each is still a new decision with its own log line, never an erasure of the first.

  What a drop does preserve is the note. A dropped action or commitment keeps its file, its body and its created date, archived under _done/<year>/ — so the context you wrote survives even though the plan did not. A milestone is only a bullet, with no note behind it, so dropping one leaves just the log entry naming it — including when it had sub-bullets, which is the one place this guarantee does not yet hold (#574).

• Minimal maintenance. If keeping the system running costs more than a few minutes a day outside the weekly review, something is wrong.

• One obvious next step. cdno orient answers “what should I do now?” with a single suggestion, biased to your current energy.

The rhythm

The method runs on a few interlocking loops:

• Daily — orient in the morning, log and act through the day, a light close at the end. See The daily loop.
• Weekly — a short retrospective (wins, challenges, one improvement) and a single goal for next week. See Weekly review.
• Monthly — the parked maps (“is it time?”) and the questions (“still the right questions?”).
• Occasional — file evidence as you find it, triage the inbox, prune questions and projects.

Method version

The version tracks the method’s text, not any tool. A change is minor if every page of an existing logbook can be read under it without being rewritten, moved, or given a line it lacks; a minor version may ask for a one-time read-through of existing pages. A change is major if any page must be rewritten or moved, and it comes with instructions for doing so (in a tool, a migration). A logbook records on its first page, dated, the version it follows and the day it moved to a newer one; the published method keeps a changelog of practices.

Changelog of practices

• 1.0 — the seven practices: the chronological log, evidence portfolios, important questions, project maps, stewardships, the commitments register, and energy-matched scheduling.
• 1.1 — parking clarified (under practice 4), practice 8 (handing off), and the monthly loop in the rhythm. Additive: every 1.0 logbook is a valid 1.1 logbook. On adopting 1.1 a paper user does two things: a dated line on the first page, and one pass over the parked pages’ dates.
• 1.2 — practice 1 gains its one exception: a renamed page’s references are corrected, the old name is kept on the page, and the rename is itself an entry. Additive: every 1.1 logbook is a valid 1.2 logbook. On adopting 1.2 a paper user does one thing: a dated line on the first page; there is nothing to read through.

How it maps to the tool

Read on: Note types.