Thread is a User's Personal Database
Part 1 of 4
Ambient Intelligence Index, at its core, is a database. It has 3 parts: Sewn, Thread, Seam. The Thread is the actual database layer, and around it Sewn and Seam provide the machinery to connect it to application layers and other databases, and to consolidate machine learning APIs for inference using the database contents as context. In this part of the series we will focus on Thread, and will cover Sewn and Seam in Part 2, Sewn & Sinatra Personalizes Your A.I.
Thread's Road to AII
Thread is meant to be a type of storage solution that stores data to prepare it for knowledge graph and vector store retrieval. Vector stores are how Thread started. Actually, Thread has a longer history: it started from Seer. I started in October-November 2025, when I set out to solve the royalty/attribution issue with retrieval. While doing so I wanted to tackle augmenting generated responses as a whole. 2 key things: this idea of an infinite chat, and tuning a response towards a user via some form of self reinforcement learning. Another case of wanting to solve multiple birds with 1 stone, seen in The Path Towards 'Fair Use' in Generative A.I., when dealing with 'fair use' capable language models.
In this process, Seer evolved into a dynamic of personalization I found could make a Mistral Medium model as valuable as a state of the art OpenAI model. And it wasn't due to factual recall, because that was being supplemented by how I was aggregating data into Thread from social sites like Bluesky. It was due to its ability to connect the dots across my notes and other nodes.
I had hosted Seer on Scaleway and implemented a rudimentary HNSW, Hierarchical Navigable Small World, that essentially places the vector representations of the data onto a graph that can be traveled to find related pieces with ease. A design I might bring back, but its difficulty in maintenance kept it out for the time being. It was very insightful though, so I will talk about it briefly before entering the current state of Thread, as the core PartitionTable storage format remained throughout the development timeline.
Embeddings are vector representations of text: each word or passage becomes a list of numbers, one per dimension. There can be hundreds or thousands of them, but we often picture them in three, x, y and z, to make the space something we can see. I started with NLP in 2016, working with emotion lexicons to derive the emotional cadence of a user's message history and what they typed to a chatbot. Along the way I discovered GloVe, and with it the idea, long studied in its own right, that words have measurable similarity to other words. If you picture words in a 3D world, you can travel through it and find a real distance between them that means something: a number for how close two words are in meaning and relation.
Text embeddings carried that idea from words to whole passages, and HNSW built on it. Where word vectors relate one word to another, an embedding model places an entire passage in the same kind of space, and HNSW links each one to its nearest neighbors, across themes and across documents. Because of how I structured partitions within a document, it could take one partition of a document and relate it directly to partitions of another.
It gave me this idea of mutual thoughts, where 2 essays can be about entirely different things, but a paragraph or phrase in each is related, connected together in a navigable small world. The power was in seeing how shared perspectives can exist in entirely different posts. Ultimately a bridge being built between two different viewpoints, finding the same thing they both wanted deep down.
The trouble with HNSW was keeping the graph consistent as nodes and their documents came and went. An insert linked in place, but a delete only marked the node: its text and vector stayed in the graph, with links still pointing at it, until a compaction rebuilt the whole thing. I wanted Seer, Thread and AII to put privacy and security first, so I retired HNSW. Balancing reliability, dangling nodes and data consistency at scale was an engineering feat of its own, and I was building many other moving parts at the same time. It's worth bringing back, and from a server-reliability perspective it was an interesting problem.
I had built a scraping service that connected to Bluesky and RSS feeds, pulled posts hourly, and filed them into the index automatically under fixed service accounts, labeled Bluesky and so on. When those posts were used in context retrieval, their accounts were credited with royalties, to demonstrate fair use at the retrieval layer.
It was while building this credibility layer that I found the idea of personalization that felt magical. I could see that an LLM response was 60% Bluesky, tap into that account, and see the actual Bluesky posts, the actual people, behind the response. It was like stitching life together: the LLM was sewing threads together rather than being the entire source of truth. It also seemed like a guard against AI-induced delusion. Seeing the actual people behind the words, in a digestible way, gave me something to verify rather than a black box to trust, one that could lead you down the wrong path, sometimes on purpose.
In a way, seeing these accounts as contributors to what an LLM was stitching together gave weight to a line I kept coming back to: "decentralized intelligence centralizes progress for the whole." What if peer-to-peer ideas were involved? What if multiple Seer servers could spawn and connect to each other? This is where one stone and many birds re-entered my development lifecycle. Not only could we solve attribution through retrieval, but we could make users feel they truly own their data in the process. The engineering to maintain all of this would grow, testing my ability to keep the architecture coherent, so it was time to divide and conquer. I split the stack in half: the database was clearly its own product, and so was the service layer, which exposed the REST API, called the LLM APIs and prepared retrieval.
I installed Ubuntu on a desktop I had, got Swift compiling on Linux with MLX so I could run on-device embedding models and LLMs for summarization, and placed a Thread on it. I downloaded arXiv's full dataset and wrote scripts to extract authors and entities, create groups, and ingest it into the Thread automatically. Then I had Seer connect to the Thread over the local network, via gRPC, to handle retrieval. It proved the approach viable: users would host their own Threads with their own data, and a mothership server would sew those Threads together for a front end like Ambient.
Current State
Now, Thread is back in the mix, a part of Ambient Intelligence Index, which organizes the three parts: Sewn, Thread, and Seam (the gRPC). A coherent stack that enables anyone's machine to store their personal data and serve it to their personal applications, personalizing their interactions over time and preparing their machine to connect with others in the future with ease. I like to say AII is the beginning of a new railroad and Rao's role is building the Union Pacific.
Today, Thread is a knowledge graph of entities and relationships, kept beside a compressed vector for every partition. HNSW is retired for now, so there are two ways to search. A similarity search compares a query with the partitions in a user's own documents. A knowledge-graph query matches entities and relationships and walks the graph, so what it returns is decided by the entities set at the document level, not by a score. That matters because a user can have millions of partitions: the graph narrows them to a set of documents, and the vector search runs only on that set.
Groups and tags narrow it further. A group is like a folder, and each document is filed in one. Tags are labels a document can carry many of, and each is filed as an entity in the graph, so naming a tag in a query finds its documents through the graph. A user can pick groups, name tags and entities, and run a vector search over what's left to find similar ideas. That builds the context for an LLM request personalized to them, or simply recalls a memory: reminding the user of a note from the past that is relevant again today, one of Ambient's primary use cases. In a way entities and tags are interchangeable concepts.
In practice, tags have taken over much of what groups were for, since a document can carry many and the graph finds them by name, but both are kept: a group is still the one place a document is filed, and a search can name it directly. The premise of groups early on was creating an aggregated location for a user or owner to indicate whether it should remain available or restricted, so when another user requests context from that user, they can indicate which documents are okay to search and which are not. A privacy rooted feature, which is still maintained, and Ambient will soon reflect it in the UI.
PartitionIndex
The partition index is the in-code representation of a document. I find this to be the key cornerstone behind Thread's invention and what blooms into what Sewn, Thread, and Seam express through AII. In life, there is always that 1 small piece of a puzzle that actually makes a larger picture sing, and the PartitionIndex with its Quantizer help write the lyrics.
It started from Computational Photography and how filters are applied to photos to create new variations. The same filters you use on Instagram or other platforms; back in the day there was VSCO. A lookup table is like a direct translation of something into something else. A picture can be viewed as a literal representation of 1000 words, a grid of numbers that reflect RGB values or pixels, actual colors in numerical form. When a lookup table is applied on top, it transforms each pixel into another destination, creating an edited and filtered outcome. I like to think of a pin board, where the pins on each board resemble a concept or thought in a partition that we need to raise in order to retrieve effectively, the height of the pin resembling the concept of distance and its relation to similarity between words I was referencing earlier in this essay.
Prior to the current implementation, and an idea that will soon return for completion, each user's Thread actually has a pin board representation of their entire personalization layer: a large table that describes everything that is stored in their Thread, rather than one for each document. This is where the efficiency of LUTs comes in: created from a query, they can mask irrelevant partitions quickly and retrieve relevant items, "cutting out" things for a quick O(1) lookup. In this case, the knowledge graph route may not even be necessary, unless an effective way to create pin boards of entities/tags/groups overall proves better than one for the entire database. So that will still be in R&D for now, eventually becoming proof for a provisional patent I have filed for this approach in document storage for the AI-Native engineers entering macOS and iOS environments for the first time.
In order to make these submitted documents compatible with the pin board metaphor though, we need to train the embedding vectors that represent the document and its partitions. Train them into a codebook. A codebook that is the converted representation of the partition's larger embedding's placement for each row in a 2-Dimensional array.
The codebook can store billions of entries at the moment for each document, so it seems a bit inefficient if one were to look directly into the code. But that's because the original intention was for it to represent all of the documents for a user's lifetime rather than 1 document only, so it can potentially take 2 paths from here. Either the size limit is reduced to fit the document's exact needs upon ingestion, which is tough, because then the document id is constrained for modifications: new edits need to dynamically update the codebook size, which could be costly, costing an entire retrain operation for the compressed embedding approach. And the benefit of the compressed embedding approach is not requiring thousands of 1024 dimensional embeddings kept in a machine's memory at all times for similarity search. 16 UInt16 codes, 32 bytes, not 384 of them (which was in the HNSW days of Seer). Which was still not a 1,024-d vector, as that is cut into 16 slices of 64 numbers, and each slice keeps one UInt16 naming its nearest notch.
In the end a user begins to have this personal database that stores their data on their machine, prepared for personalization, while running on-device models to generate entities and relationships on the fly. Connecting their life's dots that sprouted from a Macintosh. Enabling a search for them to find things in the past they forgot, or see things in the present from a different perspective. That's the power of databases: it's not just storage, it's more than that. At times it can be one's entire life condensed into a folder. An entire life that only you should have access to and only you are allowed to read from. That's what Rao is meant to do. That's my role.
P.S.
I was thinking of this song while writing this, so I will make it the theme for this part of the series.
Privacy is important, not because people are trying to hide something. But because there are some things that are only meant for our eyes to see and remember. And the motivation and inspiration that blooms from those things reduce in value when unwarranted eyes look at those things. It's dehumanizing in its own way. Rao aims to never let that happen to anyone else through AII.