RAG Needs to Start Adding Real Value

Rigorous benchmark results from a patent-pending retrieval architecture — and why the RAG industry needs to start showing its work

F1 = 0.677 on MuSiQue: What a Biology-Inspired Sparse Tensor Graph Engine Taught Us About Multi-Hop RAG

If you haven’t noticed, the AI industry is kind of hot, with the five largest U.S. tech companies spending $427 billion on AI infrastructure in 2025 and projected to spend up to $700 billion in 2026. But a February 2026 study surveying 6,000 CEOs, CFOs, and senior executives found that over 80% of firms report no measurable productivity gains from AI (NBER Working Paper, February 2026). PwC’s 2026 Global CEO Survey of 4,454 CEOs across 95 countries found that 56% say they’ve gotten “nothing out of” their AI investments, with only 12% reporting that AI both grew revenues and reduced costs. S&P Global found that 46% of AI proofs-of-concept were scrapped before reaching production, with only 48% of AI projects making it past the pilot stage.

Something is broken. And shockingly, it’s not the AI models (for the most part).

The Problem Nobody Wants to Measure

Large language models (LLMs) are now remarkably capable. Hallucinations and other legitimate criticisms aside, frontier LLMs like GPT-4, Claude, Gemini can reason, synthesize and generate content with a sophistication and quality that was unthinkable even two years ago. But why are the productivity gains not materializing despite the leaps and bounds of improvement in LLM performance? The problem is what happens before the model uses a single watt of power.

Most enterprise AI deployments use a technique called Retrieval-Augmented Generation (RAG). The concept is simple: instead of relying solely on the model’s training data which has a cutoff date and is general in nature, you retrieve relevant documents from your own (often proprietary) data and feed them to the model alongside the user’s question. This grounds the model’s response in your actual information rather than its parametric memory, reducing hallucination and enabling domain-specific answers.

In theory, RAG should be the bridge between a powerful language model and your organization’s knowledge. In practice, it has become the bottleneck that prevents enterprise AI from delivering on its promises.

The standard RAG approach works like this: chunk your documents into fragments, convert each fragment into a numerical vector (an “embedding”), store these vectors in a database, and when a question arrives, find the vectors most similar to the question and hand those fragments to the model. Called semantic search, conceptually, it’s like a librarian who finds books by topic similarity. Ask about cardiac drug interactions and she retrieves everything shelved nearby. For simple, single-fact questions (“What is our return policy?”), it works adequately.

But real business questions are rarely that simple. Real, everyday, serious business questions resemble something like “Which of our vendors flagged for compliance issues have active contracts in countries where we’ve had regulatory actions in the past three years?” This question requires connecting facts across procurement records, compliance databases, regulatory filings, and contract management systems. It requires multi-hop reasoning.

This is where standard RAG fails. Semantic search retrieves documents that look similar to the question, but it has no mechanism for following a chain of reasoning across documents. It cannot discover that Vendor A was flagged in Report B, which references Jurisdiction C, where Regulatory Action D occurred. Each of those connections requires a separate hop to different shelves of the library - and the vanilla vector search librarian is not built to hop.

Coming back to more familiar territory, anyone who has worked in pharmaceutical regulatory affairs, clinical trial data management, product development or adverse event signal detection will recognize this pattern immediately. Drug-drug interaction queries, cross-reference checks across INDs and NDAs, competitor pipelines and status, ever-changing regulatory requirements across jurisdictions, tracing a manufacturing deviation through a supply chain - these are all inherently multi-hop problems. They require traversing a web of connected facts, not searching a flat index.

The causes of enterprise AI underperformance are well-documented: Gartner predicts that 60% of AI projects unsupported by AI-ready data will be abandoned through 2026, and their 2025 Market Guide for Enterprise AI Search identifies retrieval relevancy gaps and ROT content - Redundant, Obsolete, and Trivial information - as primary bottlenecks. Among these failure modes, one remains particularly underserved: multi-hop retrieval.

For the class of questions that enterprises actually need answered, standard single-step retrieval architectures hit a structural ceiling. The most troubling aspect is not that this gap exists. Technology catching up to real-world requirements is a normal part of the process. The problem is that almost nobody in the commercial RAG space is publishing rigorous, controlled data to demonstrate that their solutions close this gap all the while claiming, implicitly or explicitly, that they can.

