I wanted to search my work notes. I ended up building instruments out of them.

For years I wrote work notes in plain files, one dated entry at a time, with the ticket reference in the line. A typical stretch looked like the sample below. I never planned to do anything with them beyond finding a sentence again, and that was the whole reason I wanted search.

22/09/2026
Chased TICK-1842 with @dana. Tunnel into prod still dropping.
INC-9 again after the deploy, third time this month.

24/09/2026
addresses: INC-9
Rolled the retry config back. Left TICK-1842 open until it holds.

Search was only the first thing the notes could do.

Once the entries were searchable, I noticed that I was asking the same question over and over: what happened to this ticket? A reference like INC-9 appears in many entries across many weeks, and listing them in date order is a timeline I had already written without meaning to. Nothing had to be tagged for that, because the reference sat in the sentence the whole time.

The second thing was recurrence. Counting how many days a ticket appears in a month shows an issue coming back, and the dates show whether the gaps are getting shorter. The third was the project summary I owed someone every quarter. A claim such as "this failed six times since June" is easy to write and hard to defend, unless the six entries are one click away from the sentence.

Those three uses are what I mean by instruments. Each one is a question over entries you already wrote, it returns a figure, and the figure opens onto the entries it was counted from. If a number cannot show you its entries, you have no way to tell it from a guess, so I did not want any number on the page that could not open.

A link you write is not a coincidence.

The first trap was relations. Two entries that mention INC-9 sit next to each other in a timeline, and it is tempting to read that as one leading to the other. A shared ticket says that both entries concern the same ticket and nothing more. The same applies to two entries written on the same day, or two that happen to use similar wording.

So there are two separate things, and the app keeps them in separate lists. A relation exists only where you wrote a line for it: addresses: INC-9, reverses: BTX-12, or follows: BTX-4. Deleting the line deletes the relation, since the line is the relation. Entries that merely appear together are listed under their own heading, labelled as not a cause, and nothing promotes one list into the other.

This costs you something. A relation you never wrote does not exist, so a project where nobody wrote follows: has a timeline and no relations. I prefer an empty list to a confident wrong one, though I accept it makes the result look thinner at first.

A repeated line can become a property, after a check.

I also noticed that I kept starting lines with the same words. A line such as root cause: stale cache entry appeared in entry after entry, and I had never declared a field called root cause. It had arrived through habit.

blk/txt notices this and offers the prefix back as a property you can preview, once it shows up in at least five entries. Before it offers anything, it looks for counterexamples. If the same words turn up in many more entries without the colon shape, they are ordinary vocabulary and not something you record, so the proposal is dropped. It never adds the property by itself, and a proposal you refuse does not come back. It reads only the text, with no language model involved, so you can run the same check yourself.

Nothing written is not the same as did not happen.

A ticket with no mentions for twenty days looks resolved. If nothing at all was written on twelve of those days, the gap says very little about the ticket. The app therefore counts the days with at least one entry you wrote and reports the others as "nothing written", separately from "not mentioned". Entries posted by agents and log rollups do not count as writing, since they do not show that you were keeping the notebook that day.

Links and corrections travel with the export.

Anything built over your notes is only worth trusting if it survives leaving. When you export, a manual link becomes a line such as see: 2026-09-22 3f9a1c2b7d4e, which names the target by its date and a short hash of its text. Corrections you made to what the app read, such as a confirmed label on a metric or a dismissed loose end, go into a comment at the end of the file that a viewer does not show. An import reads both and re-attaches them.

The match is by text and not by position, so a link whose target you later edited is reported as unmatched and left alone instead of being attached to a nearby entry. Locked entries contribute no anchor at all, because a hash would let someone holding the export confirm a guess at the hidden text. For the summary I owed, you can also pick the entries behind it and export them as one file that opens without an account.

What this does not do.

Everything above depends on what you wrote. An entry that says "the usual problem came back" has no reference to build a timeline from, and no instrument can recover one. The habit that makes this work is naming things in ordinary sentences, which is the subject of the first article below. I would rather say so here than let the instruments suggest that the notes hold more than they do.