Timeline labels are navigation, not summaries.

A few days ago I opened the timeline panel in a Creator Notes workspace I had been writing into with the CLI for a week. It showed me fourteen rows in a column, each one labeled No description, with the lightbulb icon as the only signal that an idea lived behind it.

The timeline is supposed to be the surface where I can scan my recent thinking and decide what to reopen. It had become a list of file IDs.

The obvious fix is “wire up an AI summary so every row has something on it.” I think the obvious fix is wrong, and I want to explain why.

When you see a blank label on a row, your brain reaches for a summary. “This note is about X.” You can picture the model output. It feels like progress.

Spend a minute imagining what those summaries would actually say in a real timeline. “Notes about pricing.” “This note discusses the timeline panel.” “Ideas around AI summaries.” Each one is accurate. Each one is useless. A summary tells you the topic. The timeline user is not asking about the topic.

When you open the timeline, you are running a fast triage loop in your head:

1. 1. What happened here?
2. 2. Do I care enough to open it?

A topic summary answers question 1 weakly and question 2 not at all. Knowing the topic does not tell you what shifted, and it does not make you want to click.

Compare:

Notes about pricing.

with:

Opened pricing question: charge for agents or shared workspace value?

The second one tells you a thing happened (a question got framed), it tells you the specific shape of that thing (the option set is binary), and it creates a small pull to reopen. It is not longer. It does more.

The timeline label is not a summary. It is a scan-first headline for a thinking event.

Once you stop trying to summarize and start trying to write a headline, you have a very good reference point. The git commit message.

Git's whole shape is this. A commit has a subject line and a body. Tools like git log --oneline, GitHub's commit list, git shortlog: they all show only the subject. The body is there when you need it. The subject does the navigation.

And the part of git's design that took me a long time to appreciate. It is all one field.

Reframe descriptions as scan-first headlines

Timeline labels were reading like content summaries, which made
scanning impossible. Treat them as navigation aids instead, with
the deeper explanation expandable on click.

That is one text blob. The first line up to a blank line is the subject. Everything after is the body. There is no subject column and no body column. Just a convention about newlines, and a render layer that knows what to do with it.

This matters when you are designing the Creator Notes equivalent. The instinct is to add a timelineHeadline field and a timelineDetail field. Two columns, two prompts, more migration, more storage. The git model says: do not. One field. The render layer splits on the blank line. The side panel shows the headline. Click to expand reveals the body. When a human writes a one-line description without a body, it still works because the headline is the whole thing.

The other thing I keep seeing flattened: people lump “AI summary for a new note” and “AI summary for a version edit” into the same problem. They are not the same problem. They need different prompts.

For a new note, the label answers what new thing entered the workspace. There is no prior version to diff against. The generator works from content, type, and source.

Opened question: how timeline labels stay meaningful at scale

For a new version, the label answers what materially shifted. The generator works from a diff plus the current content.

Reframed descriptions as scan-first change labels, not summaries

A “summary” framing handles neither well. A “headline” framing handles both, but with different prompts under the hood.

Most of the bad descriptions you have ever seen on a timeline share one thing. They waste the first word. “Created a note that…” “This note discusses…” “Updated information about…” The side panel is narrow. Text truncates. The first word is the most valuable real estate on the row, and dead phrases burn it before any signal arrives.

The formula is simple:

[Meaningful verb] + [specific object] + [important twist]

Examples:

• Opened pricing question: charge for agents or shared workspace value?
• Reframed descriptions as scan-first change labels, not summaries
• Extracted three risks in batch AI note creation
• Challenged generic AI summaries as too vague for scanning

The verb should tell you what kind of intellectual event occurred. Captured, Opened, Framed, Proposed, Clarified, Challenged, Narrowed, Connected. For agentic work: Extracted, Synthesized, Split, Linked, Converted, Flagged. The worst verb is “Created” because every event is a creation. It carries zero signal.

Before any generated label goes into the database, it should pass five tests:

1. Distinguishable. Could the same line apply to five other notes? If yes, too generic.
2. Reopenable. Can the reader tell why they might click it later?
3. Specific. Does it preserve the actual concept, tension, decision, or question?
4. Honest. If the note is exploratory, say “Explored,” not “Defined.”
5. Front-loaded. Would the line still be useful if the right side got truncated at 40 characters?

There is a tempting design where the platform asks every CLI client, every MCP agent, every chat-funnel write to pass a creationIntent hint. The platform then uses that hint to inform the final headline. It feels collaborative.

We are not doing it. Description generation is platform-owned, full stop.

The reason is product consistency. If every external agent invents its own commit-message dialect, the timeline reads inconsistently. Some rows verb-led, some passive, some literal file-event language. The reader's eye cannot settle into a rhythm, and the surface that promised to make thinking-history scannable goes back to being noise.

By owning the label, we get one place to change the style as we learn what works, one voice across human writes and AI writes and CLI writes and inbound writes, and a real product promise that every timeline row reads well, no exceptions. The token cost per write is the price of that promise. We are happy to pay it.

Even if every row reads beautifully, there is a row-count problem we have not solved. An agent run that creates 17 notes in one turn produces 17 timeline rows back-to-back. The rows are individually well-labeled, but the timeline visually drowns in agent output and loses the human-thinking signal it was supposed to preserve.

The shape of the fix is clear. When several notes come from a single operation, the timeline should show one rollup row that expands. “AI extracted 12 notes and 4 open questions from the positioning brainstorm.” Click to see the children.

We are not shipping that in the first pass. The headline-quality fix is higher leverage. Without it, no amount of row grouping rescues a wall of unreadable labels. With it, the row-count problem becomes a separable, less urgent next move.

I would rather call that out than pretend the design is complete.

The timeline should let a human replay the evolution of thought without reopening every artifact.

That is the bar. A row that reads No description fails. A row that reads This note discusses pricing fails. A row that reads Opened pricing question: charge for agents or shared workspace value passes.

Every timeline row is a navigation aid. Treat it as one.