Micrologcapture first, structure later

Microlog is one timestamped log of anything I care about. I append short entries throughout the day, and separate tools read the same record to build habit views, financial summaries, health histories, and context for models.

I arrived at this design after repeatedly abandoning more structured trackers. Every category, field, and folder added a decision at the moment I had the least attention to spare. Missing one entry then looked identical to nothing happening.

I moved all interpretation out of capture. Writing requires a timestamp and a sentence. Structure is applied later, when I already know what I am trying to retrieve or measure.

I needed an honest record before I needed a productivity system

The first version was a paper to-do list. I used paper because comparing applications had become a way to avoid tracking anything.

The list showed me that the record mattered more than the planning features around it. I wanted to see what I had actually done each day. A tracker that made the day look productive or omitted inconvenient gaps would give me confidence without evidence.

That made adherence part of the design. A perfect schema produces no useful record if I stop filling it in. A lower-friction system with rougher entries gives me something I can inspect and improve.

Paper also revealed details I would not have chosen in advance. Tasks approaching two hours felt too large to begin. I only learned that by running the system and watching where I hesitated. Since then, I have prototyped tracking practices manually before building software around them.

Continuous capture made entry cost the main constraint

Reconstructing a day at night records what I remember, not everything that happened. I needed to write during the day, while working, eating, exercising, spending money, and talking to people.

That changed how I measured friction. A form that takes thirty seconds may sound cheap. If it interrupts another activity and asks me to choose among several categories, the attention cost is much larger than thirty seconds. Repeating that interruption throughout the day eventually creates gaps.

I therefore made the capture command accept raw text:

organs log "Ate chicken, broccoli, and okra at home"
organs log "Gym: bench DB 150x10, dips 3x8"
organs log "Shipped tasks integration"

The command appends each entry to that day's Markdown file:

# 2026-08-30 (Sunday)

## Morning

- [10:06] Ate chicken, broccoli, and okra at home
- [10:24] Shipped tasks integration

There is no required category, project, habit, or metadata form. I can write a fragment and return to what I was doing.

The log is chronological and append-only

I borrowed the entry shape from system logs and bank statements. Each entry has a time and enough local context to make sense later:

2024-03-11 09:14:22  worker.queue  job 8812 retried after timeout
2024-03-11              Blue Bottle coffee                     -6.75

Microlog uses the same basic form for personal events. The normal write path appends a new line instead of editing earlier history. Corrections become additional entries, preserving what I originally recorded and what changed afterward.

Chronology gives every tool a stable input. A new tool can scan the same files without requiring a migration or asking older entries to match its schema. The log remains useful even when I stop using the application that originally captured it.

The scope is deliberately broad. An entry can describe my work, food, exercise, an expense, a conversation, a world event, or a friend's milestone. The common property is simply that I wanted to remember when it happened.

Plain files are the source of truth

I tried keeping the record in Evernote, Notion, Trello, and several databases. Each tool made one part of the experience easier while placing the history behind its own interface or hierarchy.

Those attempts gave me four requirements:

• entries live in a standard format on disk
• capture has no setup beyond writing the entry
• tools can read and write programmatically
• the source stays shallow enough to browse without a custom application

Markdown files satisfy those requirements. They work with editors, search tools, Git, scripts, and models. I can replace the capture interface or analysis tool without moving the historical record.

This led to a toolbox architecture. Microlog owns the append-only record. Other applications consume it through files or a small read/write interface. A habit tracker can disappear without taking the journal with it. A new search tool can index the existing history without importing it into a new authoritative database.

capture ───────┐
voice ─────────┼──→ daily Markdown log ──→ habits
automations ───┘                         ├→ health
                                        ├→ finance
                                        ├→ search
                                        └→ model context

The tools may keep derived indexes or caches. I can delete and rebuild those because the log remains the source.

The old schema made capture do too much work

An earlier daily template required me to sort each event before writing it:

Mission
To-do list
Habits
  Journaling
  Food
  Expenses
  Fasting
  Meditation
  Gym
Highlights
Insights

A meal purchased at a restaurant could belong under Food, Expenses, Habits, or Highlights. The form forced me to choose one section before it would accept the event. Recording therefore required remembering the schema and deciding how the entry would be used later.

That was the wrong moment for classification. At capture time, I only know what just happened. At read time, I know the question I want to answer.

Microlog keeps the meal as one event. A food view extracts what I ate. A finance view extracts the purchase. A habit view marks whether I logged a meal. Several interpretations can coexist because none rewrites the source entry.

Models apply schemas when I ask for a view

Before language models could interpret loose text reliably, structured tracking required a form. The person entering data had to supply the categories that software could not infer.

Models let me move that work to read time. A view defines the schema it needs, reads the relevant entries, and asks a model or deterministic parser to map them into that schema.

For example, a food view can request:

interface MealEvent {
  at: string;
  foods: string[];
  source?: "home" | "restaurant";
}

The health tool applies that shape to entries likely to describe meals. The finance tool uses a different schema over the same time range. The source log does not need to anticipate either one.

I still keep deterministic boundaries where they help. Timestamps come from the capture system. File dates define the initial range. Exact markers such as Gym: can route obvious entries cheaply. The model handles ambiguous language and overlapping categories.

Derived records retain a link to the source line. I can inspect the original text when an interpretation looks wrong and regenerate the view after changing its prompt or schema.

Each use gets its own view

My first digital implementation asked the event stream itself to serve as a habit tracker, model memory, and automated journal. The raw list was too vague for habits, too noisy for model context, and too unstructured for reports.

The mistake was expecting one storage shape to answer every question directly. The log only needs to preserve events. Each consumer needs a narrower view:

These views can improve independently. Changing the food parser does not change finance history. Replacing the model used for context selection does not change the log. Adding a new view requires reading existing entries, not redesigning capture.

Real entries determine the configuration

I could not design every useful schema before using the system. Real entries exposed ambiguous cases that a design session would miss: one sentence describing both a purchase and a meal, a workout abbreviated in personal shorthand, or a work event whose importance only became clear days later.

I let those cases shape each view. I start with a small schema, run it against the actual log, inspect errors, and add rules or examples in response. The raw entry remains available throughout that process.

This is another reason capture stays loose. Early classification would freeze my first guess into the historical record. Read-time interpretation lets the configuration evolve as I learn what I want from the data.

Microlog keeps capture simple and moves complexity downstream

The finished system has a clear division. Capture records a timestamp and text. Daily Markdown files preserve the history. Narrow tools interpret that history for a particular purpose. Models handle the parts of classification that require judgment.

I no longer choose between Food and Expenses while standing in a kitchen. I write what happened once. Later, when I want a meal history or spending report, the relevant tool performs that interpretation against the same entry.

That decision solved the adherence problem that had broken my earlier trackers. The log asks almost nothing when my attention is scarce, and every later feature pays its complexity after the event has already been captured.