How Long Should I Keep Revising a Note?

When organizing notes, I mostly worried about where to put them. Once the folders were reasonably settled, another question remained.

“How long should I keep revising this note?”

If I keep refining every note, the record of what happened at the time disappears. If I leave every note untouched after writing it once, new facts and ideas scatter into separate files. Creation and modification dates remain, but dates alone do not tell me what to do next.

So I tried placing notes on a time axis. What mattered was not when a note was created, but when my attention returns to it and when that attention closes.

• Bullet Journal places notes along a time axis. To revisit another note, I move backward through that axis and depend on index pages.
• PARA moves expired projects and areas that no longer hold my attention into an Archive folder. Space bends as time changes.
• ACE separates time and space. It felt similar to my design. In my version, though, the Atlas side spans atlas/, notes/, and sources/, while the Calendar side maps to log/.

All three methods can lead to changes in action across areas of life. I see value in that, but it is slightly different from the question I am trying to answer here.

A creation date cannot explain a note’s time

A file has a creation date. Obsidian can store dates as properties, and the file system records the last modification time. At first, I thought that was enough to explain the time of a note.

But two notes created on the same day can live very differently.

Meeting minutes become a record of that day when the meeting ends. A thought captured in the inbox may be reviewed for several days before becoming another note or disappearing. A principle or concept I continue to use may be revised years later when I find new evidence.

Although all three can share a creation date, attention returns to them in different ways. The time of a note is ultimately closer to an interval of independent attention and revision than to a single date.

I continue with where the actual file should live after deciding its temporal shape in the spatial-axis post.

Points, line segments, and rays

Points, line segments, and rays are not mathematical models for measuring time precisely. Nor are they a classification system that forces notes into folders. They are operating metaphors for comparing the shape of returning attention.

A point ({t₀}) is a note whose writing and completion happen within one interval of attention, with no separate round of revision afterward. Meeting minutes, logs of judgments made at the time, and preserved external sources are close to points.

A point does not mean that writing took zero time. I might revise minutes throughout a four-hour meeting. If that one interval—the meeting and its immediate cleanup—closes and I do not revise the note again, it is still a point. Conversely, even a short document is closer to a line segment if I reopen it days later, revise it, and then finish it.

A line segment ([t₀, t₁]) is a note that receives attention and revisions at distinct times but has an end condition. A research draft awaiting judgment and a project MOC with a completion point are close to line segments.

The right endpoint matters most. I review an inbox capture before its deadline, then create a new canonical note or delete the capture. A project MOC does not automatically become state: archived merely because the project ended. I keep it frozen only if it is no longer revised but remains useful for exploring or reviewing an area of interest. If it has no exploratory value, I clean up its references and delete it.

A ray ([t₀, ∞)) has a beginning but no predetermined end. Principles I continue to use, concepts, and MOCs for ongoing interests are close to rays. In my vault, notes/ usually serves this role.

A ray does not mean daily editing. I may leave it untouched for months. But when I encounter a new insight, a counterexample, or a changed fact, I can reopen and revise the same note. I have not closed off the possibility that attention will return.

The time axis is not a folder classification

Notes on the same topic can have different temporal shapes.

The minutes from a security meeting in a project are a point. A security checklist used while the project is active may be a segment. Security principles that I keep refining across several projects are closer to a ray.

Saving another note type such as meeting, security, or concept does not solve this problem. A type says what a note is about, but not when to close and reopen my attention.

I decided not to attach a separate lifecycle property to every note. Folder structure can imply a temporal shape, but I do not force points, segments, and rays into folders or properties. created is the day a note was made, and file.mtime is only its latest modification time; neither preserves the full history of returning attention. This distinction is not a precise edit log. It is a model for deciding how I will treat the note next.

What happens when there is no right endpoint

The time model changed my inbox and logs most clearly.

I used to leave inbox notes around because they might become useful someday. But a segment needs an end. If review turns a capture into an idea I want to develop, I create a new note under notes/. If it is external material, I make a new capture under sources/. I keep the original inbox capture when it has independent value; otherwise I delete it after checking its references.

Logs are the opposite. There comes a point when I need to stop refining them to match my current thinking. If I rewrite the basis of a past decision using today’s standards, I can no longer understand why I made it. Even a record of a poor judgment is meaningful when it preserves the state from that time. Original material stays under sources/, the event context under log/, and only the reusable interpretation continues to evolve in a separate notes/ file.

A ray carries a different responsibility. If I call a note alive but create a new file for every new piece of evidence, I end up with several canonical versions. For a principle I expect to keep referencing, I should return to the existing note, revise the wording, add counterexamples, and remove what no longer holds.

In short: preserve points, finish segments, and rewrite rays.

Designing the time of a note means designing when to stop

When I hear “the time axis of notes,” I first think of creation dates, modification dates, and daily notes. I did too. In practice, what made organization difficult was not a lack of dates, but a lack of criteria for stopping.

Should this remain a record of that moment? Should it be processed by a set time? Should I keep revising it whenever new evidence appears?

Answering those three questions reveals the next action without attaching complex states to every note. I stop treating a note that preserves the past in the same way as one intended to grow.

This distinction will probably change as I use it. For now, though, I think first about when attention returns and when it closes, not when the note was created. I continue with when a frozen MOC should remain or be deleted in the post about wikilinks and MOCs, and with the practical rules for separating original material, records, and thoughts I will keep revising in the post about sources, logs, and wikilinks. The time axis is less a way to organize dates than a way to think about the end of a note.