Skip to main content

04 - The Knowledge Lifecycle

The Knowledge Lifecycle-1

info

This article was published on October 29, 2021 by Alan Chan, co-founder of Heptabase, one month after the company was incorporated.

Foreword

After finishing the first three articles (My Vision: The Context, My Vision: A New City, My Vision: A Forgotten History), I will begin introducing the next generation of the internet that I am building, Heptabase, from different perspectives starting with this article.

Heptabase’s vision is to create a contextualized knowledge internet, and an ecosystem of tools surrounding this knowledge internet, to augment the individual and collective intelligence of knowledge workers around the world. In this article, I will introduce this vision from the perspective of “The lifecycle of human knowledge work.”

The lifecycle of human knowledge work

Human knowledge work has a lifecycle: exploring → collecting → thinking → creating → sharing. For example, I might explore ideas and information online, collect valuable insights and data into a note-taking app, use a whiteboard tool to think and organize my thoughts, then create content through a writing tool once my ideas take shape, and finally share the results back to the internet for others to explore.

The drawback to the process is that I’m constantly switching tools. The context of an idea is scattered across different tools, making it hard to trace and integrate. Humans have bad memories. An idea loses most of its meaning if I can’t remember the context behind it.

Heptabase helps knowledge workers bridge the gaps between different parts of the knowledge lifecycle and preserve the thinking context behind all ideas. The knowledge internet we’re building focuses on optimizing three dimensions: information interoperability, context retrieval, and collective knowledge creation.

Information Interoperability

To build a contextualized knowledge internet, the first step is to ensure that information across all stages of the lifecycle can be interoperable. Currently, the software world approaches this problem in two major ways.

The first approach is to increase the capabilities of a single piece of software. This is often done by packing many features into one tool (e.g., Notion), or by adding plugin systems that extend the tool for different use cases (e.g., Obsidian). While this can cover more use scenarios, it typically leads to a steep learning curve, reduced usability, and fragmented focus—making no single feature truly excellent. Additionally, endless plugin extensions can quickly become hard to manage and maintain.

The second approach is to integrate multiple tools through APIs (which may come from different apps or be natively provided by the file system). This is the most common approach to combining software capabilities today. However, it comes with high development and maintenance costs and requires many compromises in data format compatibility and synchronization. If integration is achieved by copying data between tools, it’s almost impossible to truly achieve the experience of “using one tool inside another.” But if multiple tools try to share a single database without a universal protocol, the risk of data corruption grows exponentially as the number of tools increases.

Do we really have to compromise between these two directions? After careful thought, I believe that to build the contextualized knowledge internet we envision, the system must follow three core principles:

  1. All software must share the same data format.

  2. All software must follow a universal protocol for data processing.

  3. Software should be as decoupled from data as possible, avoiding direct data ownership.

Heptabase is built on these three principles.

In the system I envision, all data are “cards.” Cards can be extended into many types: they can be notes, PDFs, videos, images, e-books, spreadsheets... these basic types, or compounds, gene sequences, drugs, algorithms... these special data objects in professional fields. All cards will use a universal data format to store their metadata, and all software on this system, which I call Meta Apps, will use a universal protocol to read and edit these metadata. In this way, each Meta App can maintain its own usability, while Heptabase, as the operating system that carries these Meta Apps and as the browser that opens Meta Apps and cards, can both ensure that data are universal among Meta Apps—eliminating the cost of connecting data between them—and decouple data and Meta Apps through the abstraction layer of metadata, allowing us to ensure that all Meta Apps share the same data format while greatly reducing the risk of data being corrupted by Meta App developers.

Context retrieval

To build a contextualized knowledge internet, the second step is to ensure that the thinking context behind all knowledge and ideas can be fully preserved and traced. When you see an idea, you should be able to find how it was created and in what context it was used.

For all human knowledge and ideas, there is always an input before there is an output. “Tracing the thinking context” helps us understand what kind of input leads to what kind of output. To achieve this goal, we must integrate the “collecting,” “thinking,” and “creating” stages of the knowledge lifecycle.

The principle of collecting is “fast.” Ideas are fleeting, and a good collecting tool should have very low friction and can capture ideas as they arise. In Heptabase, the Meta App responsible for this task is called Journal. You can pour ideas into it anytime without creating an actual note.

The Knowledge Lifecycle-2

Journal

The principle of thinking and creating is "visual." To clarify our thinking, we often have to visualize the big picture of our ideas. Moving and reorganizing information on visual space is a critical process to augment thinking. In Heptabase, the Meta App responsible for this task is called Whiteboard. You can pull out contents from Journal onto an infinity whiteboard space to create cards and arrange these cards to clarify your thinking structure. A card can appear on multiple whiteboards at the same time.

The Knowledge Lifecycle-3

Cards on a whiteboard

Journal and Whiteboard, as Meta Apps, do not own the data of cards. They read and reference the card database of Heptabase, and the only data they have is metadata for presenting cards. For example, Whiteboard does not own the cards’ contents but store the cards’ spatial attributes (shape, color, arrow) on different whiteboards.

This sharing of card databases ensures that each Meta App is not overly complex but is well integrated into a workflow, avoiding untraceable gaps between different stages of the knowledge lifecycle. When you see a card, you can trace when it was created, what other cards have mentioned it, what whiteboards it appears on, and its position in different mental frameworks.

The Knowledge Lifecycle-4

Shared Card Database

Collective knowledge creation

To build a contextualized knowledge internet, the final step is to let individual thinking interact and enable collective knowledge creation that can’t be done with any individual mind on their own. To achieve this goal, we must integrate the “sharing” and “exploring” stages of the knowledge lifecycle.

When it comes to collective intelligence, the examples that come to our mind are software like Notion and Miro, which put “shared workspace” and “real-time collaboration” in their value proposition. However, there are three main problems with such products that make collective intelligence difficult to emerge.

First, these shared workspaces force everyone in the team to use the same information architecture from the top-down, rather than letting everyone use the one that works for them.

Second, it’s easy to result in disorder when everyone’s thinking overlaps in the same workspace. It’s hard to know which documents are outdated and which are still in use. If many people have edited a document, it’s hard to trace why they edited it and the thinking context behind each editing.

Third, it’s easy to result in groupthink when entering real-time collaboration before the ideas from individuals get matured, which is terrible for independent thinking. For efficiency reasons, collaboration often takes a majority decision approach to develop ideas, resulting in an individual’s unique ideas being unexpressed and stifled early.

At Heptabase, we advocate bottom-up “asynchronous sharing” based on “personal workspace.” When knowledge workers want to collaborate, asynchronous sharing from a personal workspace allows them to track each other’s thinking clearer and reuse each other’s ideas and knowledge without disturbing anyone’s independent thinking process.

Instead of sharing an idea, we can share an entire thinking context that uses ideas as a unit. Every idea in each thinking context can be used by other thinking contexts. Heptabase’s context-tracing ability allows you to explore different thinking contexts behind any idea you see.

Summary

In short, from the perspective of “The lifecycle of human knowledge work,” we are building an ecosystem of tools to help knowledge workers integrate their knowledge lifecycle of exploring → collecting → thinking → creating → sharing. Our guiding principle is to optimize information interoperability, context retrieval, and collective knowledge creation, with the ultimate aim of evolving a contextualized knowledge internet.

In the next article, I will provide a detailed introduction to the structure of the Heptabase system, as well as the roadmap of our iterations for this system.