Reddit feeds and LinkedIn posts are saturated with grandiose announcements claiming to have “solved RAG” or built “the future of knowledge retrieval.” These posts almost universally share two characteristics: they present no benchmark data against standardized evaluation sets, and they provide no controlled comparisons against baseline systems. The academic community, to its credit, does publish rigorous benchmarks. But the commercial space where customers are actually spending money, operates largely on promises, uncontrolled benchmark figures and demo videos.

Recent independent evaluations reinforce this concern. An ICLR 2026 study (MemoryBench) found that none of the leading commercial memory systems including Mem0, A-Mem, and MemoryOS, could consistently outperform simple RAG baselines that use basic retrieval over the full task context. A separate 2026 benchmark on financial documents found that BM25 - a keyword-matching algorithm from the 1990s - outperformed dense retrieval with one of the strongest commercial embedding models available on nearly every metric. Credit where credit is due, the commercial RAG industry is selling integration convenience and developer experience, which are genuinely valuable. But fundamental retrieval performance breakthroughs? The evidence for those is thin.

Running into our own frustration with the lack of performance in our own work using AI, we decided to do something about it. We built a retrieval engine modeled after what we know best - biology. We benchmarked it on one of the hardest multi-hop QA datasets in the field using the exact protocol and corpus published by the leading academic RAG system, because science. And we are publishing the results, warts and all, in true EluciDx fashion.

From Biology to Sparse Tensors

EluciDx was founded to help partners navigate the immense global complexity of healthcare products - from pharma to diagnostics to nutraceuticals across the science and product and markets across the world. But I have also been deeply passionate about IT since the x286 and MS-DOS days and have been on top of hardware and software developments throughout the decades - above and beyond what could be described as a tech hobby although not close to professional-level. So naturally, serious problem solving in the IT space was only just out of range, until AI came along.

After multiple failed attempts over the past few years trying to use AI for both the day job and also build commercial-grade software, it was only late 2025 with the release of the latest frontier LLMs that the threshold was crossed and AI finally became usable, but only just. The experience is still maddeningly frustrating, and one only needs to scan a few subreddits to witness the fundamental limitations of the present state of commercial AI. But LLM performance crossed a threshold where I could now drag it along kicking and screaming to get serious work done on both healthcare consulting and software engineering fronts. So naturally, I wanted to create the AI tools to first and foremost add value to my professional work and therefore my clients. And like our namesake, I elucidated and diagnosed the lowest hanging fruit I could pick - RAG, or more specifically, LLM context management.

Without getting caught in the technical weeds, modern LLMs are remarkably good at word prediction through brute force calculations from its (relatively) limited memory enabled by massive bandwidth. Human cognitive ability, on the other hand, has incredible memory capacity estimated to be as high as 2.5 petabytes. But our conscious processing bandwidth was estimated by Caltech scientists to be a paltry 10 bits per second. The problem with today’s LLMs is that they are incapable of learning new information in the fundamental sense. All new information outside the training data set and beyond the cutoff date must be provided through some form of RAG for LLMs to be useful for domain-specific, proprietary, or time-sensitive knowledge work which is precisely where I and probably all of you reading this operate in. So the logic goes, if LLMs are a tool just like any other and are intended to extend and enhance human capabilities, then why not augment it with a memory structure that mimics how brains handle memory to make it a better tool that makes use the best of both worlds?

In a standard dense transformer - the architecture underlying most frontier LLMs including newer Mixture-of-Expert (MoE) models - every parameter participates in every computation. The self-attention mechanism at the heart of every transformer scales quadratically with context length, and even in MoE architectures where the feedforward layers are sparsified, the key-value (KV) cache that powers attention remains dense — a 7-billion-parameter model at 128,000 tokens (~words) of context requires over 24 gigabytes of GPU memory for the KV cache alone (PiKV, arXiv 2508.06526). Dense computation scales brutally. A biological neural network, however, is a sparse network of connections. One neuron does not connect to every other neuron. A select few neurons fire depending on the cognitive task, which propagates an electrochemical signal chain throughout the network only in associated neurons. Different neurotransmitters perform different functions across the same synapse (connection). Connections that are used frequently strengthen while connections that are neglected fade. Only a tiny fraction of the neural population participates in a given memory retrieval event, and the mixture of neuron firing patterns and neurotransmitters deployed becomes the cognitive process, including memory recall.

