Compliance knowledge is scattered, dense, and unforgiving
Global e-bike compliance lives across dozens of governing bodies, thousands of pages of standards and regulation, in different formats and different languages, much of it locked inside scanned PDFs. There is no single place where you can ask, in plain English, whether a product meets a requirement and get an answer you can trust and trace. The knowledge exists. It just isn't usable.
A wiki LLM the model reasons over, not another search box
The system is a knowledge base the model reads, links, and reasons over, queried entirely in plain English. The pattern is the one Andrej Karpathy described as an LLM wiki. Instead of re-searching raw documents on every question the way a standard RAG pipeline does, the system pre-compiles knowledge into structured, interlinked entity pages. Each standard, region, and component becomes its own page, cross-linked to the others, so the relationships between requirements are captured as first-class links rather than rediscovered from scratch every time. When something new comes in, the model writes its page, then reaches back across the knowledge base to update related pages and flag contradictions.
From scratch, because the shortcuts weren't enough
I started in Obsidian. It wasn't full-featured enough for what the linkage layer needed to do, so I'm building the system from scratch instead. I designed it in Claude and built it with Claude Code. I'm an Agile coach by background, not a developer, and Claude Code is what makes a build at this level realistic on my own.
In compliance, "close enough" is a failure
The domain is unforgiving, which is the entire point. A wrong answer about a safety standard isn't a small mistake. So the system is built to three hard requirements, treated as non-negotiable design constraints rather than nice-to-haves:
- Full source traceability. Every answer points back to the exact source standard it came from. Nothing is asserted without a citation.
- Zero hallucination. The model answers only from ingested source material, never from its own priors. If the knowledge base doesn't contain it, the system says so.
- Accuracy against the source. The answer has to match what the standard actually says, not a paraphrase that drifts.
It ingests thousands of pages of regulation and standards pulled from governing bodies around the world, including scanned documents handled through OCR before they ever reach the knowledge layer.
Alpha, and honest about it
It's in alpha. I'm fine-tuning the functionality against a handful of standards before scaling the corpus. That sequencing is deliberate: get traceability and grounding right on a small, verifiable set first, then widen.
Batch ingestion to make scale affordable
The next phase moves ingestion to overnight API batch processing, committing standards in batches to cut token cost at volume. That's what turns this from a working prototype on a few standards into something that can hold the world's e-bike compliance landscape without the cost spiraling.
This is a capability, not a one-off
The e-bike domain is the proving ground, but the capability is general. It's the same thing I'd bring to any knowledge-heavy operation: turning a mountain of unstructured documents into something a team can question in plain English, where every answer is grounded in the source and traceable back to it. Most businesses are sitting on exactly that kind of mountain. The point isn't the chatbot. It's the traceability.