LifeLab · topics · worked cases
The question only looks hard because we're asking it at the wrong moment. At the moment of writing there is no information to decide on: the first 1:1 is a thing that happened on a Tuesday. Whether it's a recurring topic is a fact about the future, and no amount of UI can extract it from a user who doesn't know yet.
So the honest answer is temporal. It starts as a block. It stays a block until a pattern exists. Then the system — which can see the pattern and the user can't — offers promotion, and the earlier occurrences come along. Companion to Lens as Block State; this document is the pressure test.
reading A · a block with tags
Costs nothing, reads naturally, and the date is real information — this meeting happened on this day and won't happen again.
Fails at: “what did we discuss last time?” You can compose :sam: :1on1: to gather them, but there's nowhere to put a standing agenda, and nothing carries between occurrences.
reading B · a page
Standing agenda has a home; history is in one place. This is what people actually want by meeting five.
Fails at: the journal. Nothing on 2026-08-01 records that you spent an hour with Sam — your day is missing from your day. And it demands a decision the first time, when you can't make it.
reading C · a summon on the journal
facenew lines land on sam 1:1
You write on the journal page and the words land on the topic. The day records that the meeting happened; the topic accumulates what was said.
Works — but only once B exists. Reading C is not an alternative to B, it's how you use B from a journal. The first-occurrence problem is untouched.
the actual finding
A and B aren't rival encodings of one thing — they're two different facts. “I met Sam on Aug 1” belongs to the day. “What Sam and I are working through” belongs to the relationship. Any design that forces a choice will lose one of them, which is why every notebook app makes this awkward. C is the only reading that stores both, and the entire remaining question is how you get to C without asking the user to predict recurrence.
A block. No offer, no prompt, no page. You met someone once.
Still a block. The ⇥ offer does not fire — there's no page called that, and creating one is not something to suggest on a coincidence of two.
Third occurrence. Same headline, three journal pages, regular spacing. Now there is evidence, and the system says so — once, dismissibly, in the gutter.
Page created. All three occurrences become summons in place — the journal entries stay where they are, now showing the topic's face. Nothing moved; three blocks gained a binding.
This is only possible because promote-in-place doesn't move anything. The retroactive part — three old blocks becoming windows onto a page that didn't exist when they were written — is a straight consequence of the block/page split. Their content stays homed where it was written; the topic gathers it.
Why three and not two: two is a coincidence, three is a habit. Getting this threshold wrong in either direction is fatal — too eager and it's a nag bar, too lazy and the feature never fires. It should also count tags, not just headlines: three blocks marked :sam: with similar text is the same evidence.
tension 1 · you already know
Occurrence one, full certainty. Waiting for three is now the system being stupid on purpose. So the manual path must stay open and equally cheap — ⇥ on a line that matches nothing creates the topic immediately, exactly as designed. The threshold is a suggestion engine, never a gate.
tension 2 · the same words, different things
Headline matching will absolutely fire on things that aren't recurrences. Accepting merges unrelated notes into one topic — a destructive-feeling outcome from a passive suggestion, which is the worst possible pairing. Mitigation: the offer must show what it will gather before you accept, and accepting must be one undo away.
tension 3 · the tag/page collision, arriving by the back door
:sam:Promotion creates a page named sam 1:1 while :sam: exists as a tag. The earlier doc says refuse name collisions — but here the system itself is walking into a near-collision. It probably has to offer to home the existing tag instead of making a second name: “:sam: has 14 blocks — give it a home?” Which is a nicer feature and a much bigger one.
tension 4 · what the journal keeps
After promotion the journal block is a summon, so its own content slot is empty and the face belongs to the topic. If a user then writes a private aside there, it's homed on the day, not the topic — correct, but invisible unless the two regions stay visually distinct. This is the three-region design doing real work; without it, promotion silently changes where your typing lands.
the general rule these cases imply
| if the thing… | encode as | because |
|---|---|---|
| happened once | block, tagged | the date is the point; nothing to accumulate |
| recurs, no continuity | block + tag, composed on demand | gathering is enough — a standup log needs no standing agenda |
| recurs with continuity | homed topic, summoned per occurrence | something carries between instances: agenda, thread, obligation |
| is referred to before it exists | homed topic immediately | you needed the name in order to point at it |
“Continuity” is the discriminator, not recurrence. Workouts recur and need no page — nothing carries from one run to the next, the tag gathers them, done. A 1:1 recurs and carries an agenda, a thread, unfinished business. That's a distinction the user feels immediately and can articulate, which makes it a much better rule than anything about topic-ness or aboutness.
What I'd still push on before draft 3: whether a passive suggestion is even the right mechanism, given tension 2 — a wrong accept merges notes, and passive UI that occasionally causes destructive merges trains people to ignore it. The safer variant is that the system never offers, but promotion always gathers retroactively when you do it by hand: you promote when you notice, and the past comes with you. Slower, but it can't misfire, and it needs no threshold at all.