Translating this biological model into a digital memory retrieval solution meant that the structure needs to be a sparse tensor structure, not flat like a traditional indexed database. So a graph it was. However, the variety of neurotransmitters needed to be represented since not all synapses and neural firings are the same, so neither should the edges (connections between information chunks or “nodes”) of our graph. So we created a system where edges can be weighted by multiple dimensions of hierarchy, logical operators (e.g. reinforcing, contradicting, dependent), temporal conditions etc. so even when two edges could have the same nominal value, every edge becomes qualitatively unique. Finally, to mimic the electrical potential-based neural signal propagation, we borrowed a page from analog in-memory computing and modeled the graph traversal to follow Ohm’s law of V=IR where the inverse of edge weights represent resistance. So graph traversal theoretically happens at the speed of electricity while stronger edges (i.e. high edge weights), which reflect a stronger relevance and association, pass more electrical signal down to other linked nodes, while weaker edges which represent weaker associations pose high resistance and thus pass much less energy, killing the signal quickly in that direction.

The result is the Donna engine: a sparse tensor, bitemporal, hierarchical, multidimensional edge-based graph engine - written in Rust, a systems programming language chosen specifically for its raw speed and minimal memory footprint, and utilizing compressed sparse row (CSR) data structures - that retrieves knowledge through biologically-inspired associative pathways rather than geometric or programmatic search. It was fully developed and runs flawlessly on consumer-grade laptop hardware: the entire codebase and benchmarks in this post were produced on a laptop with an Intel i7, 16 GB system RAM and an NVIDIA RTX 3050 Ti with 4GB of shared VRAM. It turns out mimicking biology can pack an incredible amount of performance in a small package - about 12.5 MB for the entire release-build binary sidecar .exe file, to be exact (as of benchmarking time). And the performance we discovered honestly exceeded my wildest expectations.

The Benchmark

To evaluate this engine, we chose MuSiQue (Trivedi et al., 2022), which is among the most challenging multi-hop question answering benchmarks available and a standard evaluation target for leading published GraphRAG systems including HippoRAG 2 (the leading academic multi-hop RAG developed by Ohio State University), PropRAG, and Microsoft’s CoRAG. Unlike other benchmarks, MuSiQue was explicitly constructed to defeat reasoning shortcuts through disconnected single-hop strategies. With MuSiQue, a single-hop model loses 30 F1 (harmonic mean of precision and recall) points compared to a proper multi-hop approach (Trivedi et al., 2022, §5.2). Getting a high score on MuSiQue requires genuine cross-document reasoning.

The kicker? We did not build our own benchmark. We ran on theirs. Because I can’t help being a scientist with integrity.

Specifically, we used HippoRAG 2’s exact published corpus - 1,000 questions and 11,656 Wikipedia passages from their HuggingFace repository (osunlp/HippoRAG_2). Same questions. Same passages. Same evaluation metric: SQuAD F1, a deterministic token-level precision/recall score with no LLM judge involved. Same scoring protocol: answerable questions only (MuSiQue-Ans standard). The questions span 2-hop, 3-hop, and 4-hop reasoning chains, with each additional hop compounding the retrieval difficulty.

To ensure the comparison was controlled, we ran three retrieval systems through the identical reader model (Google’s Gemini Flash at temperature=0 for reproducible, near-deterministic answers): BM25 (keyword matching, the 1990s baseline), LlamaIndex (standard vector RAG with the same embedding model), and our Donna engine. Same reader, same questions, same corpus, same scorer. The only variable was the retrieval system.

Results

The headline: F1 = 0.677. This is state-of-the-art good.

This is the best configuration we tested - our engine paired with a larger embedding model (Google’s gemini-embedding-001 at 3,072 dimensions, and yes, we used API calls for this one) and the reader’s extended reasoning mode enabled. But the headline number alone tells an incomplete story. The real value lies in the full optimization matrix and what it reveals about how retrieval quality, embedding model choice, and reader reasoning interact.

The controlled baseline (Cell A): F1 = 0.565. Using our compact local embedding model (nomic-embed-text-v1.5, 768 dimensions, 137M parameters, running on the laptop GPU) and the reader in its default mode, Donna scored 0.565. Under the same conditions, LlamaIndex scored 0.418 and BM25 scored 0.329. This is the apples-to-apples comparison: same embedding model as LlamaIndex, same reader, same everything except the retrieval architecture.

