LifeOS: A MANUAL

How I run four careers and a family out of a folder of text files — and how you can build the same thing.

Luis Alt · July 2026

Before anything else

I am not an organised person.

I say that at the start because most systems like this one are written by people who are, and the advice doesn’t transfer. I have always been good at designing structures and bad at inhabiting them. Twenty years of abandoned Moleskines, three false starts in Notion, a Trello board I haven’t opened since 2019. If a system requires discipline to survive, I will kill it. That is a constraint, not a confession, and it shaped every decision in what follows.

So this is not a manual about becoming organised. It’s a manual about building something that keeps working while you are disorganised. Those are different problems and only the second one is solvable.

What I run now is a folder of plain Markdown files — no app lock-in, no database, no subscription — that holds four parallel careers (a consultancy, a decision-making product, a board track, a personal brand) and a family life, and asks perhaps ten minutes of maintenance a week. I call it LifeOS. It is deliberately, almost aggressively simple. The simplicity is the engineering.

Part 1 — Why the usual thing fails

The filing question has no answer

Every tool that organises by place — folders, notebooks, Notion pages nested in pages — asks you the same question the moment you capture something: where does this go?

It looks like an innocent question. It isn’t. It is asking you to predict the future. You’re filing a note about a meeting with a client; is that note about the client, the project, the decision that came out of it, or the person you met? It’s about all four. Whichever folder you choose, you are wrong three ways, and you’ll only discover which way in six months when you go looking for it under one of the other three.

Worse, the answer changes. A note that belonged to “prospect” now belongs to “client”. A draft that lived in “in progress” is now “published”. Every state change becomes a filing chore, and filing chores are exactly what a disorganised person will not do. So the state stops being true. And a system whose state isn’t true is worse than no system, because you trust it and it lies to you.

The maintenance tax

The second failure is subtler. Systems tend to demand maintenance in proportion to their sophistication. You build a beautiful relational database with eight linked tables, and then discover that keeping it accurate is a part-time job. The system starts as a tool and becomes a client.

I have done this to myself more than once. The tell is when you find yourself working on the system on a Sunday instead of working with it. Any structure that isn’t paying for its own upkeep should be deleted, not refined.

The thing that changed

There is a third reason, and it’s new. For twenty years, the format your notes were stored in didn’t much matter — you were the only reader. That is no longer true. I now have a machine that can read my entire body of work, reason across it, and write into it. That machine reads plain text natively and reads proprietary formats badly or not at all.

Which means the format of your notes is now a strategic decision. Store your thinking in a database owned by someone else and you have a pretty archive. Store it in Markdown in a folder on your disk and you have a thinking partner that has read everything you’ve ever written.

That is the single largest change in personal knowledge work in my lifetime, and almost nobody has adjusted for it.

Part 2 — The five principles

Everything else in this manual follows from these. If you understand the five, you can rebuild the system from scratch without my templates.

1. Folders describe what a thing is. Properties describe everything else.

This is the whole system. Read it twice.

A folder tells you the nature of a note: is it something I consumed, something that happened, something I made, someone I know? Nature doesn’t change. A book you read is a book you read, forever.

Everything mutable — which project it belongs to, which area of life it sits in, whether it’s finished — lives in properties: a small block of metadata at the top of the file. That block is called frontmatter, and it looks like this:

---
type: task
status: active
priority: high
deadline: 2026-07-20
area: "[[work.sales]]"
related_project: "[[Acme Redesign]]"
---

The consequence is the important part: a note never moves because its state changed. You don’t drag a file from “Doing” to “Done”. You change one word. The file stays exactly where it was, and every view that cares about it updates itself.

That single decision eliminates the filing question and the maintenance tax at once. It’s the reason the system survives me.

2. Capture must cost nothing. Structure is applied later.

There is a moment, in a meeting or a shower or a car, where a thought arrives. The amount of friction you can tolerate at that moment is roughly zero. Any system that asks you to choose a folder, pick a template, and fill in six fields at the moment of capture will lose the thought.

So the system has an escape hatch: an inbox with no rules at all. No template, no metadata, no naming convention. Write the thing and move on.

The price of the escape hatch is that you must empty it. Once a week, twenty minutes, the inbox goes to zero — everything is either filed properly, promoted into something bigger, or deleted. Most of it gets deleted, and that’s the point. An inbox you never empty becomes a graveyard, and a graveyard teaches you not to trust the system.

3. Think in entities, not documents.

Most note systems are piles of documents. This one has a spine.

Four kinds of thing get to be an entity — a hub note that exists to be pointed at:

• People you’ll deal with more than once
• Institutions — companies, clients, schools, teams
• Projects — initiatives with a beginning and an end
• Areas — the standing domains of your life that never finish

Entity notes are deliberately thin. A person note is three lines. Its value doesn’t come from what’s in it; it comes from what points at it. Every meeting note that links [[Ana Silva]], every task, every decision — they all accumulate as backlinks on her page. After a year, you open Ana’s note and see the entire history of your relationship, assembled automatically, without you having maintained a single “relationship log”.

