The Note Has No Schema

In 1968, Lawrence Weed published a paper in the New England Journal of Medicine that made doctors uncomfortable. He argued that the medical record, the document at the center of patient care, was organized wrong.

At the time, hospitals kept records by source. The physician's notes in one section, x-rays filed elsewhere, lab results in another pile, nursing notes somewhere else. If a patient had chest pain and hypertension and a history of kidney disease, the history of each problem was scattered across the chart. A physician seeing the patient at 3am had to reconstruct the story from fragments.

Weed said the problem wasn't the content — it was the primitive. Organizing by source meant the record served the hospital's filing system, not the physician's thinking. The right unit wasn't the source but the problem. For each problem: what the patient reports (Subjective), what's measurable (Objective), what it means (Assessment), what to do (Plan). The SOAP note was born.

That was fifty-seven years ago.

The generic note

The default unit in every PKM tool is a blob of text with a timestamp. Call it a note, a page, a card, a block. They're functionally the same thing. You type words in. The words go somewhere. You try to find them later.

The note has no schema. It doesn't know what kind of thing it is. A decision, a preference, a contact record, a meeting summary, a passing observation — the note treats all of these the same way: as prose.

Different kinds of knowledge have completely different shapes.

A decision needs context (why was this being decided?), alternatives (what else was considered?), rationale (why this one?), and status (still standing, or superseded?). In 2011, Michael Nygard proposed Architecture Decision Records for software teams, the same basic insight Weed had about medical records. The format matters because without it, you'll spend years relitigating choices with no record of what you already considered. "We decided to use PostgreSQL" is a conclusion. An ADR is a decision record. Those are not the same thing.

A contact record has a different shape again: relationship type, communication preferences, last-interaction date, what you've learned about a person over time. An address book entry gives you a phone number. A person record gives you context. A "note about Kari" halfway down a document captures neither cleanly.

Preferences are different still. Not made once but drifting, with varying degrees of confidence. You know some things about yourself precisely and other things tentatively. A preference record should carry source, confidence, and probably a timestamp for when it was last verified. None of that fits in a note field.

The problem with folders

The standard PKM response to all of this is folders and tags: organize notes by type, which is a workaround for having no types. The structure lives outside the knowledge, in the filing system rather than in the record itself.

Weed's insight was that the structure should be in the record. The SOAP format doesn't mean you write only four fields. Physicians still write prose. It means the four-field structure organizes the encounter, and the prose fills in what the structure can't capture.

Harbor's dual-layer model tries to work the same way. A person record is backed by a database row and a Markdown document in the same file. Structured fields in one section; narrative notes about the last conversation in the next. Structure doesn't replace prose. It gives prose a context that makes it retrievable.

An AI trying to answer "what do I know about this person?" needs both. The structured fields give it anchors; the prose gives it texture. A note alone gives it neither reliably.

The open question

How many primitives are enough? Weed needed one (the problem) with four sub-elements. Nygard needed five fields. Harbor has people, tasks, projects, preferences, and documents. That feels approximately right for how a lot of people work, but "approximately right" is doing real work in that sentence.

The honest version of this argument is that every domain has its own natural shape, and any general-purpose knowledge system is making compromises. A lawyer's knowledge about a case doesn't fit neatly into "people" and "tasks." A scientist's knowledge about an experiment wants something closer to what Florence Nightingale built in 1858: observations, conditions, uncertainty, methodology. No consumer PKM tool currently offers that.

Typed entities are better than untyped notes. That much is defensible. Whether the right types are the ones any given tool ships with — that's the question most tools are still pretending isn't a question.

---

Asgeir Albretsen is the founder of Harbor.