A Second Brain, built around your work

LH Digital builds Second Brains using the LH BRAIN method: Baseline, Repository, Automatic capture, Intelligent recall and Nurture. Obsidian is our main workspace, with agreed connections and an AI assistant where they serve the work.

The aim is not to collect everything or add AI everywhere. It is to organize the knowledge your work depends on, put it to use in a defined task and leave your team able to check and maintain the system.

Obsidian is the main workspace we use to organize your Second Brain. It brings notes, reference material and written instructions into a structure built around your work.

We use it because the underlying notes remain yours to inspect, edit and keep. Obsidian stores them as plain-text Markdown files in a folder called a vault. Markdown supports simple formatting, such as headings, lists and links, and the files can be opened in other applications.

LH BRAIN is the method; Obsidian is the workspace. The method determines what belongs in the system, how it is organized, what is captured and who keeps it current.

Automatic capture and AI recall are configured around that workspace. Before the build, we identify the connections and services needed, what information they can access and what they cost.

Obsidian stores notes locally, but synchronization and connected services can create or process copies elsewhere. We agree on storage, access, synchronization and backups as part of the design. Local files do not mean that the whole system stays on one device.

If your team already works in another tool

We recommend Obsidian, and the method does not depend on it. Where a team already relies on another tool, we can build from that instead. We ask the same question of any tool: can you inspect your notes, keep them and take them with you.

Tools change. We confirm current features, storage and costs with you before the build.

Tiago Forte set out his approach in Building a Second Brain. It includes CODE for working with information and PARA for organizing it.

We draw on these principles. LH Digital is not affiliated with Forte Labs. The LH BRAIN method is our own approach to assessment, implementation and handoff.

CODE: turning information into useful work

CODE describes four steps:

• Capture: Save information worth returning to.
• Organize: Put it where it supports the work you need to do.
• Distill: Identify the essential points so they are easier to use later.
• Express: Use what you have collected to make, decide or deliver something.

The purpose is not simply to build a collection. It is to make the information useful in the work you do.

PARA: giving the material a clear home

PARA organizes material into four categories:

These categories distinguish current projects from ongoing responsibilities, reference material and completed work.

PARA is not an alternative to a folder hierarchy. It is a way to decide what that hierarchy is organized around. Rather than asking only “What subject is this about?”, it asks “What work does this support?”

We apply that principle to the work in front of us. The structure should make sense to the people using it.

Before we build, we map the knowledge the system needs to hold: what it is, where it lives, who uses it and which decisions it supports.

We then design the structure around the work. That includes where material is saved, how related notes are connected, what is captured automatically, who can access it and how it will be reviewed.

Here, modeling means designing the knowledge structure, not training an AI model.

We write down the proposed structure and agree on it with you before the build begins. It guides the scope and is updated to reflect what we hand over.

Every Second Brain we build follows five steps.

1. Baseline. We review what you know today and where it lives: notes, files, inboxes, records and the tools you use to manage them. We also look at what you need to find, decide or produce.You receive a short written assessment and a plan for the build.
2. Repository. We organize your material in Obsidian, around the work you need to do. There are clear places for active projects, ongoing responsibilities, reference material and completed work.You have a structure for saving and finding information, with instructions the people using it can follow.
3. Automatic capture. We connect agreed sources so selected notes, files and decisions can be saved as part of the work.You know what is captured automatically, where it goes and what still needs to be added by hand. We also identify what needs review before it becomes an approved source.
4. Intelligent recall. We set up an assistant to help you find answers in approved material, within the permissions and rules you agree to.You ask in plain language and can inspect the source material used in a response. The assistant is a way into the archive, not a replacement for the archive or for your judgment.
5. Nurture. Each part gets a named owner and a review date. We hand over a routine for checking what has changed, correcting outdated material and keeping the system current.You know who is responsible for the information and how to suggest or approve a change.

Before an assistant can work usefully with your knowledge, you need to know what it should rely on. That means identifying the relevant information, checking its quality and deciding who may access it. These are important parts of preparing organizational information for AI.

We begin with practical questions:

• Which information is current, and which is a draft or an old version?
• Who can confirm that it is correct?
• What may the assistant read, and what must stay out of reach?
• Which task is worth helping with?
• Who will check the result?

Not every file needs to be cleaned up before you begin. We focus on the material needed for the first agreed use and identify gaps that would make that use unreliable.

An organized archive is a starting point, not proof that the system is ready. Finding a relevant passage does not establish that it is authoritative, complete or suitable for the decision in hand.

