Beyond PARA: A Hothouse For Embers

Adding "Embers", Repurposing Areas and Reframing Resources, And Finally Arriving At the PEAKER Method.

This is the fifth and final episode of my series called Beyond PARA. It is also the eleventh installment in the long series titled "PARAmore".

In the previous episode, I introduced you to The Keep. This structureless org space changes the whole PKM game. It acts as a forcing function to move us away from folder hierarchies and toward other means of organizing, namely tags, views, search, and — most of all — links.

The basic principles behind The Keep lead to an evolution of personal knowledge clusters. While we start to place everything in one big bucket, some cohesive groupings will form organically over time. The formation of these clusters is a truly bottom-up process. We can make guesses, but we can never be sure which clusters will eventually emerge and — more importantly — where they will lead us. In other words, unlike the spaces called Protocols, Efforts, and Areas, The Keep is undirected in that we don't have a clear goal for what we are working towards.

One popular way to emphasize and “lock in” emerging clusters has been introduced by Nick Milo and became known as Maps Of Content (MOCs), where one creates a kind of super-index note that glues various related notes together but above that itself also forms a note to be developed. This method is useful for marking clusters without fully “committing” to them. In some cases, as long as only notes (text files) and no other types of files are involved, it is certainly a great way to start.

However, The Keep embeds a somewhat different mantra: once a cluster reaches a certain sophistication and forms a standalone bubble, we "promote" it to a folder. With note apps, folders are the hardest PKM structure at our disposal. Folders give us confidence and certainty. File navigation cannot just break like links can. This is in defense of folders: they are the perfect way to materialize real knowledge clusters in our system. The folder, of course, can additionally contain index notes, TOCs, or even a MOC, but the key here is that it doesn’t have to. The grouping alone will form the hard shell that represents the boundary.

So, while structurless, The Keep can be seen as a breeding space for folders. However, they can’t be located in The Keep itself to keep its underlying principles intact. Any folder we add to The Keep acts like a magnet—it attracts more and more folders, which is exactly what we want to avoid. So, where do we put these new knowledge cluster folders?

Depending on their nature, they could arguably be placed into either Efforts, Areas or Resources. And as long as we stick to PARA/EARA, these are the only places they could possibly go. However, if we want to go all the way through with our new method called PEAKR, then there must be another solution. We have already deviated from PARA too much, and the boundaries of our remaining PARA buckets (Areas and Resources) are not as clear as they used to be. That is why, in this last episode today, we will rename and redefine both of them, which also makes it clearer that neither of them is the right place for our clusters. Efforts, too, is unsuitable since clusters may or may not contain actionable artifacts. Even if they all contained some actionable notes, not all items inside the clusters have action potential.

That leaves us with only one option: yet another organizational space.

A Hothouse For Embers

Our last org space in the PEAKER method will be called Embers. Embers will contain several things, but one of them is the above-mentioned artifact clusters that arise from The Keep and don't fit neatly into our other spaces. That is to say, if we breed a cluster that revolves around our standards, it should go to Areas. And if we end up with a cluster that is more like a collection of things, something like quotes, it should go to Resources. But often, this differentiates the knowledge builder from the mere knowledge manager, these clusters will be of a different kind.

For instance, I have had the inkling for the longest time that I want to start a blog about personal growth called Path of the Growth Pilgrim. Over the years, I have collected various resources for it. After several years, I made the first step and put up a Substack for it. That was in 2020, and I haven’t begun digging deeper into it. The time just isn’t right yet. I have, however, started collecting resources for this yet-to-be-born effort/program/area or whatever it might become. These resources started forming a cluster that now resides in my Embers space ready to be unleashed once I feel the time is right.

However, as mentioned above, this won’t be the only job of Embers. This new org space will be rather multifaceted. Here are some other things it will contain:

• Whenever we retire an area or a resource container (which in PARA we used to move into Archives) we can place these things into Embers to denote that they are not fully dead yet. They may be considered somewhat moribund, but there are still some “embers glowing”.