We then ran a controlled 2×2 optimization matrix to isolate the effects of two variables: embedding model quality (nomic 768d vs. gemini 3,072d) and reader reasoning depth (default vs. extended thinking).

The results revealed something we did not expect. The interaction between embedding quality and reader reasoning is super-additive — the combined improvement (+0.112 F1) exceeds the sum of the individual improvements (+0.071) by 58%. Better retrieval creates opportunities that only a reasoning-capable reader can exploit.

Even more counterintuitive: upgrading the embedding model without enabling reasoning (Cell C) actually hurt performance on 2-hop and 4-hop questions (data not broken out here). Denser, higher-quality retrieval surfaces more plausible distractor passages that a non-reasoning reader cannot distinguish from the correct evidence. The retrieval quality improvement actively degraded answer quality when the reader was not equipped to handle the richer context. This has direct implications for anyone deploying RAG in production: a more expensive/capable embedding model is not automatically better. The entire stack - retrieval, embedding, reader - must be carefully optimized as a system to extract maximum performance.

The per-hop breakdown tells the performance story most clearly. On 3-hop questions — the sweet spot where multi-hop retrieval is essential and the questions remain tractable — the engine improved from F1 = 0.510 at baseline to F1 = 0.704 in the optimized configuration, a gain of +0.194. The hardest category, 4-hop questions requiring four sequential reasoning steps across four different documents, reached F1 = 0.536.

Honest Comparison with HippoRAG 2

Again, as a scientist, transparency is of utmost importance. And any benchmark result is only as credible as its comparison methodology. So here is the full picture, including what favors us and what doesn’t.

The raw F1 gap between our baseline (0.565) and HippoRAG 2’s published result (0.486) is +7.9 points. But approximately 52% of that gap is attributable to the reader model, not retrieval quality. HippoRAG 2 used Llama-3.3-70B as their reader; we used Gemini Flash. Comparing BM25 scores across readers (their BM25 scored 0.288; ours scored 0.329) reveals that Gemini Flash is simply a stronger reader, contributing roughly +4.1 F1 points independent of any retrieval difference.

The fair comparison, therefore, is the BM25-relative retrieval lift - how much each system improves over the BM25 baseline when using the same reader. This controls for the reader confound indirectly:

System	F1	BM25 (same reader)	Relative lift
LlamaIndex (Flash)	0.418	0.329	+27.1%
NV-Embed-v2 (Llama-3.3-70B)	0.457	0.288	+58.7%
HippoRAG 2 (Llama-3.3-70B)	0.486	0.288	+68.8%
Donna w/ nomic (Flash)	0.565	0.329	+71.7%
PropRAG (Llama-3.3-70B)	0.524	0.288	+81.9%

Donna’s retrieval lift (+71.7%) slightly exceeds HippoRAG 2’s (+68.8%), achieved with an over 50× smaller embedding model (nomic at 137M parameters vs. NV-Embed-v2 at 7-8 billion parameters) and no LLM-powered knowledge graph construction during ingestion. PropRAG, from the University of Illinois, exceeds both at +81.9%. We are not claiming to be the best retrieval system in the world. We are claiming competitive retrieval quality at a fraction of the computational cost, which also suggests (and as evidenced by our best configuration F1 score) that with increased computational effort, results can improve dramatically.

Among zero-shot RAG systems (i.e. those not fine-tuned on MuSiQue’s own training data) our optimized configuration’s F1 of 0.677 is, to the best of our knowledge as of May 2026, the highest end-to-end score published on this benchmark. The highest prior published zero-shot results on the same corpus range from PropRAG at 0.524 (Llama-3.3-70B reader) to StepChain GraphRAG at 0.554 (GPT-4o reader). Trained systems — those fine-tuned on MuSiQue’s own training data — achieve higher scores: Beam Retrieval (Zhang et al., NAACL 2024) reaches 0.692 using a supervised reader. Our engine, with zero task-specific training, comes within 1.5 F1 points of that fine-tuned result.

We are publishing these comparisons including the reader confound, including PropRAG’s superior retrieval lift and including Beam Retrieval’s higher fine-tuned score, because cherry-picking metrics is exactly the tech bro bullshit practice we are criticizing. Our technology is strong enough to withstand honest comparison.

What This Means for Production

Benchmark scores on academic datasets are necessary but not sufficient. The question for any production deployment is: how does performance trade off against cost at realistic operating points?

