The whole system, written down.

For a while back in the summer of 2025 I noticed the emergence of AI content, and some of it was bordering on so realistic that it was difficult to tell whether it was real. The fundamental issue then becomes: how do I know what is real or not. And if it is real, is it in date.

Around this time I also started using LLMs to search online for data, and it became clear straight away that my habits for finding data were moving from an "Ask Google" to an "Ask LLM" approach. I had not been able to do this before, because models could not search the web. Early models would also hallucinate data on a regular basis, which was a massive problem and needed constant checking. That brought me full circle: how do I know this data is true, or at least have confidence in what I am looking at. Google was always my go-to before this point, and using rankings and the algorithm I could make my informed choices. When AI content started showing up this became harder.

At this point I decided there must be a better way to control what my agent was reading, and to let the agent break down the content it was reading to almost the atomic level. Then group the work and build the dependency back to where the data was coming from. That developed into the Engine side of the platform, which serves today. I spent close to three months building it. The first work coming out of it was very good, the results held at scale, and that side has been working well ever since.

As the agentic world developed it became clear that memory and recall were also a big part of what I was dealing with daily. Models with early reasoning were a real step up, but it became clear they could wander off the garden path easily unless the prompting was good and alignment was given to avoid drift during sessions. It was noticeable that drift also occurred when you started new sessions, so I naturally started developing "Master Plans" to first show true north, then built phased work plans on top of them. Over time those developed into "ExecPlans", which come from a similar setting but require less master-plan oversight and are more dynamic, now that models can bridge the gap between session runtime and what we need to do next.

At this point it became clear that context was a big thing. I had recently started using Claude and noticed straight away that token usage was going to be important, not just the "right tokens" but the use of "efficient" tokens. Context windows were small, and compacting was a hard thing to deal with compared to its Codex rival. It is at this point I started building a new database engine which was append only and needed to be quick. I settled on using my GPU, which meant it would scale well and information was instant; ingestion was also very impressive. I had planned on using a developed database, but found I needed a certain set of functionality and no one database did all of it. This is when CoreCrux was born.

Once CoreCrux and the Engine got talking, things moved quickly to firm up the system. I then needed to prove the system was as good at recall as it was at scaled performance. That type of data sits in the domain of memory and recall rather than a straight corpus lookup: observation, logs, long dialogues, prose with minimal formal text. It was a challenge for the Engine side, so I decided to complement the system with one that would serve just this type of data, called VaultCrux. It also dealt with memory write and read, which is useful when you are saving data out of a session near max context. It was built over a few months and was a challenging environment. The number of subsystems built was large and only a small fraction made it into the production build. It was a fascinating time, and at times I felt I would never reach the other side. It turns out I did.

My own note from that period is that VaultCrux was returning 90%+ on the bench in strict mode, and along the way we found genuine issues in some tests and reported them to the bench owners. Take that as my account of a run I did, not as a published result. It carries no corpus name and no revision, so by the house rule we hold ourselves to on every other page, it does not get quoted as a benchmark. The numbers that do meet the bar are on Bench results, each with the corpus it was measured on and the revision it was measured at.

Once the tests were covered we then needed to lower the token count per retrieval. This was a challenge, because models sometimes do what they want rather than sticking to the rails, and that produces self-inflicted context rot. Sticking to facts was one way out: the model cannot reason around a fact. That became the foundation of the Crux Daemon, an agent orchestration service that ties together VaultCrux, the Engine (now merged into CruxEngine) and CoreCrux.

These systems sit alongside the local-first model, which is a cut-down version of the CoreCrux server. Local first is not a default you can flip. It is the floor, and it is permanent: you can stay local forever and connect to the platform only when you want improved embedding or data processing services. The full system is close to being online and we are looking forward to rolling it out.

That is the argument, and the rest of this documentation is the working out. Documentation is not proof. A citation is not evidence. "The model said so" is not something you can hand to anyone who has to sign their name to a decision. So every retrieval leaves a record, and anyone can check that record without an account with us. What the record establishes is narrow, and we say so rather than let the rest imply otherwise: it is a verifiable record of what was stored and retrieved, which is tamper-evidence, not an attestation of how an agent behaved. Attestation of conduct needs a witness on the traffic path holding its own key, and that is honestly stated as not built. I would rather write that down than let a strong claim next to it do the implying.

Three things people usually want next. If you want to know what the pieces are and which of them you can read the source of, read the Crux family; it names each system and states its posture plainly. If you want to run something today, the Crux Daemon is free, local, needs no account and nothing leaves your machine unless you configure it to, and First run is the shortest path to a working one. If you came to check the claims rather than the story, Bench results carries the numbers with their corpora, and Receipts and proof carries what a receipt does and does not prove.

A note on this documentation

This set covers the whole family, not one product: the daemon you install, the hosted plane, the substrate underneath it, and the surfaces on top. Some of it is written for a person who wants to understand or operate the thing; some of it is a machine contract, tool schemas and route tables and wire formats. Those two read very differently and mixing them helps nobody, so every group above carries a track. Pick For people or For agents at the top of this page and the spine filters to match. Everything is always one click away, and nothing is hidden permanently.