CleverMemory

Part 1 of Foundations, a series on the ideas behind CleverMemory, where they came from, and why each one matters.

If you have ever given an AI system a "memory," there is a good chance it worked like this: turn every document into an embedding (a list of numbers that places similar meanings near each other), turn the question into one too, and return whatever lands closest. That is vector retrieval, and for discovery it genuinely works. "Find material related to this" is a similarity problem, and embeddings are a very good tool for it.

The idea underneath them is older than the software and worth knowing, because it tells you exactly what embeddings are good for. In 1954 the linguist Zellig Harris published Distributional Structure, arguing that linguistics could be done as an empirical science: instead of asking a speaker what a word means, look at the company it keeps, and let the pattern of environments a word appears in stand as a description of it. John Rupert Firth put the same instinct more memorably a few years later ("you shall know a word by the company it keeps"), and for decades it stayed a claim about method rather than a thing you could compute.

Then it became a training objective. word2vec and the encoders after it are Harris's hypothesis at scale, and they work remarkably well, which is a real vindication of a seventy-year-old argument.

But notice what the hypothesis actually promised. It says distribution is a good guide to what a word is like. It never claimed distribution settles what a particular sentence asserts. Harris was describing vocabulary, not adjudicating claims, and a system that treats proximity in that space as evidence for an answer has extended his argument past where he took it.

Now ask a memory question instead, something like "when does my contract renew?" and the requirement changes: related passages are candidates, but the renewal claim still needs support.

Three things similarity alone does not guarantee#

An embedding compresses language into a space where proximity usually means relatedness. A model may encode the distinctions below, but a nearest-neighbor result does not make them explicit or prove that they were preserved.

Polarity renewal date is March 3rd renewal date is not March 3rd nearby in vector space same topic, opposite claims Similar as vectors. Opposite as claims. Direction Alice reports to Bob Bob reports to Alice Alice Bob same words, opposite edges Direction carries the claim. Similarity does not prove it. Absence when does my contract renew? nearest item question nearest does not mean sufficient Retrieval still needs a rule for insufficient evidence.
Similarity helps find related material. By itself, it does not test polarity, relationship direction, or whether the corpus actually supports an answer.

The first is polarity: whether a sentence asserts something or denies it. "The renewal date is March 3rd" and "the renewal date is not March 3rd" share nearly all of their language. A good encoder may notice the negation, but proximity alone is not a dependable contradiction check.

That is not a hunch. Allyson Ettinger's psycholinguistic diagnostics for language models probed BERT with tests borrowed from human sentence-processing research and found it handled several of them respectably while showing clear insensitivity to the effects of negation. Give it "a robin is not a" and it will happily predict bird.

It is worth being precise about what that does and does not show. It is one model family, one probing suite, and encoders have moved on since. The durable lesson is not "models cannot do negation." It is that fluency and polarity are separable, that a system can be extremely good at the first while quietly failing the second, and that nothing about a similarity score will tell you which one you are looking at. If a distinction matters to your answer, something has to represent it rather than hope it survived the embedding.

The second is direction. "Alice reports to Bob" and "Bob reports to Alice" use the same words while asserting opposite reporting relationships. Their vectors may differ; the ranking still does not constitute evidence for which direction was asserted.

The third is absence. A nearest-neighbor lookup, which returns the stored item whose numbers sit closest to the question's, returns the nearest candidate even when the corpus contains no answer at all. Production retrieval systems can add thresholds, rerankers, and abstention policies, but those are additional decisions; distance alone does not establish that the evidence is sufficient.

A different role for memory#

CleverMemory's design makes these distinctions explicit: entities, directed relationships, polarity, time, and where a passage sat in its source document are all represented as part of a record. We call the result a Temporal Evidence Graph, which is a customer-facing name for a set of behaviors rather than a data structure I am going to describe here. The behaviors are what matter: a question such as "Who reports to Bob?" should be answered only when the stored evidence supports the relevant relationship, and the answer should be able to point back at the passage that established it. That is the design target. The principle came first, and the measurements will follow when the controlled runs are ready.

Embeddings still have a valuable role in finding candidate places to look and in associative language work. Before somebody acts on an answer, the system needs evidence for the claim being made. Trouble starts when related text is treated as if it were already a verified answer.

The rest of this series digs into what "meaning as structure" requires if you take it seriously. What a question really is (part 2). The math of honestly saying "I don't know" (part 3). Events and roles (part 4). The word "might" (part 5). Time (part 6). Citations as algebra (part 7). Where a passage sat on the page (part 8). How those literatures relate to one another (part 9). And the public data that makes all of it possible (part 10).

A word about what this series is and is not. Each part is a real research area with decades of work behind it, and I will give you the primary sources so you can go read them yourself. Where the series stops is at our own implementation. One part of CleverMemory stays ours: the code and data that tie everything together. That piece is not public; everything you need to check what it tells you is, and I have tried to make the series worth reading on the public material alone. The genuinely hard parts of this problem are in the open literature, and most of what I know about them I learned there.

The project is built around a stricter role for memory: preserve what the source supports, expose the evidence, and abstain when that support is missing.

If that role sounds right to you, the natural next question is the one part 2 takes up: if related text is not an answer, what was the question actually asking for? Logicians have had a surprisingly practical answer since 1973.

Follow the project

Get one email when the first public release is ready, and first notice when the invitation-only demo opens. Nothing else. If you would rather talk before then, a technical briefing goes deeper than this site does and is the fastest way to test whether the approach fits your workflow.

One release notice and one demo notice only. See the privacy policy.