This is the part that makes it feel like a second brain rather than a filing cabinet. You never wrote that history. It wrote itself, as a side effect of you working normally.

The discipline it requires is small but real: link people, companies and projects by name whenever they appear. Type [[Ana Silva]] instead of “Ana”. That’s it. That one habit is the engine.

4. One vocabulary for state, across everything.

A task can be active. So can a book you’re reading, an article you’re drafting, a project, a sales opportunity. Most systems invent a different vocabulary for each: to-do/doing/done for tasks, to-read/reading/read for books, draft/review/published for writing.

Resist this. Use five words, everywhere:

One vocabulary means one dropdown, one mental model, and — critically — one query. “Show me everything that is waiting” returns your stalled proposal, your unanswered email, and the book you put down in March. That cross-cutting view is impossible if each type speaks its own dialect.

waiting earns its place. Most systems only distinguish “doing” from “done” and so quietly accumulate a pile of things that are neither. Naming the state is what lets you see the pile.

5. Plain text, because your notes should outlive the tool.

I have lost work to three dead apps. The files in this system are Markdown — text with a bit of punctuation — sitting in an ordinary folder, readable by any editor written in the last forty years and any that will be written in the next forty. Obsidian is how I look at them; it is not where they live. If Obsidian disappears tomorrow, I lose a viewer, not an archive.

And, per the earlier point: plain text is what makes the system legible to a machine. That is no longer a nice-to-have.

Part 3 — The architecture

Seven folders. That’s the entire structure.

When you hesitate, two tests resolve almost every case:

• Did I make it, or did I meet it? Made it → 05_content. Met it, did it, decided it → 04_log.
• Will I link to this from other notes for years? Yes → it’s an entity → 03_entities.

The frontmatter contract

Four fields do the real work. Everything else is optional.

type — what kind of note this is (task, log, source, content, entity, quote). Never leave it blank. A note with no type is invisible to every view in the system. It exists on disk and nowhere else. This is the single most damaging thing you can do, and I’ll come back to it.

status — one of the five words. Lowercase, single value.

area — which domain of your life this belongs to. Mine are namespaced with dots so they group naturally: lw.innovation, lw.bizdev, lw.strategy for my consultancy, luisAlt for my own brand, and bare words for personal life. Yours will differ. The convention matters more than the names: pick a small, closed set and don’t grow it casually.

related_project — a link to the project hub, if there is one.

Get those four right and the system runs itself. Get them wrong and notes go missing — not deleted, just unfindable, which amounts to the same thing.

Views replace folders

Here is where it pays off. Because state lives in properties, you can ask the vault questions instead of browsing it:

• Every task that is active or waiting, sorted by deadline
• Every project in the innovation area, with its next action
• Everything I touched for this client, whatever type it is
• Every decision whose review date has passed

In Obsidian these saved queries are called Bases; other tools call them views or dataviews. The name doesn’t matter. What matters is that the folder is no longer how you find things. You barely look at the file tree. You look at views.

Which leads to the last piece.

The front door

Build a Home note. Make it the first thing you see. Put four views on it:

1. Do now — open tasks
2. Projects running — active projects
3. In flight — what you’re making
4. Inbox — how far from zero you are

You open the vault into a cockpit, not a filing cabinet. This sounds cosmetic. It isn’t. I ran without a Home note for two months and nearly abandoned the whole thing, because a file tree is a terrible place to decide what to do today. The day I added it, the system became usable.

A worked example

Say I meet a prospect at a hospital group. One meeting, and here’s how it lands:

1. 04_log/Meeting — Oswaldo Cruz.md — an event, with people: [[Andrea de Souza]], institutions: [[Oswaldo Cruz]], area: [[lw.bizdev]], status: done. The notes from the room go in the body.
2. 04_log/Draft Oswaldo Cruz Proposal.md — a task, status: active, deadline next Friday.
3. 03_entities/people/Andrea de Souza.md — a person, created in ten seconds, three lines long.
4. 03_entities/institutions/Oswaldo Cruz.md — an institution, same.

Four notes, maybe four minutes. And now: Andrea’s page shows the meeting and the pending proposal without my ever having written that down. The hospital’s page shows the same. My task view shows the deadline. My lw.bizdev area shows the opportunity alongside the others.

Nothing was filed twice. Nothing needs updating when the proposal is sent — I change one word from active to done and four views correct themselves.

That’s the entire promise of the system, in one meeting.

Part 4 — How to build it (about an hour)

There is a starter kit alongside this manual: the folder skeleton, every template, the saved views, and a Home page. Unzip it, open it in Obsidian, and you have the skeleton running in five minutes. What follows is what to do with the other fifty-five.

1. Name your areas. (20 minutes — do this properly.)

This is the only real thinking in the setup, and it’s the part that makes the vault yours. What are the standing domains of your life? Not projects — domains. Things that never finish. Mine are five: my consultancy, my decision-making product, my board track, my personal brand, my family.

Write them down. Keep it under eight. Then create one note per area in 03_entities/areas/. If you’re inventing a ninth, you’re probably describing a project.

