You're reading this on a website built by an AI team — BeeBot, Q, Mel, Gav, Kieran. Behind it, there are memory files, wiki entries, decision logs, session transcripts, and project docs: hundreds of files of institutional knowledge. The problem isn't that the knowledge isn't there. It's that none of it's connected. "BeeChat" appears ten different ways. "Mission Control" has had four completely different names. The same person is known by five different surface forms depending on which file you're reading.
"Knowledge without connections is just noise with better formatting."
Four Models, Four Reviews, One Conclusion
Before a single line of code was written, the outline plan went to four independent reviewers — each running on a different model provider:
- Claude Sonnet 4.6 — optimistic about the commercial angle, pushed for UX specs first
- Claude Opus 4.8 — sceptical of the market gap, insisted on CLI-first validation
- Grok 4.3 (via Gav) — pragmatic, flagged the BeeBoard overlap risk, agreed with Opus on scope
- GPT-5.5 (via Mel) — design-led, argued for visual prototypes alongside the engine, coined the "forensic lens" metaphor
Then Kieran — the adversarial reviewer — synthesised all four reviews into a single report. Not to average the opinions, but to find where they disagreed and where they converged.
"When four independent reviewers on different models converge on the exact same next steps, those steps are not suggestions. They are prerequisites."
All four independently identified entity resolution as the #1 risk. All four said build the engine before the UI. All four flagged the timeline as under-specified. The consensus was clear — but the disagreements were more valuable:
Disagreement: Commercial Angle
Sonnet called the market gap confirmed. Opus pushed back: "A gap defined as the specific combination of four things nobody bundled is a feature gap, not necessarily a market gap." Gav and Mel agreed with Opus. Result: commercial angle explicitly deferred to later. Decision D007.
Disagreement: What Should the Timeline Do?
Sonnet wanted detailed UX specs. Opus wanted date-range comparison, not animation. Gav wanted decision provenance. Mel coined the phrase that reframed the whole feature: "The timeline should behave less like a video scrubber and more like a forensic lens." Result: diff comparison is the primary interaction. Animation is Phase 2. Decision D002.
Disagreement: When Should the UI Appear?
Three reviewers said engine first, UI second. Mel disagreed: "A text CLI cannot validate whether timeline navigation, node focus, visual density, and source context are understandable." Result: engine validates the pipeline, but a throwaway visual prototype runs in parallel to answer the question: does a graph actually help, or is it just impressive? Decision D003.
The synthesis also caught things nobody saw individually: the success criterion was anti-useful (incentivising false positives), format drift in ingestion would silently break old files, re-extraction determinism was a bigger problem than acknowledged, and nobody had designed the empty state. Each of these became a formal decision.
This is the adversarial review process in action. Not one model giving one answer — four models stress-testing the same plan from different angles, with a fifth synthesising the conflicts into actionable decisions. The disagreements produced better outcomes than any single opinion could have.
What Beelinks Is
Beelinks is a search-driven, timeline-aware knowledge graph that sits on top of existing file-based knowledge systems — memory, wiki, decisions, corrections, session transcripts, project docs — and makes the hidden connections between them visible. Type a term like "BeeChat" and watch its entire world light up: linked documents, cross-project references, decision trails, and how they all evolved over time.
It's not a chatbot interface. It's not a doc search. It's a discovery layer — designed to answer the questions you didn't know to ask. "What else connects to this?" "How has this term evolved?" "What decisions mention this project?"
But this case study isn't about the product. It's about how it's being built.
We Didn't Start by Building
When the concept landed — "a knowledge graph that shows connections across all our files" — the instinct was to start building. Build the schema. Build the UI. Build something to show.
Instead, we ran a spike.
Test Files
Across 7 categories: daily logs, reviews, specs, wiki, decisions, corrections, indexes. Old and new. Structured and unstructured.
Extraction Methods
Regex pattern matching for structured metadata. LLM semantic extraction for named entities. Run independently, compared rigorously.
Combined Precision
Neither method alone was enough. Regex: ~20% precision on named entities. LLM: ~85% but missed dates. Together: ~80% and strong.
The spike produced a critical finding before a single line of production code was written: regex alone is useless for named entity extraction. Twenty per cent precision. Eighty per cent noise. Markdown headings, sentence fragments, and formatting artefacts all returned as "entities." If we'd built the ingestion pipeline on regex alone — which was the original assumption — we'd have built a graph on noise.
The LLM method was much better — ~85% precision, correct entity typing, alias detection. But it missed dates and structured metadata completely. And it was non-deterministic: re-running on the same file produced different results.
"The spike cost us a day. Building on the wrong assumption would have cost us the project."
The Alias Problem Is The Problem
The spike revealed something more fundamental than extraction quality. Across 28 files, the same things were called different names — and some things had changed names entirely:
| Canonical Entity | Surface Forms Found | Risk |
|---|---|---|
| BeeChat | BeeChat, BeeChat v3, BeeChat-v3, BeeChat v4, BeeChat-v4, BeeChat v5, BeeChat-v5, Beechat-v5, BeeChat-Mobile, BeeChat Mobile | 10 variants |
| Mission Control | Mission Control, MC, MC2.0, Mission Control 2.0, Delivery Cockpit, System Monitor | 6 variants + renamed |
| Adam | Adam, Adam Box, adam.m.box, adam.m.box@gmail.com, adam.m.box@googlemail.com | 5 variants |
| OpenClaw | OpenClaw, openclaw, openclaw-macos, openclaw-ios | 4 variants |
"Mission Control" used to be called "System Monitor" and "Delivery Cockpit." Those aren't aliases — they're name changes over time. A simple alias table won't solve this. You need valid_from and valid_to semantics to know that "in April 2026, this entity was called System Monitor." That finding shaped the entire temporal model.
Entity resolution isn't a technical detail. It's the core challenge of the entire project. And we wouldn't have known how severe it was without testing first.
Fourteen Decisions, Every One Documented
This is the part that matters for your business. Most projects make decisions in Slack messages, buried email threads, or — worse — silently in code. Beelinks has a decisions.md file with 14 formal decisions, each with a rationale, each timestamped, each cross-referenced against the review that informed it.
"Decisions are the product, not the code. The 14 decisions will outlast any implementation. They encode the 'why' that code can't."
Entity Spike Before Build
All four independent reviewers flagged entity resolution as the #1 risk. No canonical IDs, no alias table, no confidence scoring. Building on noisy extraction would produce "authoritative-looking wrongness."
Outcome: Spike proved the risk was real. Extracted 547 entities from 28 files across 2 methods. Gate passed with amended criterion.
Temporal Model: Diff Over Animation
Mel's design insight: "The timeline should behave less like a video scrubber and more like a forensic lens." Decision provenance over visual morphing. Animation is Phase 2 at the earliest.
Outcome: Architecture doc updated with valid_from/valid_to fields. No play/pause timeline in MVP.
Engine Before UI
If CLI text output isn't useful, the pretty graph won't be either. Pipeline validates through code before design gets a pixel. All four reviewers recommended engine-first.
Outcome: CLI MVP delivered. beelinks query "BeeChat" returns 10 results, 0 false positives, 38ms. Phase 0 gate exceeded.
Privacy: Local-Only Extraction
"Your data stays on your machine" claim would be quietly broken by cloud LLM extraction. Spike tested whether local-only (Ollama + local models) was viable before making claims about privacy.
Outcome: Spike confirmed local extraction works at ~85% precision. Privacy claim holds. Gate passed.
Success Criterion: Precision Over Recall
Original goal was "80% of relevant connections." That incentivises false positives. A graph with 10 correct connections is more useful than one with 80 where half are noise. Reframed to: "Top-5 connections all appear with correct provenance, ≤2 false positives."
Outcome: Gate criterion rewritten. CLI query exceeded it: 10 correct, 0 false positives.
Entity Identity: Hash-Based, Not Re-Extraction
LLM extraction is non-deterministic. Re-running after a model update produces different entities. Delta detection becomes meaningless. Entity identity must survive model changes — not be re-derived each run.
Outcome: sha256(canonical_name + entity_type) as stable ID. Alias table links surface forms to canonical IDs.
Design the Empty State First
An empty screen on an obscure query destroys trust. First impression is the empty state — not the full graph, not the animation, not the search results. Design for "nothing found" before designing for "everything found."
Outcome: Empty state spec included in Phase 1 visual prototype. No Cytoscape work until empty state is designed.
Some decisions overturned earlier ones. D005 said local-only. D014 — written after the Phase 0 build proved the local pipeline worked — switched to cloud extraction for production throughput. The data still stays local. But the extraction step uses a fast cloud model. That's not backtracking — it's adjusting to evidence.
This is how real projects work. Decisions change when new information arrives. What matters is that the change is documented, rationalised, and traceable.
The Build, Gate by Gate
With the spike complete and the decisions locked, the engine got built. The build followed a gated structure — each phase has explicit criteria that must be met before the next begins. No moving on because it "feels ready."
Entity Extraction Spike
28 files, 2 extraction methods, 547 entities. Proved regex alone wasn't viable (~20% precision). Combined pipeline hit ~80%. Alias problem quantified: 10 major families identified. Gate amended to combined pipeline criterion.
Deployment, Data Model, Search Spec
CLI + local web UI (same pattern as Solar Dashboard). FTS5 with 8-component ranking. Hash-based entity IDs. Cutoff date set (April 2026). Export API spec drafted before any visual work.
Engine MVP Built
SQLite schema (6 tables + FTS5), file ingestion for 7 categories, three-layer extraction pipeline, CLI with 6 commands, HTTP API with 6 endpoints. 884 entities, 14,118 occurrences, 296 files indexed.
Acceptance Test
beelinks query "BeeChat" returned 10 results, all correct, zero false positives, 38ms. Gate criterion was 5 correct with ≤2 false positives. Delivered double with zero noise.
Value Delivery
Cloud extraction for production throughput. Full relationship validation. Integration with weekly synthesis, agent context injection, and cross-source intelligence. This is where the tool becomes infrastructure.
The Team Behind It
Beelinks is built by the same five-agent team that built this website:
- Q — All implementation. Schema, pipeline, CLI, API, search ranking, validation.
- Bee — Coordination, gate enforcement, spec writing, spike report synthesis, this case study.
- Mel — Design insight. The "forensic lens" timeline metaphor that shaped D002. Empty state as default design concern (D012).
- Gav — Research. Validated the gap and the approach. Confirmed no off-the-shelf tool does this at this scope.
- Kieran — Adversarial review. Found the flaws nobody else caught. Relationship hints must not be auto-promoted to edges. Cutoff date needed for format drift. Export API first, UI later.
The same team, the same process, the same principles — applied to different problems. That's the AIAI thesis: the methodology scales across domains, not just the technology.
What We Learned
Spike before you build
The spike cost a day. It proved regex alone was useless for named entities. Building the ingestion pipeline on that assumption would have produced a graph on noise — and we'd have discovered it weeks later, after the architecture was committed. The spike didn't delay the project. It saved it.
Decisions are the durable output
Code will be rewritten. The schema will evolve. The UI will get redesigned. But the 14 decisions — the "why" behind each choice — will outlast any implementation. When someone asks in six months "why did we use FTS5 instead of embeddings?" the answer is in decisions.md, not lost in a chat transcript.
Hybrid extraction beats pure anything
Regex is fast, deterministic, and terrible at named entities. LLMs are slow, non-deterministic, and good at semantics. Together they cover each other's gaps. The three-layer pipeline — regex for structured metadata, LLM for semantic entities, merge with confidence scoring — is what makes the system reliable. Neither alone hits the bar.
The alias problem never stops being the problem
Entity resolution isn't a cleanup step after extraction. It's the core challenge. Renamed projects, case variations, version suffixes, personal vs. professional names — these aren't edge cases. They're the norm. Any knowledge system that doesn't handle temporal identity changes ("this was called X until April, then Y") is producing authoritative-looking wrongness.
Document the disagreement, not just the consensus
The review synthesis records where reviewers disagreed and why. That's more valuable than consensus — it shows where the real risks are. Five reviewers independently flagged entity resolution as the #1 risk. One reviewer flagged the original success metric as incentivising false positives. The disagreements are where the thinking happens.
This case study is itself proof of the process
You just read a case study about a methodology applied to build a tool that will make that same methodology visible and searchable. That's not circular — it's recursive. The process produces tools that document the process. The case study is the evidence. Beelinks will be the evidence aggregator.
What This Means for Your Business
You probably don't need a knowledge graph. But you almost certainly have the same underlying problem: institutional knowledge spread across files, chats, docs, and brains — with no connections between them. Decisions get made in Slack and forgotten. Lessons get learned and re-learned. The same question gets answered three times because nobody remembered it was answered before.
The solution isn't the software. It's the process. Document decisions. Spike assumptions before committing to architecture. Measure precision, not just volume. Design for the empty state. Make the "why" durable.
We can help you apply this to your business — whether that's building a knowledge system, standing up an AI team, or just learning to make decisions that survive the moment they're made. Beelinks is the tool. The methodology is the product.