The PIM Matrix: A Unified Theory of Personal Information Management
The Problem Everyone Has and Nobody Solves
You use too many tools. You know this. You have notes in three places, tasks in two, bookmarks you’ll never revisit, and an email inbox that functions as a to-do list even though you swore it wouldn’t. You’ve read the GTD book. You’ve tried the Zettelkasten method. You’ve migrated from Evernote to Notion to Obsidian and felt the same hollow thrill each time: this is the one that will unify everything.
It never does, because the problem isn’t the tool. The problem is that no single tool can cover the full space of what personal information management actually is. The tools aren’t failing you. You’re asking each one to be something it was never shaped to be.
What if the answer isn’t a better tool, but a better way to think about the space that tools occupy?
Why You Have Five Note-Taking Apps
Here’s a question nobody asks: if Apple Notes and Obsidian are both “note-taking apps,” why do people use both?
Because they’re not doing the same job. Apple Notes is where you paste your Wi-Fi password and your doctor’s phone number. Obsidian is where you develop ideas across weeks, linking thoughts into an evolving web. A journaling app like Day One is where you process experience into narrative. They’re all “notes.” They serve completely different cognitive functions.
The typical response to this observation is to build a tool that does everything. Notion tried this. The result is a tool that can be configured to do everything, eventually, after you’ve spent more time designing your workspace than actually thinking inside it.
The better response is to recognize that the space has structure, and to name that structure clearly.
Three Axes
Personal information management, across all tools and all workflows, can be described by three independent axes.
Axis 1: Object Type
This is the obvious one. The kinds of things you manage:
- Note—a living document. Authored, revised, evolved. Its value is in its current state.
- Entry—a time-stamped record. A journal entry, meeting notes, a daily log. Authored but fixed once written.
- Task—a state transition. Something that needs to move from undone to done.
- Event—a temporal anchor. Something happening at a time, optionally for a duration.
- Message—communication across a boundary. Email, text, chat. Has a sender, a recipient, a body.
- Contact—an entity in the world. A person, business, or organization. Not their information—them.
- Resource—a pointer to an external substance. A URL, a filepath, a DOI. The PIM holds the pointer; the substance lives elsewhere.
- Topic—a named area of concern. A project, an area of responsibility, a client, a goal.
These eight types are not an arbitrary list. They’re generated by three independent binary properties of information: diachrony (is the thing constituted by change across time?), sovereignty (is the user the sole authority on its truth?), and structuredness (is it fully described by its fields, or does it carry content that must be read?). Each type is a unique combination of three binary choices, and every combination produces a recognizable kind of thing.
| Unstructured | Structured | |
|---|---|---|
| Diachronic + Referential | Message | Event |
| Diachronic + Sovereign | Entry | Task |
| Synchronic + Referential | Resource | Contact |
| Synchronic + Sovereign | Note | Topic |
A few of these types deserve elaboration.
The distinction between Note and Entry is the reason you use both Obsidian and Day One. A note exists in a perpetual present—you revise it, refine it, link it. Its value is in its current state. An entry is fixed in time—you wrote it on a specific date and it is a thing of that date. You don’t go back and rework it. Both are authored, sovereign, unstructured. But one is synchronic and one is diachronic, and that makes them different cognitive objects.
Resource subsumes what traditional PIMs split into “bookmarks” and “files.” Both are pointers to things outside the system. A bookmark points to a URL. A file reference points to a path on disk. From the PIM’s perspective, that’s an attribute difference, not a type difference. The system can’t act on external content—it can only point to it and extract from it.
Topic is the organizational backbone. It’s not information the way a note or a message is. It’s a container of meaning—the answer to “what is this about?” or “what part of my life does this belong to?” An OmniFocus project is a topic. A Johnny Decimal category is a topic. A PARA area of responsibility is a topic. Topics can relate to other topics—that’s where hierarchy comes from. A flat tag is just a topic with no parent.
Axis 2: Verb
What you do with those objects. Not the twenty-seven toolbar actions in your app of choice, but the fundamental operations:
- Capture—bring something new into the system. Jot the thought, save the link, create the task.
- Retrieve—find something that’s already in the system. Search, browse, look up.
- Organize—give something structure and location. Tag, file, link, prioritize.
- Review—surface what’s relevant right now. What’s due, what’s unread, what needs attention.
- Dispatch—push something outward. Send the email, share the file, delegate the task, open the link.
Five verbs. That’s it. Every interaction you have with every PIM tool is one of these five operations applied to one of the eight object types. The matrix of verbs and object types produces 40 cells, and each cell has a concrete, recognizable meaning. “Capture a reference” is saving a URL. “Review tasks” is checking your due list. “Dispatch a message” is sending an email.
Some cells are dense with functionality. Others are sparse. “Dispatch a task” is thin—really just delegation, which is dispatching a message about a task. That sparsity is informative. It tells you something about the nature of tasks: they’re primarily internal objects. They don’t go out into the world the way messages do.
(Under the hood, these five verbs decompose further. “Organize” is really creating and updating relations between objects. “Review” is really querying those relations. The companion ontology document covers this decomposition in detail. But for thinking about your tools and your workflows, five verbs is the right level of abstraction.)
Axis 3: Register
This is the axis nobody talks about, and it’s the reason you have five note apps.
Every information object in your life exists in one of four cognitive registers:
- Scratch—unprocessed, just captured, no investment yet. The inbox, the quick note, the “remind me to…” tossed into the void.
- Reference—processed and depersonalized. Stable. Looked up more than written to. Your Wi-Fi password, the office address, the API documentation you check once a month.
- Working—actively engaged. Being shaped, linked, restructured. Your current project notes, your active task lists, the email thread you’re negotiating in.
- Log—the subjective residue of your engagement with information over time. Your journal, your annotations, your completed-task history, your interaction record with a contact.
Like the object types, these four registers aren’t arbitrary. They’re generated by two binary properties: stability (does the content change once it’s here?) and intentionality (did the user deliberately place the object here, or did it arrive on its own?).
| Accrued | Curated | |
|---|---|---|
| Unstable | Scratch | Working |
| Stable | Log | Reference |
Scratch is an inbox—things pile up and need triage. Working is a workbench—things don’t pile up, they get replaced and revised; each edit is superimposed on the last. Log is a journal—things pile up in sequence, and nothing changes once it’s there. Reference is a filing cabinet—things are placed deliberately and stay put.
The accrued registers have a sequential character: things arrive in order, building a stack. The curated registers have a snapshot character: things are placed deliberately, replacing or refining what’s there. These tendencies parallel the diachrony of the type axis—but the parallel is suggestive, not exact: a diachronic entry can be deliberately curated as reference, and a synchronic contact can accrue in scratch when auto-extracted from email. The two axes are independent.
This is why Apple Notes and Obsidian coexist. Apple Notes lives in the Reference register—stable, looked up, rarely revised. Obsidian lives in Working—linked, evolving, actively shaped. Day One isn’t a note app at all in this model—it’s an Entry app, a different object type entirely. Entries are diachronic where notes are synchronic. The person who uses all three isn’t disorganized. They’ve intuitively partitioned both the register axis and the type axis, even if they’ve never named either.
The Matrix
Combine the three axes and you get a three-dimensional space: 8 object types × 5 verbs × 4 registers = 160 cells. This is the PIM Matrix.
The matrix has three faces. Each face is a cross-section of two axes, and each tells you something different.
Face 1: Verb × Object Type
What can you do with each kind of thing?
| Note | Entry | Task | Event | Message | Contact | Resource | Topic | |
|---|---|---|---|---|---|---|---|---|
| Capture | Create, start writing | Log, append | Quick-add, create | Create event | Compose draft | Create contact | Save URL/filepath | Create project/area |
| Retrieve | Search, read | Browse by date | Query status/date/tag | List by range | Search, read thread | Lookup name/field | Search, list | List projects, find by name |
| Organize | Tag, link, folder | Tag mood/theme | Context/tag, defer | Set calendar, categorize | Label, archive, folder | Group, tag | Tag, folder | Nest under parent, reorder |
| Review | Recent, modified | ”What happened this week?” | Due, flagged, stalled | Today, upcoming, conflicts | Unread, flagged | Recent contact, favorites | Unread, recent saves | Active, stalled, on hold |
| Dispatch | Share/publish | Share reflection | Delegate | Send invite, RSVP | Send message/email | Share vCard | Open URL, share link | Ship, publish, submit, deploy |
Face 2: Verb × Register
How does each operation change character depending on your level of engagement?
| Scratch | Reference | Working | Log | |
|---|---|---|---|---|
| Capture | Quick-add, inbox, voice memo | Save stable fact, paste details | Create linked note, open task in project | Append entry, log event |
| Retrieve | Check inbox, recent captures | Lookup known item by keyword | Search by relationship/context | Browse by date, search by period |
| Organize | Triage: promote, file, or discard | Categorize, keep findable | Link, tag, restructure, refactor | Tag mood/theme, mostly auto-organized by time |
| Review | ”What’s unprocessed?" | "Is this still current?" | "What’s active, what’s stuck?" | "What happened this week/month?” |
| Dispatch | Forward raw capture to someone | Share reference with someone | Publish, export, share working document | Share reflection (rarely) |
Face 3: Object Type × Register
Which tool handles which cell? This is the face that maps directly to your personal setup.
| Scratch | Reference | Working | Log | |
|---|---|---|---|---|
| Note | Quick capture, inbox | Stable info (account numbers, SOPs) | Obsidian, Org-Roam—linked, evolving | —(notes in log register are really entries) |
| Entry | Voice memo, raw jotting | —(entries are temporal by nature) | — | Day One, daily log, meeting notes |
| Task | Reminders, OmniFocus inbox | Checklists, standing procedures | OmniFocus actions, contexts | Completed task log |
| Event | ”Quick event” creation | Recurring/standing meetings | Actively planned events, scheduling | Calendar as historical record |
| Message | Drafts, unsent | Templates, canned responses | Active threads, negotiations | Sent mail archive |
| Contact | New contact from business card | Address book | Active collaborators, CRM-like | Interaction history |
| Resource | Reading list, downloads, save-for-later | JD-filed docs, permanent links | Research collection, active reading | Annotated resources |
| Topic | ”New client, need to set up” | JD categories, PARA areas | Active projects | Archived/completed projects |
Face 3 is the most revealing. It’s where you can literally point to cells and name the app that lives there—and where someone else would name a completely different app for the same cell. Your PIM setup is your personal tiling of Face 3.
Every PIM tool you’ve ever used occupies some region of this matrix. OmniFocus covers the Task column, primarily in the Working register, across most verbs. Apple Reminders covers the Task column too, but mostly Scratch and Reference—quick capture, simple lists. They’re not competitors. They’re addressing different cells.
Your email client covers Message across all registers and all verbs. Your calendar covers Event. Your filesystem covers Resource. Each tool has a footprint in the matrix—a set of cells it handles well.
And here’s the key insight: no tool needs to cover the whole matrix, and no person uses the whole matrix. Your personal PIM setup is a tiling of the matrix. You’ve covered the cells that matter to your life and work with whatever combination of tools made sense at the time. The gaps are the things you don’t manage well. The overlaps are the things that feel redundant or confusing.
Seeing the matrix makes those gaps and overlaps visible for the first time.
The Space Between Tools
The matrix explains why you have the tools you have. But the real problem isn’t inside any single tool. It’s in the space between them.
When you read an email and realize it contains a task, you’re performing a transform—converting an object in one region of the matrix into an object in another. You retrieve a message, then capture a task. The information crosses a tool boundary. In practice, this means you copy-paste, or you just try to remember, or you use some brittle automation that breaks every six months.
When you want to see everything related to a project, you need to query across tools. The relevant notes are in Obsidian, the tasks are in OmniFocus, the emails are in your inbox, the references are scattered across your filesystem, the meetings are on your calendar. No tool has the complete picture because no tool covers the whole matrix.
When you want to connect a journal entry to the meeting that prompted it, or a reference to the note where you discussed it, or a contact to every message and task and event involving that person—you’re reaching for relations that cross tool boundaries. And no tool supports this, because each tool can only see its own objects.
The missing layer is the one that sits above all your tools and understands the matrix as a whole. Not a super-app that replaces everything. An orchestration layer that connects everything.
Objects, Identity, and Relations
For an orchestration layer to work, every object across every tool needs to be addressable in a common way.
Every PIM tool already assigns internal identifiers to its objects. OmniFocus has task IDs. Obsidian has file paths. Your email client has message IDs. Calendar events have UIDs. The orchestration layer maps these native identifiers into a universal address space—a URI scheme that can point to any object in any tool.
A note in Obsidian, a task in OmniFocus, an email in your inbox, and an entry in Day One can all be referenced by a common address. The tool that holds each object is just a detail of the address.
With universal addressing, you can build relations: typed connections between any two objects, regardless of which tools hold them. A relation has a source, a target, and a type. “This note is derived from that email.” “This task blocks that task.” “This entry is an annotation of that meeting.” “This reference is cited by that note.”
Some tools already support internal relations. Obsidian has backlinks. Org-Roam’s entire model is a graph of linked notes. The orchestration layer extends that graph across every tool in your matrix. The link between an Obsidian note and another Obsidian note is stored natively in Obsidian. The link between an Obsidian note and an OmniFocus task is stored in the orchestration layer’s relation index, because neither tool natively understands the other.
The relation index is the thing that makes the whole system more than the sum of its tools. It’s the connective tissue that only exists at the orchestration layer—the place where your personal information stops being a scattered collection of app databases and starts being a graph.
Transforms
The matrix doesn’t just describe what things are and where they live. It describes how information moves.
When you read an email and pull tasks from it, you’re moving information along the structuredness axis: from unstructured (a message body) to structured (task records). This is extraction, and it fans out—one message might yield three tasks, two contacts, and an event.
When you synthesize a week of task completions and meeting notes into a status report, you’re moving in the opposite direction: from structured to unstructured. This is narration, and it fans in—many records consolidate into one document.
Two of the three axes are symmetric—each direction of crossing is a genuine transform. The third, diachrony, is asymmetric. Five fundamental transforms:
Structuredness axis:
- Extraction (unstructured → structured): read content, derive records. Fan-out.
- Narration (structured → unstructured): synthesize records into prose. Fan-in.
Sovereignty axis:
- Capture (referential → sovereign): ingest from the world. Fan-out.
- Dispatch (sovereign → referential): push out into the world. Fan-in.
Diachrony axis:
- Distillation (diachronic → synchronic): extract the timeless from the time-bound. A series of journal entries becomes an evergreen note. Fan-in.
The diachrony axis is one-directional. Distillation is lossy compression: it summarizes a process into a timeless artifact. There is no inverse. You can always summarize history into a snapshot, but you can’t inflate a snapshot into a history—a process requires having actually happened, and you can’t fabricate that from a state. What looks like a reverse transform—anchoring a synchronic note to a date—isn’t a transform of the note at all. It’s the creation of a new diachronic object (an event, a task) linked back to the synchronic source. The note remains a note.
These transforms compose. Receiving an email and pulling tasks from it is capture (referential → sovereign) plus extraction (unstructured → structured)—two axis crossings in one workflow. Writing a status report from your task list and sending it is narration (structured → unstructured) plus dispatch (sovereign → referential).
The system breathes. Capture and extraction fan out—inhaling structure from the world. Narration and dispatch fan in—exhaling narrative back into it. An orchestration layer that understands these transforms can recognize what the user means by “process this email” or “write up where we are on Project X” and chain the right operations automatically.
Contacts as Hubs
One object type deserves special attention: contacts.
A contact isn’t a phone number or an email address. It’s an entity—a person, a business, an organization. The contact information is just attributes. The entity itself is a node in your information graph, and probably one of the densest nodes there is.
A person connects to the messages you’ve exchanged with them, the tasks you’ve delegated to them or they’ve assigned to you, the events you’ve shared, the notes you’ve written about conversations with them, the references they’ve sent you. When you ask “what’s my history with Sarah?” you’re asking for every relation in the graph where Sarah is a participant.
This makes contacts a natural hub for the kind of cross-tool queries the orchestration layer enables. “Show me everything connected to this person” is a query that fans out across every adapter and returns a unified view of a relationship—not just the data in your address book, but the full texture of your engagement with another person over time.
Swappability
If tools are just implementations of regions in the matrix, then swapping one tool for another should be straightforward in principle. If you move from OmniFocus to Things, you’re replacing the adapter that handles the Task column. The verbs, registers, and relations stay the same. The orchestration layer doesn’t care which app manages your tasks, as long as the adapter supports the same operations.
In practice, tools vary in capability. OmniFocus supports defer dates, sequential versus parallel task ordering, and custom perspectives. Apple Reminders supports almost none of that. And some tools blur object types: an OmniFocus “project” is really a Topic that contains Tasks, handled by a single adapter. The orchestration layer needs to account for this: each adapter declares not just which cells it covers, but which capabilities it supports within those cells. The orchestrator can then adapt—using advanced features when the adapter supports them, falling back to simpler operations when it doesn’t.
This also means that the adapter contract is minimal by design. To plug into the system, a tool needs to: expose its objects with stable identifiers, support some subset of the five verbs for its object types, and declare what it can and can’t do. The rest is the orchestrator’s job.
What Changes
The PIM Matrix isn’t a product. It’s a way of seeing.
Once you have the model, several things become possible that weren’t before. You can look at your personal tool setup and see it as a tiling of the matrix—identify gaps, redundancies, and opportunities. You can evaluate new tools not by their feature lists but by which cells they’d cover. You can build automations and integrations that are expressed in terms of verbs and object types rather than tool-specific APIs, making them portable across tool changes.
And you can build an orchestration layer—an AI-native one, in particular—that understands your intent in terms of the matrix and routes actions to the right tools. When you say “remind me to follow up with Sarah about the contract next Tuesday,” the orchestrator decomposes this: retrieve a contact, capture a task with a due date, maybe link to the relevant email thread. Three verbs, three object types, three adapters, one coherent action. You don’t think about which app to open. The matrix already knows.
The goal isn’t to replace your tools. It’s to make the space between them disappear.