PPV Outside of Notion – Notion Life Operating System
Based on August Bradley's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Use pillars as the universal categorization layer across Notion and every hierarchical storage tool, so the “where” stays stable.
Briefing
A life operating system built on Notion’s “pillars, pipelines, and vaults” can stay just as usable outside Notion—by exporting the same categorization into any hierarchical file system like Dropbox, Google Drive, Box, Evernote, and OneNote. The core idea is consistency: everything that belongs to a person’s life gets slotted into the same pillar categories everywhere, so files and knowledge don’t drift into different folder logic depending on the tool.
In the Notion setup, pillars act as the top-level slices of life—typically 5 to 15 categories—that everything else must fit under. Pipelines hold the moving parts: tasks, projects, and goals. Vaults store the knowledge layer: notes, ideas, training materials, tools, and skills. Dashboards then let a person view what’s relevant to each pillar across pipelines and vaults. That structure works well inside Notion because relational links keep the system navigable.
The challenge comes when work spills into tools that are better at certain file behaviors—large files, quick open/close workflows, and synced folder hierarchies on a computer. Notion can consolidate a lot, but it doesn’t replace the practical strengths of cloud-synced directories. That’s where the pillar system becomes the bridge. The transcript describes using the same pillar categories as the folder hierarchy in Dropbox and Google Drive, and mirroring the same logic in Evernote and OneNote so paper filing and digital storage stay aligned.
A concrete example is a Dropbox folder structure on Windows and macOS. Instead of using only three top-level folders (Growth, Business, Home Life), the system adds an extra layer to reduce clicks: Business, Growth, and Home Life are abbreviated as B, G, and H. Under each letter sit the pillar names (for Business: admin, client, execution, content creation, product development, sales, and marketing; with the same pillar list reproduced under Growth and Home Life). Visual cues are matched too—icons and colors in Dropbox are aligned with the Notion color scheme (green for Growth, gold for Business, blue for Home Life). Within each pillar folder, the system supports ordering (sometimes via numbering) and cleanup through an archive convention: z_underscore archive folders store older material without breaking the category logic.
The transcript also draws a sharp contrast with PARA-style prioritization (Projects, Areas, Resources, Archives). Prioritization-based hierarchies can feel intuitive at first, but they shift as deadlines pass and interests change—so assets move between levels, forcing users to search and re-learn where things went. Pillars avoid that churn by keeping the “where” stable; prioritization, if needed, should happen inside a pillar (for example, splitting a busy content-creation folder into hot and cold topics) rather than replacing the top-level structure.
The payoff is operational: once the pillar hierarchy is consistent across Notion and external storage, people stop hunting for files, reduce context switching, and gain a reliable mental map of where information lives—whether it’s an active project, a reference vault, or a paper document in a file cabinet structured the same way.
Cornell Notes
The pillars–pipelines–vaults system stays effective outside Notion when the same pillar categories are mirrored into any hierarchical storage tool. Pillars provide stable life “slices” (typically 5–15) that everything—tasks, projects, knowledge, and notes—must map to. Pipelines handle the active work (tasks/projects/goals), while vaults hold stored knowledge (notes, training, tools, skills). In Dropbox/Drive and similar systems, the transcript recommends using the pillar hierarchy as the folder structure, including consistent naming, color/icon cues, and an archive convention (z_underscore archive) to prevent clutter without moving items across categories. This approach avoids the confusion of priority-based folder schemes where items constantly shift as projects end or interests change.
Why do pillars matter more than the specific tool (Notion vs Dropbox/Drive)?
How do pipelines and vaults fit into the pillar structure?
What folder hierarchy does the transcript recommend for Dropbox/Drive to match Notion?
How does the system handle cleanup without breaking the hierarchy?
Why is a priority-based hierarchy (PARA-style) described as problematic?
What’s the practical benefit of mirroring pillars into a file cabinet and paper filing?
Review Questions
- If a document is no longer actively used, where should it go in the pillar-based folder system, and why?
- How would you implement “hot vs cold” prioritization without abandoning the pillar hierarchy?
- What specific failure mode occurs in a priority-based folder scheme when projects and interests change over time?
Key Points
- 1
Use pillars as the universal categorization layer across Notion and every hierarchical storage tool, so the “where” stays stable.
- 2
Treat pipelines as the active layer (tasks/projects/goals) and vaults as the knowledge layer (notes, training, tools/skills), both mapped to pillars.
- 3
In Dropbox/Drive, mirror the pillar hierarchy with consistent naming (e.g., B/G/H) and matching visual cues (colors/icons) to reduce retrieval friction.
- 4
Use z_underscore archive folders inside each pillar to declutter while keeping items in the correct category context.
- 5
Reserve special utility folders (like underscore delivery) for truly temporary or auto-captured workflows, not for general organization.
- 6
Avoid top-level priority hierarchies that force assets to move as priorities change; if prioritization is needed, apply it inside a pillar (e.g., hot/cold).