How nectar works
Nectar reads each file, mints a stable identity, writes a plain-language description, stores it on Deeplake, and keeps it current as your code changes.
Nectar reads each file once, gives it a stable identity that survives renames and moves, writes a plain-language description of what the file does, stores both on Deeplake, and recalls them by meaning through honeycomb. Descriptions stay current as code changes.
Here's what nectar is actually doing under the hood, from the moment it first reads a file to the moment your assistant recalls it by meaning.
#How does nectar read my files?
Nectar reads each file in your project once, during the first scan (called brooding). It doesn't just look at the file's name or its path. It reads the contents so it understands what the file actually does.
#What is a "stable identity," and why does a file need one?
Every file nectar sees gets a stable identity: a short unique tag minted once and never recalculated from the file's name or its contents. That matters because both of those things change over time. If identity were based on the file's path, a rename or move would break it. If identity were based on the file's contents, every edit would break it too.
Because the identity is independent of both, a file keeps its history and its description even after you rename it, move it to a different folder, or reorganize your whole project. Nothing resets.
#How does nectar know a changed file is the same file?
When a file changes or moves, nectar has to decide whether it's looking at the same file with new content, or a genuinely new file. It checks a few signals, starting with the most obvious: does the path, modified time, and size still match? If not, does the content still match at a new path? If the content changed too, does it still resemble the old version closely enough to be confident it's a move plus an edit?
If none of that gives a confident answer, nectar doesn't guess. It flags the file for a quick human review rather than risk attaching the wrong history to the wrong file.
#How does nectar write the description?
Once nectar has a file's identity settled, it writes a plain-language description of what the file does, along with a few concept tags. Small files are described in small batches to keep this efficient; larger files are handled one at a time. The description reads like something a teammate would say if you asked them "what does this file do," not a technical dump of syntax.
#Where does all of this get stored?
Everything nectar learns is stored on Deeplake, the same data layer honeycomb uses. That means identity, descriptions, and the file's history all live in one place, with no separate database bolted on the side. Nectar also writes one small, human-readable file into your project that reflects the current state of that understanding, so the map can be committed to your repo and shared with your team.
#How does recall work?
When you or your assistant search for something, nectar looks for files by meaning, not by matching words. It compares the idea behind your question to the descriptions it's written, and returns the files that are actually about that idea.
This isn't a separate search tool you have to remember to open. Nectar's results surface automatically inside your assistant, through honeycomb's shared recall, alongside everything else honeycomb already knows.
#How does nectar stay current as my code changes?
Nectar watches your project and notices when a file changes in a way that matters. It waits for you to pause editing before doing anything, so a burst of saves during active work doesn't trigger a flood of updates. Cosmetic changes, like reformatting, are ignored. Only a meaningful change to what the file actually does triggers a fresh description.
#Common questions
Does nectar change how my files are identified if I rename them? No. Identity is independent of name and path, so renames don't break anything.
Does every edit trigger a new description? No. Only edits that meaningfully change what the file does trigger a new description, and only after you've paused editing.
Where does the understanding actually live? On Deeplake, the same data layer honeycomb uses, plus one small committed file in your project for sharing.