To answer this, we leveraged the fact that our retrieval system ranks retrieved nodes by activation energy by taking the full retrieval output for each question and virtually truncated it at progressively smaller budgets (500, 1,000, 2,000, 3,000, 5,000, 10,000 words) for re-scoring the reader’s answers against the gold standard at each budget level. We then fit a bias-corrected regression model comparing two independent prediction approaches - a per-question empirical model and a binary partition model - and calibrated using the actual scored data points where the two models converged.

The curve follows a log-linear trajectory with R² = 0.964. The practical implications are significant:

A “Quick Answer” scenario at 2,000 whitespace words (~2,700 tokens) retains 93.5% of the full-budget F1 at 10% of the token cost. A 10× increase in context budget (2,000 → 20,000 words) buys only +0.037 F1 — a 7% relative improvement for 10× the cost. Budget sensitivity is concentrated almost entirely in 4-hop questions (+0.150 F1 across the full range); 3-hop questions are essentially flat (+0.024).

For product deployment, this means a flexible cost-efficiency-based RAG strategy can be used. Quick Answer budgets for simple and routine queries, large token budgets for complex multi-hop queries. This setup can deliver production-grade retrieval quality at a fraction of the infrastructure cost that current enterprise RAG deployments assume.

The Accountability Gap

I want to be blunt about what these results represent in the broader context of the RAG and AI industry.

F1 = 0.677 on MuSiQue is, to the best of our research as of May 2026, the highest end-to-end F1 score published by any zero-shot RAG system on this benchmark. The highest prior published zero-shot results range from HippoRAG 2 at 0.486 through PropRAG at 0.524 to StepChain GraphRAG at 0.554. Standard vector RAG (LlamaIndex with identical embedding) scored 0.418. BM25 — a keyword algorithm that predates the current century — scored 0.329.

These are the academic systems. They publish their numbers, their methodologies, their code, and their datasets. They submit to peer review. They disclose their limitations. Whatever one thinks of the specific approaches, the academic multi-hop RAG community operates with scientific accountability.

Now consider the commercial space.

Mem0, the most prominent commercial AI memory platform, published results on the LoCoMo conversational benchmark showing improvements over baselines, including multi-hop conversational recall. An independent evaluation at ICLR 2026 (MemoryBench) subsequently found that, as of their evaluation date, none of the leading commercial memory systems, Mem0 included, could consistently outperform simple RAG baselines using basic full-context retrieval. On LongMemEval, an independent evaluation measured Mem0 at 49.0% and Zep at 63.8%. Neither publishes results on MuSiQue or any cross-document multi-hop QA benchmark — their evaluations test conversational memory recall across chat sessions, not cross-document reasoning across unrelated sources.

Zep’s Graphiti engine is technically interesting. Its bitemporal knowledge graph with entity validity windows is genuinely novel architecture. But “technically interesting” and “demonstrably better at retrieval” are not the same claim, and the latter requires the kind of controlled evaluation that is conspicuously absent from Zep’s public materials.

The broader pattern is consistent across the commercial RAG landscape. Some platforms have begun publishing multi-hop comparisons — Cognee, for example, benchmarks against Mem0 and Graphiti on HotpotQA, a 2-hop multi-hop benchmark. But none publish results on MuSiQue — the benchmark specifically designed to defeat shortcut reasoning through artifact-controlled, 2-4 hop questions where bridge entities are deliberately unnamed. The gap between HotpotQA and MuSiQue is the gap between “connect two explicitly linked documents” and “chain reasoning across four documents that never reference each other.” Enterprise knowledge retrieval is the latter problem.

In drug development, you don’t get to market by announcing you have a molecule. You prove it works through rigorously controlled trials with predefined endpoints and with honest adverse event reporting. The stakes in enterprise AI are not life-and-death (usually), but they are measured in hundreds of billions of dollars of investment that is currently not generating expected returns. If the RAG segment wants to be taken seriously as an infrastructure layer for enterprise AI and not as the latest iteration of the enterprise software hype cycle, it needs to start publishing controlled benchmarks with standardized evaluation sets and honest comparator arms. Not empty claims or demos. Not blog posts with hand-wavy diagrams. Hard data and reproducible methodology.

We are publishing ours because that is what accountability looks like. Funny how different industries have different standards.

Where the Engine Goes From Here