We start with one defined task rather than a general promise to transform the business.

That might mean finding an operating instruction, preparing a weekly update or drafting from approved reference material. We agree on the sources, permissions, expected result and review step before connecting the assistant.

We then test representative questions and tasks, including cases where information is missing or conflicting. The purpose is to see where the system helps, where it needs correction and when it should stop for a person.

An example: preparing a weekly client update

Consider a small building firm whose owner gathers job notes, checks decisions and writes a client update each Friday. This is an illustrative workflow, not a client result.

The assistant has a limited job: prepare a draft from agreed information. It does not decide what the firm promises the client.

The value is not only in getting an answer today. It is in keeping useful work available for the next task.

A checked research summary can support a proposal. An approved process can support staff training. A project record can provide context for a later decision. Instead of assembling the same background each time, the team has material it can inspect, update and use again.

That depends on care. New information needs a place, outdated instructions need attention and changes need an owner. Ongoing data quality and governance remain important after AI is introduced, not just before it.

Nurture makes that responsibility explicit. Your team receives a routine for reviewing the material and checking whether the assistant still serves the task. If the work changes, the sources, permissions and tests may need to change with it.

The aim is not to make every process automatic. It is to reduce repeated preparation while keeping responsibility clear.

Saving information does not necessarily make it easy to use. A long note may contain an important point without making that point easy to find again.

Progressive Summarization, developed by Forte, adds selective layers to a note: mark important passages, highlight the most useful points and, where helpful, write a short summary. The underlying material remains available for context. Not every note needs every layer.

For example, several pages of client-intake notes might contain observations about repeated data entry, missing information and unclear responsibilities. You could mark the relevant passages, highlight the changes worth considering and add a short summary when planning the work.

Where useful, we incorporate this approach into the review routine. The aim is not to summarize everything. It is to make frequently used material easier to understand without losing its context.

Forte uses the term “intermediate packets” for tangible pieces of a larger project. An outline, research summary, diagram or draft section can be reviewed on its own, combined with other pieces or reused later.

“Research funders” is a task. “A comparison of five funders, with requirements and source links” is an output someone can inspect and build on.

For example:

A Second Brain gives these pieces a clear home, with their sources, status and related project.

An assistant can help you ask questions across approved material and prepare summaries, outlines and drafts.

Retrieval-augmented generation, often called RAG, is one way to do this. The system retrieves relevant material from a collection and supplies it to the model when it answers. This is different from training the model on the archive.

It is also different from a chat product’s memory feature, which may carry selected information from earlier conversations into later ones.

For this work, the approved archive remains the reference. The assistant helps you use it.

It can still misunderstand a question, retrieve an unsuitable passage or produce an unsupported answer. A source link gives you something to check; it does not establish that the answer is correct.

The review step remains part of the work.

For one person

The system brings notes, ideas, research and working knowledge into a manageable structure. It is built around the founder’s projects and responsibilities, with a routine they can maintain.

The Second Brain line on Services

For a team

The system organizes shared knowledge so routine questions do not always depend on finding the right colleague. Ownership, review dates and written instructions make it clear which information to use and who can change it.

The Second Brain line on Services

For a practice

A practice build begins with the clinical Knowledge Core Assessment. Before records are connected, your licensed advisors approve how they may be handled, and we agree on access, privacy safeguards and clinical review.

Using Obsidian or storing files locally does not, by itself, establish that a system is suitable for patient information. The proposed arrangement must be reviewed as a whole, including synchronization, backups, connected services and any AI provider. Where HIPAA applies, required agreements and safeguards must be in place before the covered work begins.

The assistant supports agreed drafting and preparation tasks. It does not diagnose.

Your vault and its contents stay under your control. Any separate services, accounts and subscriptions are identified and agreed before the build.

At handoff, you keep:

• The organized vault and its contents.
• The documented structure.
• Written operating instructions.
• A record of the agreed connections and capture routines.
• Instructions for using and checking the assistant.
• Named owners, review dates and the maintenance routine.

Obsidian’s plain-text format means your notes remain accessible outside the application. Connected services may still require their own subscriptions or ongoing maintenance, which we identify as part of the engagement.

Our aim is to leave you with something you can understand and run, not something that only works while we are there.

A Second Brain begins with Baseline: a review of what you know, where it lives and what you need the system to help you do.

You receive a written assessment and a plan for the build. The structure, connections and review requirements are agreed before implementation begins.