• Yet another use case for Embers is that it can contain things like book highlights and summaries or other annotated files that are either not yet qualified or, at some point, may become relevant. For instance, my Readwise highlights are synched directly into a folder in Embers. I used to treat them as a kind of sub-inbox but eventually realized that while they form a qualification zone, they aren’t a real inbox to be regularly reviewed. I certainly don’t want to slave away processing every single book highlight I take without a proper use case in place. So they make a perfect fit to become “embers”. Highlights from books and article highlights are not really “hot”, but they represent a somewhat “warm” artifact because the fact that I took the highlight indicates that at some point in the future I do want to revisit and make use of it. Embers thus also refer to somehow personally crafted but still unqualified artifacts.

• Lastly, to turn Efforts it into a truly actionable space, Embers will also be able to hold reference material for efforts. For instance, I am currently writing a book, and while I keep the effort note with the outline and other plans inside my Efforts, I don’t want the huge number of drafts, resources, notes with ideas, and finished chapters all within my Efforts space. So, Embers will hold non-administrative effort material for knowledge-heavy efforts. "Embers" as a term here indicates that these artifacts are not as hot as the main effort note, but they are somewhat ”warm" and "alive" through the effort. The book effort is a hot endeavor that sparks otherwise only warm knowledge building blocks and forges new artifacts in its fires. While I keep a hot effort note called "Book XYZ" in Efforts, I have a similarly named folder inside Embers for all of its “reference material”.

So, embers are part Efforts, Incubator, Archive, and even part qualification zone. They aren't quite efforts because they are not actionable in that sense, but they may very well relate to efforts. They aren’t really incubating either because we may engage with them somewhat actively and regularly, as in the case of reference material. And while some of them may behave like the stuff in our archives did, they certainly feel different. An “Archive” as a concept and term mainly encodes the “going out of life” side of things; “Embers” also embraces the opposite direction — things that are still somewhat alive or are just being born.

Maybe you can now better see how blurred our old PARA-based distinctions got. We should thus do away with them completely and see Embers as something new indeed: a hothouse for glowing formations in transit — things that may eventually burst into flames (again). Embers as a name captures and signals that the material it contains may either burn out or light up to fire at some point; in any case, it's still there, active in the game.

So, to recap, the new Embers org space will contain:

• Reference material for efforts

• Inactive/archived areas and resources

