Five Percent of the Job

Last October I published a piece about BeMo's Knowledge Base, the layer meant to hold what an organization understands about itself: its mission, its voice, its reasoning, the things that are true about it. I have been going back through the record I put out while we were building BeMo, checking each claim against what building it actually taught. This is the edition where the miss was structural rather than verbal, and where I can point at the exact sentence that gave it away.

What I claimed

The essay's argument was that most knowledge systems store information and lose meaning. I was hard on the incumbents on exactly this point: traditional tools "succeed at storage but struggle with relevance," and "they manage pages, not meaning." BeMo's answer would be different. Knowledge would be held as meaning rather than as filing, and it would flow into the work instead of sitting in a folder.

The mechanism I described was fragments. "A first-time user logging on to the BeMo app can add key elements such as their mission, tone, leadership bios, values, and communication style. Behind the scenes, each of these is stored as a tagged fragment, not a static page." Fragments would be semantically linked, retrieved by meaning rather than exact words, and pulled into whatever the organization was making.

And here is the sentence. The section was titled "Knowledge as Inputs to Work," and it began: "Information in the Knowledge Base becomes inputs to the documents, deliverables and strategy recommendations created across all BeMo apps."

Inputs. To the software.

What held

The strongest claim in that essay survived intact, and it is the one the whole design now rests on: "Knowledge evolves through use, not maintenance."

That sentence is close to verbatim in our current internal canon, which says memory accrues as a byproduct of conversations, documents, and imports, and that any design making the knowledge base a destination requiring effort repeats the failure mode of every prior version. It is now a rule we reject proposals against. If a feature asks a nonprofit to sit down and populate something, it does not ship. Score it: held, and load-bearing.

The retrieval claim held too. Ask BeMo "what's our purpose" when the record says "mission" and it still finds it. That was real then and it is shipped now.

The diagnosis held as well, which is the least surprising part. Mission statements do hide in brand decks. Messaging guidelines do sit in forgotten folders. None of that needed revising.

The miss

Read the essay again with one question in mind, and it falls apart in a specific way: who is this for?

Thirteen sections. Exactly one of them is about the interface a human being touches, and even that one routes the human through the machine. Its headline feature was that you could talk to it. Everything else describes a system whose purpose is to be consumed: fragments made ingestible, context made available to templates and workflows, knowledge flowing into outputs. I had written an essay about organizational memory in which the organization is not the reader.

That is not a wording problem. We built what the essay described. The Knowledge Base was rebuilt five times over roughly two years, and every rebuild optimized for one consumer and quietly broke the others: the model, then onboarding, then document interviews, then file extraction. Each was a coherent system. None of them was for the person whose organization it described. Getting the consumer wrong at the foundation is not a mistake you patch. It is a mistake you rebuild through, repeatedly, without understanding why the ground keeps moving.

The number I keep coming back to is that feeding the software was maybe five percent of the job. It was the five percent I designed the whole thing around.

What made it obvious

The thing that finally surfaced it was our own knowledge base, which we had built for ourselves without noticing it was the counterexample.

BeMo's company knowledge lives in a library of plain prose documents with an index at the front that says what to read for which job. Nothing about it is clever. It is written for a reader who was not there. Two things are true about it that were not true about what we were shipping: an AI reading it reaches useful competence in minutes, and so does a person. Same artifact, both readers, no translation layer between them.

We had convinced ourselves those were different jobs requiring different structures. They are not. The unit that serves a human well, a well-written document that stands on its own, is also the unit that serves a model well, and the fragment optimized for ingestion serves the model marginally better while serving the human not at all. We had traded the entire human half of the product for a retrieval improvement.

So the definition got rewritten, and this time written down so it stops moving: the Knowledge Base is not an AI context store that users happen to see, it is the organization's system of record that the AI happens to read. The organization is the primary customer. The model is a reader.

Three rules came out of that, and they are the ones I would defend hardest. Every item has to answer "how do I know this," and the answer gets shown to the user, not just stored. AI proposes and a human confirms, so nothing in the confirmed layer is something BeMo invented. And the whole thing has to pass a test we wrote as a kill switch: users can see it, correct it, own it, and take it with them. A knowledge base that fails those is an internal cache wearing a product costume, and it should not be a product surface at all.

The page I argued against

The part I find hardest to write is that the answer turned out to be the thing I was dismissive of.

I wrote that traditional knowledge tools "manage pages, not meaning." The design we settled on this summer is a page. Not the folder-and-file version I was criticizing, and the meaning still lives underneath in structure. But the form a human meets it in, the thing you land on when you want to know what your organization knows about a funder, is a page about that funder, written to be read. My own essay had described the interface as looking "much like a structured wiki or content library" and then spent every other section explaining why the real work was happening somewhere the user could not see. The interface I mentioned in passing was the product.

One honest caveat, because it is the hard part and not a detail: our own document library works because the two people maintaining it are practiced systematizers who enjoy writing things down. No nonprofit is going to hand-author that, and asking them to would violate the one claim from the original essay that held. So the work is not building a place for documents. It is being the ghostwriter and the librarian while the organization stays editor-in-chief, which is a much harder product than the one I wrote about last October.

What I have not shipped

In the spirit of the scorecard: that essay described a permission model with a personal space and a shared organizational space, written in the present tense as though both existed.

Today every item in the Knowledge Base is personal-scope. Organizational scope ships with seats, permissions, and the rest of the team capabilities, as one set, because releasing shared memory before we can govern it would be selling infrastructure we cannot yet stand behind. That has been a deliberate hold since May. I would rather say that plainly than let a year-old article keep describing a product state that is not real.

What changed in BeMo

In one sentence, the delta: I built the Knowledge Base as something for the software to read, and building it taught us that the software was about five percent of the job, while the other ninety-five is a person being able to see what the system believes about their organization, where each belief came from, and correct it.

Then: knowledge as inputs to work. Now: knowledge as the organization's own record, which the software is merely allowed to read.

What I got right was that knowledge has to accrue from real work instead of being maintained. What I got wrong was who the whole thing was for, and that error was underneath everything else, which is why it cost five rebuilds to find.