ingest

Ingest takes material that exists outside the graph — an existing code repository, an uploaded media file, a Claude.ai conversation export — and turns it into entries inside the graph. Once it's in, it reads the same as anything a session wrote live: searchable, linkable, part of the same substrate.

That matters most for the repository case. A codebase a team has been building for years carries structure a fresh session has no way to know about on turn one. Ingest puts that structure in front of it, instead of leaving the session to rediscover the shape of the repo from scratch every time.

Run ingest against a repository and what comes out the other side is more than a pile of file contents. The files themselves are in the graph, but so is their structure — how the repo is organized, what depends on what — and the relationships between pieces, so a session can ask about the shape of a codebase and get an answer instead of having to walk the directory tree itself.

A media upload or a conversation export lands the same way: as entries a session can search and link against, not as a file sitting untouched in a folder waiting to be opened.

The first end-to-end proof of the ingestion pipeline wasn't a synthetic fixture built to make the demo work. It was gin-gonic/gin, a real public Go repository, walked through ingest start to finish (#6228).

Two real bugs surfaced during that run, and both got fixed: a clustering bug in the repo-resolution step, and a density bug in how the scanner weighted .rst documentation files. A fixture built to make a demo work doesn't turn up bugs like that; a real repository run through the pipeline does. A third finding — no automatic trigger yet for ingesting a fresh project — got logged as a gap rather than quietly patched over (#6228).

Ingest was confirmed built end to end with privacy as a structural property, not a promise layered on afterward. The raw repository is never stored on the server. The clone made to run ingestion is ephemeral — created, used, discarded — and the embeddings built from it are computed locally rather than sent off for someone else to compute (#5876).

None of that is hosted-only convenience. The whole pipeline is self-hostable, so trusting a server with your raw source was never part of the design in the first place (#5876).

gin-gonic/gin is a real, public Go repository, and running it through the pipeline surfaced two genuine bugs — a clustering bug in repo resolution, a density bug in .rst file weighting — both fixed, plus one honestly logged gap: no automatic trigger yet for a fresh project (#6228). Separately, the pipeline's privacy architecture was confirmed: no raw-repo storage, ephemeral clones, local embeddings, self-hostable end to end (#5876).