Notion Personal Operating System
Systems Design · Information Architecture · Execution
Turning a fragmented personal operating environment into a structured execution system.
Over several years, my personal Notion workspace had grown organically into a complex environment with duplicated databases, disconnected information, inconsistent structures and unclear relationships between goals, projects, tasks, knowledge and evidence.
Instead of adding another layer of tools, I treated the problem as a systems-design and architecture problem.
The problem
The challenge was not simply that there were "too many databases."
The deeper problem was that the system had lost a clear model of:
what information belonged where
how different objects related to each other
how work moved from goals to execution
where evidence of completed work should live
which structures were intentional and which were accumulated over time
Before changing the system, I needed to understand what actually existed.
Discovery & diagnosis
I conducted a structured audit of the existing architecture, mapping databases, properties, relationships and workflows.
The audit surfaced:
duplicated structures serving similar purposes
broken or missing relationships
information trapped across disconnected databases
unclear ownership of information
workflows without a defined lifecycle
legacy structures still connected to active systems
Rather than immediately rebuilding, I classified the existing architecture and identified dependencies, risks and decisions that needed to be resolved first.
The product decision
One of the central design constraints became the Database Absorption Test:
Before creating a new database, prove that an existing canonical database cannot absorb the requirement without becoming a poorly structured "mega-database".
This changed the design question from:
"Where should I store this?"
to:
"Does this represent a genuinely different lifecycle or information model?"
The constraint helped prevent solution sprawl and forced architectural decisions to be based on requirements, relationships and lifecycle, rather than convenience.
Target architecture
The resulting architecture establishes a clearer execution chain:
Goals → Initiatives → Projects → Tasks → Deliverables → Evidence
with dedicated structures for Knowledge, Learning and Resources alongside the execution layer.
The architecture was designed around a simple principle:
Information should ultimately support decisions and execution.
Prioritisation & decision gates
I deliberately did not attempt to rebuild everything at once.
Changes were sequenced according to dependencies and risk, with explicit decision gates before structural changes could be made.
During the design process, proposed solutions were repeatedly reviewed and either:
accepted
modified
deferred
or rejected
For example, proposed new databases were challenged against the Database Absorption Test rather than automatically added.
This created a controlled path from messy current state → defined target state → staged implementation.
Iteration & validation
The architecture was not treated as a one-off design exercise.
An earlier repair cycle was followed by a re-audit, which identified remaining gaps and informed further architectural changes.
Under the project's own assessment framework, internal coherence improved from approximately 4/10 to 6.5/10.
The current redesign is intentionally still in the architecture/decision stage rather than being presented as a completed migration.
What this demonstrates
Problem framing
Recognising that the underlying problem was architectural rather than simply organisational.
Requirements definition
Translating ambiguous information needs into explicit structural requirements.
Information architecture
Designing relationships between different types of information and work.
Prioritisation
Sequencing changes according to dependencies, risk and value.
Scope control
Using explicit constraints to prevent unnecessary system expansion.
Systems thinking
Considering how individual components affect the wider execution system.
Iteration
Reviewing the design against actual use and revising decisions when evidence exposed gaps.
Product takeaway
This project reinforced how I approach complex systems:
Understand the current state → define the problem → establish requirements and constraints → design the future state → prioritise → test → iterate.
The objective is not to build more.
It is to build the right structure for the way people actually need to work.
