There's a moment in every knowledge tool where you're asked to make a decision you're not ready to make.

Notion asks you to design a database schema before you've captured a single note. Your project tracker asks you to define phases and milestones before you've had the first real conversation. Your CRM asks you to categorize a relationship before you know what it is. These tools all share an assumption so deep it's invisible: that structure comes first, and information gets poured into it.

We built Earmark on the opposite assumption. We call it the decide-late principle: capture everything now, structure nothing until the moment you actually need it.

The cost of deciding early

Every early decision is a bet that the future looks like the present. The database schema you design in week one encodes what you thought the project was in week one. The folder hierarchy reflects the org chart from before the reorg. The "project status doc" describes a project that has since become a different project.

And here's the thing about early structure: it doesn't just go stale, it actively resists correction. Once a schema exists, information gets contorted to fit it. Once a status doc exists, someone has to maintain it - which means reconciling every new development against an old summary, forever. The document becomes a second job. Most teams quietly stop doing that job, and the doc becomes the most confidently wrong artifact in the workspace.

The traditional answer was to try harder: better templates, stricter update rituals, a designated doc owner. But the problem was never discipline. The problem is that the structure was decided before the information existed.

What deciding late looks like

Take something concrete: meeting notes and project status.

The tempting design - the Notion-shaped design - is a canonical status doc that each meeting updates. Every meeting ends with someone editing the living document, merging new reality into old summary.

The decide-late design treats each meeting as an immutable snapshot in the project's timeline. Nobody edits it. Nobody reconciles it. It's simply what was true, and said, at that moment.

Then "current status" stops being a file and becomes a query. When you ask where the project stands, the answer is synthesized on demand from the sequence of snapshots - always fresh, never manually maintained, never stale by construction. The structure (a status summary) is created at the moment of need, from the full record, and then it can be thrown away, because you can always ask again.

This inversion - records are immutable, views are computed - is old news in software engineering. Event sourcing, append-only logs, materialized views: infrastructure people have known for decades that deriving state from an immutable history beats mutating state in place. What's new is that the "view" no longer has to be a rigid aggregation someone programmed in advance. An agent can synthesize the view you need, phrased the way you need it, at the moment you ask. AI is what finally makes decide-late practical for messy human information, not just database rows.

The industry is already living this way

This isn't just a data-modeling preference. It's how work itself is shifting.

A product lead at OpenAI recently described how planning has changed inside the company: nothing gets planned more than a month or so out, because the ground moves too fast for longer horizons to mean anything. That sounds like chaos until you notice it's the same principle. A twelve-month roadmap is a status doc for the future - an early decision that must be endlessly reconciled against a reality that refuses to cooperate. Teams that plan late aren't failing to plan; they're refusing to pay the reconciliation tax.

Honestly, the year-plan was absurd before AI, too. We just tolerated it because the tooling gave us no alternative - deciding early was the only way to coordinate. When your tools can synthesize a current picture on demand, the long-range plan loses its main job. You keep the direction; you drop the pretense that you know the route.

Deciding late is not deciding never

The objection writes itself: isn't this just an excuse for having no structure and no plan?

No - and the distinction matters. Decide-late doesn't eliminate decisions; it moves them to the point of maximum information. You still make the schema, the summary, the plan. You just make it when you need it, informed by everything that's happened, instead of guessing up front and defending the guess. Deciding early feels responsible, but it's mostly a way of feeling in control. Deciding late is what taking the information seriously actually looks like.

The prerequisite is trust in your capture. You can only defer structure if you're confident the raw record is complete and durable. That's the trade Earmark makes: we're strict about capture - every meeting, immutable, in sequence - precisely so we can be relaxed about everything downstream. Rigid record, fluid structure.