The dotted convention (work.sales, work.delivery, home) is worth stealing; it lets you slice by work.* as a group or by one sub-area precisely.

2. Seed the entities you already know. (15 minutes.)

Don’t try to be complete. Create notes for the ten people and five organisations you deal with most. Three lines each. The rest will appear as you work.

3. Import nothing. (0 minutes, and this is the hard one.)

Do not migrate your old system. I’ll say why in a moment; for now, trust me: start empty. Your old notes are still on disk, still searchable, still there when you need them. Let this vault fill with live work.

4. Work for a week. Change nothing.

Capture as you go. Meeting ends, write the event. Decision made, write the decision. Thought arrives at a red light, it goes in the inbox. Do not tune the system this week. Do not add templates. Just use it and notice what feels wrong.

5. Friday, twenty minutes.

Empty the inbox to zero. Sweep the task board — anything active that hasn’t moved in two weeks is either waiting or a lie. Look at your projects: is each active project actually being advanced by something in the task list? If not, it isn’t active. Say so.

6. Monthly, and this is the part that compounds.

Re-read the decisions whose review date has passed. Score the predictions that have resolved. You were right less often than you remember, and the record is the only thing standing between you and that comfortable illusion. Skip everything else in this manual before you skip this.

Part 5 — How it breaks

Every failure I’ve had has been one of five. Learn them cheaply, at my expense.

Silent invisibility. This is the killer, and it nearly ended the project. When I migrated from Notion, the import brought Notion’s field names with it — Priority with a capital P, where my templates wrote priority. To a human those are the same word. To the machine they are two unrelated properties. Dozens of notes existed perfectly on disk and appeared in no view anywhere. I couldn’t see them. I assumed the tool was failing and started drafting a migration back to Notion.

The tool was fine. My data was inconsistent, and the views were faithfully reporting an inconsistent vault. It took an afternoon to fix and a week to notice.

The lesson generalises past this specific bug: when something feels lost, suspect the metadata before you suspect the architecture. The instinct — mine, certainly — is to reorganise. Reorganising a system whose data is broken produces a differently-broken system.

Folder creep. You’ll want a folder for a topic. Don’t. Topics are area and related_project. The moment you create 05_content/AI Stuff/, you have reintroduced the filing question and every note now has two homes. The only exception I allow: when a project accumulates a real cluster of output, it earns a subfolder — but membership is still set by the property, and the folder is purely a convenience for pointing at.

The inbox graveyard. Miss two weeks and the inbox has forty items; now emptying it is a project, so you don’t, so it has eighty. Then it’s over. If you’re ever behind, declare bankruptcy: select all, delete, start clean. Anything that mattered will come back.

Over-templating. I have fifteen templates. I use four. The other eleven are scar tissue from Sunday afternoons spent working on the system instead of with it. Build a template when you’ve written the same note three times, not before.

Migrating structure instead of rebuilding it. The deepest one. When you carry your old system across, you carry its assumptions — Notion’s schema, Notion’s naming, Notion’s idea of what a database is. Those assumptions were built for a tool with different physics, and they will quietly poison the new system. Start empty. Let the structure emerge from a week of real work.

Part 6 — On Notion, fairly

I used Notion for years and it was good to me. It deserves an honest account.

Notion is better than this system at several things, and if any of them is your bottleneck, use Notion. It is better at collaboration — LifeOS is single-player by design. It is better at genuinely relational data: if you need a table of 500 rows with rollups, Notion will do it and Markdown will not. It is better looking, and that matters more than purists admit; a system you enjoy opening is a system you open.

What you trade for that is ownership and legibility. Your notes live in someone else’s database, in someone else’s schema, reachable through someone else’s API. They’re a pretty archive. They can’t easily become raw material.

I moved because of the third reason in Part 1. I wanted an AI that had read everything I’ve written — every client note, every decision, every draft — and could work inside it rather than talk about it. That requires plain text in a folder I control. Once I understood that, the decision made itself, and the aesthetic loss stopped bothering me within a fortnight.

If you don’t want that, Notion is a perfectly good answer and you should ignore this manual.

What to expect

This will not make you organised. I want to be precise about that, because every system like this one is sold on a transformation it can’t deliver.

What it does is smaller and more valuable: it makes your work findable, connected, and true. Findable, because you stopped filing and started querying. Connected, because links accumulate whether or not you’re paying attention. True, because changing state costs one word instead of a filing chore, so the state stays accurate — and an accurate system is one you can act on without checking.

The compounding is real but slow. For the first month it feels like extra work with no return. Around month three you’ll open a person’s note before a call and find the whole relationship laid out — meetings, decisions, the thing you promised in March — and you’ll realise you never wrote any of it down as history. It assembled itself while you were working.

That’s the moment it stops being a system you maintain and becomes a system that carries you. Everything in this manual exists to get you to that moment cheaply enough that you don’t quit first.

–

If you’d like to download an empty template of this setup, or have any questions, comments or variantes, send me an e-mail!