AI Scanner, Engine Validator: Stop Asking LLMs to Count Lines
Tree-sitter and ASTs answer 'where is X called?' deterministically. LLMs answer 'why is X called?' with fuzzy reasoning. Fabriq draws the line in the right place — and the result is audit-ready cognitive artifacts.
The industry has tried two extremes and both fail at scale.
Pure static analysis (SonarQube-style, hand-written regex, framework-specific AST rules) is brittle. Change one internal framework and half your rules stop matching.
Pure LLM analysis (point Cursor at the codebase and hope) hallucinates physical coordinates. "It's on line 142" — except line 142 is a blank line.
We picked a third path.
The split
| Layer | Owns | Tools |
|---|---|---|
| Engine (Validator) | AST structure, call graph, file existence, line numbers, evidence validation | Tree-sitter, code graph, deterministic rules |
| AI (Scanner) | Variable semantics, framework intent, business rules, historical context | LLM with carefully bounded code slices |
The orchestrator pulls evidence through the engine first, hands the AI a prepared slice with stable physical anchors, then asks the AI to produce YAML cognitive artifacts tagged with sources[]. The engine revalidates every source before the artifact is committed.
What we shipped
The full design lives in our CDR technical spec, but the load-bearing pieces are:
- CodeGraph — a workspace-level method call graph built from Tree-sitter.
- SSOT per dimension — workspace and feature keep separate code graphs; merge is explicit.
- Cognitive artifacts as YAML with mandatory
sources[]field, validated by engine before commit. - CMR (Cognitive Merge Request) — the close-time ceremony that promotes a feature's cognitive output into the workspace.
What this buys you
- Audit trails — every "why" in your docs links to a real file path and line range that the engine checked still exists.
- No tool-call hell — the LLM never recursively queries the codebase. It receives a bounded slice from the engine.
- No physical hallucination — the engine ignores the AI's stated coordinates and re-resolves the symbol before accepting the evidence.
The bottom line: AI does what it's good at. Engine does what only it can do. The orchestrator keeps the seams honest.
Related articles
AI Scanner, Engine Validator: Why We Don't Ask LLMs to Count Lines
Pure static analysis is brittle. Pure LLM analysis hallucinates. Fabriq's third path draws a clean line: Tree-sitter and ASTs answer 'where is X called?' deterministically; LLMs answer 'why is X called?' with fuzzy reasoning. The orchestrator ties them together with evidence chains that are auditable by construction.
CDR from dapei-skill to Fabriq Desktop: Four Hard-Earned Moves
CDR keeps code knowledge alive by 'AI as Scanner, Engine as Validator.' In dapei-skill we shipped it as a headless engine powering a static portal. In Fabriq Desktop we kept the philosophy but rewired the architecture around symbol handles, an embedded engine, and a strict workspace/feature boundary.
Cursor vs Fabriq: Why Agent-Agnostic Architecture Wins
Most AI coding tools lock you into one agent. Fabriq's agent-agnostic architecture works with OpenCode, Claude Code, or any ACP-compatible backend — and the protocol is more important than any single model vendor.