Honesty about results requires honesty about limitations. We have discovered the engine has clear areas for improvement and have a defined development roadmap to address them.

Recall@K. While our end-to-end F1 scores are strong, the engine’s raw retrieval recall - the fraction of relevant passages surfaced before the reader sees them - lags behind the best published systems. HippoRAG 2 and PropRAG achieve higher Recall@5 scores than we currently do, primarily through larger embedding models (NV-Embed-v2 at 7-8 billion parameters) that exceed our hardware capacity. That they achieve higher recall despite lower end-to-end F1 scores indicates clear room for improvement on this front.

Lazy Mode (Agentic Retrieval). The benchmark results in this post are from “Eager Mode,” i.e. a single-pass retrieval that fires once and hands the full context payload to the LLM reader. The engine also has a “Lazy Mode,” where the LLM can iteratively query the graph mid-reasoning, decomposing complex questions into sub-queries and refining its search based on what it has found so far. This is agentic retrieval, but grounded in a structured memory graph with targeted recall rather than unconstrained web search or crawling over an indexed database. A pilot test showed Lazy Mode recovering questions that Eager Mode missed, particularly at 3-hop and 4-hop complexity where iterative decomposition is essential. For mission-critical and high-value complex enterprise queries, this may be the key that unlocks the elusive AI productivity.

Additional benchmarks. MuSiQue evaluates multi-hop QA. We have also completed an initial evaluation on LongMemEval, a 500-question conversational memory benchmark (temporal reasoning, knowledge updates, multi-session recall). Code understanding, structured data retrieval, and a potential third benchmark axis (GraphRAG-Bench) are in the pipeline. The goal is a multi-segment evaluation that demonstrates the engine’s versatility across retrieval modalities, not just its strength on one. We are building this for real-world use including our own high-stakes use cases, after all. And these benchmarks will provide an opportunity to further refine the engine and devise various parameter optimization strategies for various deployment scenarios, considering we currently have 60+ tunable variables on the API surface that users can tweak to squeeze maximum performance from their unique data set.

Academic publication. We intend to formalize the benchmark methodology and results for peer-reviewed publication. We believe the methodology, particularly the reader-controlled BM25-relative lift metric for cross-paper comparison, has value to the research community independent of our specific results. Full transparency is the principle, not a concession.

Where EluciDx Goes From Here (for AI)

EluciDx was founded in and for life sciences and we will maintain our unwavering dedication to the sector. Our partners and clients in pharma and biotech are not going anywhere; if anything, the retrieval technology described in this post has direct applications to helping solve the complex problems our clients face every day.

What has changed is that the technology we built to solve knowledge retrieval has applications far beyond healthcare. The Donna engine and its LLM orchestration partner engine Alfred are the intellectual property core of a broader product vision in AI.

The Donna-Alfred Engine is the proprietary Rust engine described in this post. It is patent-pending, built for enterprise integration via a standalone binary that communicates over JSON-RPC. It is designed to be plugged into any LLM-based application requiring advanced retrieval capabilities - not as a SaaS wrapper but as a native, high-performance drop-in component that runs on the customer’s infrastructure.

The Donna Platform builds on our engine to bring a model-agnostic, consolidated context management system centered around the user, not an LLM provider. It is designed to be universal context manager and server that works with ChatGPT, Claude, Gemini, or any other interface and allows a user to seamlessly transition and continue a chat amongst any provider or model with the goal of providing a seemingly infinite context window, solving the single biggest gripe among non-coding LLM users - context amnesia and endless cutting-and-pasting of conversation histories. This frustration was actually what kicked off the series of developments that led to the invention of the Donna-Alfred engine. Planned interfaces include a Chrome extension, web UI (SaaS/PaaS) and MCP server on a unified backend.

Layer 3 is born from the hard lessons learned while building Donna-Alfred with AI. Building a complex Rust monorepo with LLM coding assistants taught us that AI-generated code needs the same kind of disciplined oversight that pharmaceutical manufacturing applies to quality management. Layer3 is an AI-driven software development platform that embeds deterministic guardrails - code review, governance tracking, cross-model adversarial QA, and structured decision records - into every step of the build process. It is designed for domain experts who need software built to professional standards without needing (or having the skill) to read code themselves. All the benefits of AI-led development, with safeguards against the chaos that “vibe coding” inevitably produces.

There are other quite exciting IPs in development as well, so stay tuned.