• Sources (other people's work) with or without our annotations/personalizations/highlights

• Classic archives (want to keep, even though not sure ever needed again)

• Moribund artifacts (practically dead, but still don't want to delete)

NOTE: Embers always contains clusters — standalone notes go into The Keep.

Reframing Areas and Resources

We have now completed our journey towards the PEAKER method, but I've touched a couple of times upon the fact that we also need to clean out the rough edges and somewhat redefine the remaining two PARA categories — Areas and Resources — as they now somewhat overlap with other categories. Resources, for instance, used to contain "topics of interest" - these could now equally well reside in The Keep or in Embers. Similarly, Areas contain standards and guiding artifacts that are now to be found in our Protocols. Therefore, to make our boundaries more crisp gain, I propose the following redefinitions:

• Resources becomes Records

• Areas becomes Arcs

From Ressources to Records

Resources in PARA encompass interesting topics such as

• “coffee” (if you aren’t a barista and don’t want to become one),

• “EDM” (if you aren’t a DJ and don’t want to become one),

• "Bitcoin” (if you don’t own any, but the idea behind it fascinates you),

• “Gardening” (if you are not much of a gardener (yet) but like plants).

If you have been going strictly by this official definition, most of your resources can now simply be moved to Embers.

However, maybe you’ve been bending the official definition without noticing it. “Resources” is a very vague word, and in my case, it always contained additional things other than "topics of interest." Personally, I almost immediately started placing my lifeless, mechanistic material there. Think invoices, checklists, templates, configuration files, logs, manuals, vouchers, images … things that are not supposed to be part of and fed into my knowledge-building process but simply need to be stored and organized somewhere. Since these inorganic artifacts do not support creative endeavors, they aren’t covered by the PARA content machinery. Tiago Forte himself keeps these lifeless artifacts in his filesystem outside of PARA.

However, if one really wanted to locate them within PARA, Resources would often be the best place to put them, even though they aren’t intended to be used this way. So, one trick I used early on, but that didn’t make it into the first season of this series (PARA modding) was that I started differentiating between References (PARA's topics of interest) and Resources (all this additional storage stuff that PARA doesn't cover). In PEAKER, the R will cover only the latter category: lifeless inorganic stuff that doesn’t belong to any area but wants to be stored by category (a type of artifact that PARA fails to address properly).

Since "resources" is such a vague and overloaded word, I called it something else: Records; it's not perfect, and it's up to you where you want to keep calling it Resources instead, the point is that this org space got a new job: it will now contain artifacts that we don't want to confuse with our knowledge base. Records, in other words, it will be a boring but necessary "storage and filing subsystem" with our system. All our templates, configs, images, bank statements, eBooks, or audio files that don’t really belong to our knowledge-building efforts will go there. We go even further and say that even if a certain record were, for a certain period of time, relevant for a certain effort or in an area at some point, we still would not move it there as we would do in PARA. With lifeless artifacts stored by category, it is counterproductive to move them around; they should have a fixed place and be reliably found. For example, it will be much easier to know that invoices or bank statements are records and, thus, always be found inside your Records space. While in PARA one option was always to put them in Areas this always brought up the semantic dilemma again — “Did I put my salary documents into my “Finances” or “Work” area?”

You can also see this Records as a remnant of the earliest generation of PKM. The only goal behind this is retrievability. You want to be able to store and retrieve inanimate files quickly. Records as a space pertains to lame reference management territory and often has little to do with creativity or building knowledge. But in a holistic universal system, we need a place to put these things anyway, and, ironically, PARA which is marketed as such, doesn’t cover them (or, if your take is that they go into Areas, PARA stores them in a really unbeneficial way).

So, if with PARA, you ever wondered where to keep your bank statements, you now can rest assured that they’ll be in Records.

From Areas to Arcs

The idea behind PARA‘s "areas of responsibility” is that you store artifacts that help you maintain a personal standard based on semantically divided parts of your life. For example, if you want to keep below a certain body fat percentage, an area called "Health" could contain your nutrition tracking sheet to help you achieve that. Likewise, if you want to keep your expenses in check, your "Finance" area might contain an Excel sheet where you track your spending.

While this sounds clear enough in theory, practically, this framing of "life areas" creates a lot of confusion. From my experience, the common source of confusion for PARA beginners is understanding why they can't simply put their weight loss project inside their Health area — as they would in all traditional org methods — and, to bring up the semantic dilemma from above again, whether they should put their invoices in a Finance area a folder within their Resources?¹

In other words, Areas have always been the most troublesome org space in PARA. Conceptually, just like with resources, the term "(life) area" encompasses too much. My marathon training plan, my food tracking sheet, and that eBook about that diet I want to try all fit nicely into a folder called “Health”. This trips up many people and makes them wonder why they can't nest their projects under the respective areas. The reason, of course, is PARA‘s paradigm shift in the underlying organization principle. It focuses on actionability and visibility — not retrievability. It wants you to have the most important things right where you need/use them next. Once one understands this, one can accept and productively work with this conceptual incongruency.

However, we are overhauling our whole system, allowing us to do better. So what is an alternative to vague Areas to think about various “domains” in our lives? One that comes to mind is the important roles we take on in our lives. Most of our life areas will neatly map to one or even multiple such roles. Others won’t map to any role, which are good candidates to eliminate completely. A folder called "Father" much better encodes intent than one with my son’s name on it. It is much clearer what this folder is for and what the actual standards and responsibilities are. In a folder titled after my kid I can keep all kinds of stuff that won’t help me with parenting and being a good father. It’ll likely attract stuff like images, birth or other certificates, insurance, and banking documents. Now, you might argue that to be a “good” father, these documents are relevant, and to that, I want to say two things: First, remember how we shifted Resources into Records — these files (certificates, statements, …) are lifeless “records,” and we centralized them to one point so that we always know where to find them. In PEAKER, the birth certificate of my son goes into Records, not an area associated with my son. Second, and more importantly, we can tell a different story by encoding a role instead of a mere area. Yes, I need to reference that certificate PDF once in a while, but doing so doesn’t make me a good or better father. My wife could do so; my parents could if need be. In fact, everyone could, in my stead, wield this file to achieve things without being my son’s “father”. Thus, this document is not exclusively about my role as a father and doesn’t belong here.

Similarly, an area called "Finance" attracts many documents: invoices, warranties, banking documents. If I instead move these documents to my new Records space as they don’t help me get anywhere, and only keep the truly relevant things in a role-based folder, my folders become a lot cleaner and leaner. My role here may be, for instance, supporting my family. In that case, a folder called “Family Provider” says much more about what I am trying to achieve. It tells me that a bank statement stored merely for reference and backup won't help me with fulfilling this role, so I can move these files to Records. However, my personal budgets, an Excel where I track my spending, will help me with this, so it goes into the role-based folder.

“Employee" hints at something completely different than a folder named after my employer. It signals responsibilities and more clearly tells me what artifacts actually go there. A time tracking sheet, my contract (which defines my responsibilities), and a general note about my employer — all yes. Documents related to my job search, my profession as a software engineer, and my CV — no, as they don’t make me a better employee.

Role-based instead of area-based folders will help us pinpoint what we keep documents for in the first place. A folder called “Finance” basically doesn’t encode any intention whatsoever. Similarly, a folder called “Home Owner” strikes differently than “House”. After all, we are involved with personal knowledge management here, and there is no need to choose terms everyone “gets.” One of my folders is called “Strong Avatar,” for instance. It encodes a very special relationship I want to form with my body.

Having role-based folders nudges us to think more deeply about what artifacts to put inside. It forces us to put only the absolute best things there and exclude the lame and lifeless documents that are now in Records. Instead of asking “which life area does this best fit in?”, we ask “to which role – if any — does this pertain?” This shift will take some time to get used to. The naming of the folders will also be harder. To ease the transition, you could temporarily encode both area and role into folder names, e.g., “Father—Name,” so that it becomes easier to learn the new mappings. However, this additional struggle is actually very beneficial and shows us that we are encoding yet another key aspect of growth and becoming into our system — just like we did with Protocols, this space will be giving us direction.

Areas in PARA pertain to responsibilities and standards. One could thus say that this definition already fits the approach of the role-based folder I am outlining here. That is just a coincidence, as nowhere in teaching materials and also not in Forte’s own system do we find role-based folders. What is more, in addition to standards to upkeep, I want you to also encode how we can, over time, elevate our standards to new rights. I want you to encode very long-term and slow “goals”. For instance, I might not only want to be a mere “provider” but instead strive to become “financially independent” over time. While this aspiration can be handled the classic way via goals (and then it would be a matter of Protocols and Efforts). However, there is also a way of interpreting our “roles” in life as “lifetime goals.” Whether I fulfilled my aspiration of “being a good father” I can only really tell the day I cease from this world, as this is when my role ends. The term deadline shines in a whole new light.

For instance, I have a folder called “Liberty Man” – it encodes more than financial freedom; it encodes freedom in general, which is one of the values and goals I am steadily striving towards. I don’t really care to achieve this by 40/50/60 years of age, though. I just keep working towards it and will know when I’ll get there.

So, the “goals” behind life roles such as father, employee, caretaker are not the types of goals we set in Protocols. Instead, what we find here are our longest-term aspirations toward excellence. They do not merely represent standards we upkeep — they represent standards we iterate on. So within each role-based folder, we encode the optimal ideal we strive for in the long term.

Arriving at my roles took several years and a lot of experimentation and iteration, as well as getting used to them, but it makes these folders much more special and, contrary to what one might think, less bound to change. It also tends to decrease the total number of folders (While I had at some point over 30 area containers in my Areas, I now have less than 20 role containers).

My proposed term for this space is Arcs , which hints at my concept of Arcs of Aspiration, which I recently wrote about. One doesn’t need to understand what this entails for our purposes here fully. At its core, the Arcs space will embody the philosophy that we must never grow complacent but must always seek ways to upkeep and also to improve. We must strive towards the ideal versions of ourselves across all areas of life. And a role-based perspective helps a lot in finding the right ideals. Ideals aren’t fully reachable, so we know we don’t have to be too hard on ourselves about the fact that we never will. Instead, we encode the process of continuous improvement. This keeps us alert to possibilities for reaching our potential in all areas of life. To maintain balance but also to advance. Because when we stop to grow, we start to die. Merely maintaining is not enough.

Practically speaking, from many of your areas, it will be clear which role you should take on. So, you must find a proper name and remove any artifacts that no longer fit. Many of them will go to Records or Embers. However, if you haven't figured out all of them, stick with a view area until you arrive there. This may take a while.

PEAKER — A Quick Recap

So, that’s it. Let's quickly recap where we have now arrived at.

The PEAKER organizational method for vertical life sculpting and knowledge building contains 7 spaces:

1. +² — our inbox

2. Protocols — our practical philosophy

3. Efforts — our artifacts with action-potential

4. Arcs — our arcs of aspiration, or arete (roles of excellence)³

5. Keep — our unstructured knowledge base

6. Embers — our space to embrace change (this is a hard space to describe…)

7. Records – our inanimate and lifeless artifacts

That’s about as good as I can currently put it into words. Since writing this essay series influenced my thoughts about PEAKER quite a bit; I may find better ways to describe it soon and probably release a standalone and very condensed essay.

However, I will try my luck at giving you one different perspective to look at it through the means of an analogy to a house:

1. + — The letter box in front of our house where most new stuff arrives. Most, but not everything, will arrive here. Sometimes, a friend brings in stuff through the back door (Think Readwise sync).

2. Protocols — the blueprint, containing all guiding artifacts, our compass.

3. Efforts—Our office, where we keep everything that we can actually take action on close at hand. To keep our work environment clean, reference material resides elsewhere.

4. Arcs—The various rooms in our house (bedroom, kitchen, hobby room, …) for different purposes. They ensure balance, upkeep, and continuous elevation of our standards towards our own ideals.

5. Keep — the library — or, rather, the anti-library. Also, this library is not nearly organized into shelves; it’s more like the books are everywhere: on shelves, on the walls and the ceiling, and the floor, some of which form small staples.

6. Embers — the attic, the workshop, the garage, the greenhouse in the garden — all places where we keep material for rarer occasions for bigger efforts, things in the "slow making" someday-maybe endeavors, inactive and moribund things that we approach with a "wait and see" strategy, but also, importantly, where we develop and hatch knowledge clusters that formed organically within our Keep.

7. Records – the basement where we keep stocks and staples, neatly categorized by general topic and the type of thing something is.

Summing Up

PARA and ACE make for good Lebensabschnittsgefährten (that’s a uniquely German term meaning a “life partner for only a phase of life”). PEAKER, however, is marriage material. Not because I think it is better but because it’s based on a more potent organizing principle: alignment. It’s not a warehouse-like Johnny Decimal, not a PARA kind of content factory, and not a universal system for knowledge like ACE or even ACEx. Instead, it attempts to highlight the Personal in PKM and turns it into something much more aligned with ourselves.

PKM is not really about the things we store and what we output, and also not about the knowledge we build. It is about us. PEAKER doesn’t miss the point of PKM like Johnny Decimal does. It doesn’t treat PKM merely as a means to an end like PARA does, and it also doesn’t overdo it and treats PKM as an end in and of itself like ACE, either. Instead, it’s mainly about personal growth. Yes, sometimes, that involves content production, and our Efforts and Embers spaces help us with that. And yes, often growing is about sense-making, and The Keep and again our Embers are there for us when we need them. Sometimes, our lives even involve a lot of lame old filing, that’s why we have Records. Overall, however, PEAKER shines through Protocols and Arcs. While intermixing “self-change” and “knowledge” may be a no-go in the more objective world of collaborative knowledge management, PKM allows and even encourages us to use our uniqueness to our advantage.

That’s all I have to say about it for now. At some point, I will write a summary post on the PEAKER method, just like I did with The Ultimate Guide to Personal Program Management (PPM). There is more about how I use and approach the method in general. For example, a possible extension for power users contains an additional org space called Vaults to separate really mature knowledge clusters. However, I’ll leave that advanced use case for another time.

This marks the end of our series on Beyond PARA. I hope you enjoyed and got something out of it. Make sure to read it before it disappears behind the paywall (after 3 months of being free) or consider a premium subscription as a means of showing your appreciation. Right now is a very good time as for the very first and maybe last time, I’m running a promotion: 50% off annual subs for a few more weeks only.

---

Now, I’m curios: Which of the episodes of Beyond PARA did you enjoy most? Did you adapt any of the spaces and ideas I proposed? Are you even planning to try PEAKER out as a whole? Please let us know in the comments :)

---

What to read next? My vertical life sculpting series is ongoing right now. I also recently started a second newsletter called "Knowledge Builders" with a short FAQ format that will explore many of the nuances of PKM and PKB. If you have PKM down but struggle with task management, check out my series on Smart Task Management Based On First Principles.

1. In the PEAKER method, this is now solved by the new Records space. The active Excel sheet to track spending remains in your Areas, or Arcs, at it will be called, but the lifeless invoice moves to Records.

Whenever you need to "store" or "file" something into some kind of archive, relatively mechanistically, then there is a good chance the Records space is the right place. The same goes for very unpersonalized things like a bank statement. Arcs, on the other hand, are always more “exciting” and lively. Most of the time, you created these artifacts yourself — such as with the Excel tracking sheet — or you made them your own or used them frequently.

2. I learned and adapted the practice of referring to my inbox simply as a + sign from Nick Milo. This has various advantages, such as that it floats to the top with alphabetic sorting, is shorter to write, and is more exact and glanceable in searches.

3. I first heard the term arete in MacSparky’s new Productivity Field Guide. Although he uses the term differently from its philosophical meaning, it is a somewhat fitting application. In his course, he also talks about role-based productivity, but unfortunately, he commits several grave mistakes:

1. unfortunately, he adds to the lost-crispness problem and claims that productivity is not about doing things faster, effectively misusing the term.

2. he teaches pretty commonplace concepts such as timeboxing and even advocates for a rather extreme version that has no buffers and doesn’t account for personal energy management.

3. most importantly, he jumps on the James Clear train of bashing goals and also does away with personal missions/vision completely, which drives me nuts... He argues that roles are all you need in life, that they make up your whole WHY in life. If we were to map that approach to the PEAKER method, he would do away with Protocols and only focus on Arcs

Overall, it was a decent short course, mostly targeted at beginners (there wasn’t anything new except the concept of areté, which I wasn’t aware of). Even though he claims to have worked on it for 7 years, I feel that the price of 99€ wasn’t worth it. If you read Fractal Productivity, you don’t need that field guide. You’re welcome; I just saved you 99 bucks.