Faberic

All cases · Case 02 · Knowledge System

Building a brain for the company

As a company's data grows, the problem isn't "finding it" — it's "what do we actually know?"

The key decision in this caseEvery answer must come with evidence

Project · Company Brain · knowledge operating layer
First instance · EV dealer pilot
Status · Live end-to-end · 2026
01 · Problem

Organizational knowledge is everywhere — except where decisions are made

In a typical system, lead data lives in one place · buying signals live in another · and there's no way to check how sales events connect to real outcomes. So executives decide on a "feeling of knowing" — with no evidence that they actually know.

02 · What we found

The signals exist — but no one captures them as knowledge

Working with the first EV dealer, we found that sales signals are very concrete: interest level step by step · interaction history · the car models a customer is interested in — if all of it is stored as facts that can't be edited after the fact (immutable facts), the organization can always answer where what it knows came from, and since when it has known it.

03 · Tension

Let the LLM search freely vs let executives verify

Typical AI knowledge systems let the LLM search data freely and then compose an answer — it sounds smart, but the answers are full of things that can't be verified.

Executives need the opposite: every answer must be auditable, every number must have a source — because these answers become business decisions.

04 · Design Decision

The LLM translates the question — code finds the answer

We limited the LLM to two roles: translating the user's question into a query template whose scope is defined in advance, and composing results that code has already computed.

  • Code runs the actual query — no free-form SQL from the LLM
  • Scores and rankings are computed with versioned logic — not the model's opinion
  • The LLM can compose, but no number without a source
  • Every executive-level insight always comes with evidence
Separate "what is observed" from "what is decided" — observation belongs to AI · decisions belong to repeatable code
  1. UserAsks a question
  2. LLMTranslates the questioninto a query template with a predefined scope
  3. CodeFinds the real answerruns the query and computes scores with versioned logic
  4. LLMComposesno number without a source
  5. ResultAnswer + evidenceevery insight always comes with evidence
The LLM does only two jobs, translating the question and composing the answer; finding the answer belongs to repeatable code.
05 · System

What we actually built — and it's live

  • Knowledge graph — nodes · edges · facts with tenant isolation at the database layer and immutability enforced by triggers
  • Bounded retrieval — a template registry that defines the allowed queries in advance
  • Executive insights — Opportunity / Risk / Trend computed by code, with evidence attached
  • Live ingestion — lead data and the knowledge base flow into the graph automatically
  • Graph visualization — users can actually see the relationships among what the company "knows"

Before going live, we gated it with a parity test: every score computed from the knowledge graph had to match the existing system — it passed 100% with no mismatches, and only then did we switch it on.

06 · Result

Live end-to-end on a real pilot

The system runs the full cycle on the EV dealer pilot — from incoming lead data, through the knowledge graph, to insights executives open in the portal — while the existing system keeps running as usual, with no risk during the transition.

07 · What we learned

A knowledge system you can trust must separate observing from deciding from day one

Organizations don't need an AI that can answer everything — they need to know what they actually know and where the evidence is. When observation and decision are clearly separated, the system can always answer "how do we know" and "when did the rules change" — that's the difference between a search engine and a company brain.