Build your first repeatable routine

Put the brief, the evidence and the exception path in one place.

We have enough pieces now to build something that can survive more than one good attempt.

Choose the task you started with on Day 1. It doesn't have to become an elaborate system. A repeatable routine can be a page you open when a familiar need appears.

I'll assemble our source-checking example below. This is a proposed, simplified routine for your own reading notes, informed by our actual source-checking work. It isn't a report of a new live run or a universal procedure for every website.

Start with a bounded question

Trigger: You are about to reuse a reading note whose supporting source may have changed.

Result: A short record explaining whether the inspected material still supports the note, with any unresolved question left visible.

Inputs: The reading note, its source and the saved passage or version used when the note was written.

Already, we have narrowed the work. We aren't researching the entire subject again. We are checking the support for a particular note.

Run the ordinary path

First, read the claim in the note and locate the material that supports it. This prevents a general page summary from replacing the actual comparison.

Next, inspect the current material beside the saved version. Record the version or date when available. If a number depends on a table, preserve the heading and condition that give it meaning.

Then describe the difference in ordinary language. A sentence added about a study's population may narrow where its result applies. A navigation change may have no bearing on the note. Ask whether the meaning relevant to your claim changed.

If AI helps, give it the exact comparison material and a focused request:

Compare these passages for changes that affect this reading note. Identify the supporting text for each proposed change. If the supplied material is insufficient, name what is missing.

Inspect the proposed answer against the material. A quoted sentence needs to be present; an interpretation needs to follow from it. Approve only the revision you can support.

Give the exception a destination

If the current source won't open, record that it couldn't be checked. Keep the last verified material and name the access problem. Don't write “unchanged.”

If the saved version is missing, you may be able to inspect whether the current source supports the note, but you cannot claim to have compared it with the absent version. Record the narrower check you actually performed.

If an essential table is unreadable, stop the numerical conclusion and recover that part in a usable form. The rest of the work can remain available.

In our actual procedure, a failed capture and a wrong source reference had explicit recovery paths. We also kept a successful comparison separate from any decision to change lasting guidance. Those boundaries made the result easier to interpret.

Leave a useful return

A completed example record could contain:

Note checked: [the claim]. Material inspected: [source and version]. Finding: [supported, revision proposed or unresolved], with the relevant passage. Decision: [what you chose]. Next action: [only what remains].

The brackets are fields to fill, not permission to invent missing facts. If your result is unresolved, explain the missing input and its effect on the conclusion.

Before treating this as a routine, walk through one ordinary case and one exception. Day 19 gave you the method: define the expected behavior, follow the instructions and record where they fail. Keep the difficult case for the next revision.

We've now moved from a useful question to a draft, from a draft to a handoff, and from a handoff to a routine with a stopping point. The next week asks whether that routine deserves a place in your life. We'll count its continuing work, compare it fairly and make room for the answer to be “change it.”