The Foundation, Not the Product

Last October I published a piece about BeMo Drive that made a confident claim: this was "not just cloud storage" but "a dynamic memory system." I've been going back through everything I published while we were building, checking it against what months of beta have taught. Some claims survived. This one earns a split score, and the half that failed taught us more than the half that held.

What I claimed

The October piece described a storage layer that kept the familiar shape of files and folders but indexed what the file system never could: the relationships. A grant proposal would know the strategy it served. A press release would know the campaign that produced it. Documents, structured data, and the conversations that shaped them would live in one place, connected, so an organization could trace its own reasoning: why a decision was made, which discussion shaped which draft, what informed what.

The promise underneath was continuity. Programs outlast roles. Documents persist, but the reasoning behind them walks out the door. Build the memory system, I argued, and the organization stops losing what it knows.

The half that held

The diagnosis aged well. I wrote then that traditional storage "remembers what was created, but not why," and every month of beta conversations has confirmed it. Nonprofit leaders tell us versions of the same sentence over and over. One kept everything relevant to funding in a folder called "grant stuff" and assembled each application by copying and pasting from the pile. The information was all there. The reasoning was reconstructed by hand, every time.

That problem is real, it is chronic, and naming it correctly still matters. Nothing in the beta made me doubt the diagnosis.

The half that didn't

We built the system the piece described. Documents, data, and conversations, stored with their relationships intact. The write path worked: things went in, and they went in connected.

Then we asked our most engaged beta tester to score how well the system surfaced what it knew at the moment she needed it. Four out of ten. For a platform whose entire thesis is memory, that number needs to be a nine.

Here is what four out of ten looks like in practice. She knew the information was in the system, because she had put it there. The system knew it too, in the sense that a warehouse knows its inventory. But at the moment of work, drafting the board update, answering the funder question, deciding what comes next, the memory mostly stayed where it was. Retrieving it took a deliberate trip: go look, search again, re-find. The archive was complete. The altitude was missing.

The mechanism of the miss

The engineering explanation is uncomfortable because of what it says about where we put our attention. We invested heavily in the write path: capture everything, connect everything, lose nothing. We underinvested in the read path: surface the right piece of memory inside the work that is happening right now, without being asked twice.

I had been thinking of memory as a destination. You visit the archive, you consult it, you leave with what you need. But work does not visit destinations. Work is a stream of moments, each with a small window where the right piece of context changes the outcome, and a person under deadline does not stop to make a trip. Memory that requires a trip is memory that does not get used, which is functionally the same as memory that does not exist.

The unit of value was never the stored item. It is the moment of surfacing. An organization's memory is only real at the moment it changes what someone does next.

What changed

The measure changed first. We stopped grading ourselves on "did we keep it" and started grading on "did it show up when it mattered." Those produce very different engineering priorities. The first rewards completeness: more captured, more connected, more retained. The second rewards timing and relevance: the right fragment, in the work, at the moment of need, with no trip required.

The rebuild against that measure is underway. I'll write about its specifics when they have survived contact with users, which is the standard this series exists to enforce.

The claim I would write today is smaller and harder than the one I wrote in October: storage is not memory in use. A system that remembers everything has done the easy half. The hard half is being a participant in the work instead of a destination beside it.

Last fall I thought memory was the product. It turned out to be the foundation.