Building the DataNexus.

This post maps the path from a natural-language query to the final response, showing which components run and in what order. It is the starting point of the series; the rationale behind each component choice and the experiments along the way are covered in the posts that follow. Why routing architecture instead of a single NL2SQL pipeline When NL2SQL is first applied to a real enterprise environment, the same problem usually appears. DDL alone does not let the LLM infer what a table named T_CUST_MST actually means, or what calculation logic “net revenue” refers to in this organization. Benchmark scores keep climbing, yet reports from real enterprise deployments still show accuracy falling below 50%. The same category of errors does not disappear just by swapping datasets. ...

I build DataNexus with several coding agents running at once. Claude Code fixes router logic while Codex fills in test coverage. The workspace was the problem. With one checkout and multiple terminals, agents step on each other’s files. One reinstalls dependencies while another’s build breaks mid-run. I juggled stashes for a while, then gave up and ran them one at a time. Agents I added for parallelism were running serially. ...

In the previous ten posts, I analyzed the most common SQL generation errors. I used BIRD and Spider benchmarks, tested several models, and grouped wrong answers into types such as COLUMN_BINDING, VALUE_BINDING, and DERIVED_METRIC. As I kept looking at those SQL errors, I realized I wanted to check something different. “So how should generated SQL and supporting context appear in the UI?” I had been focused on accuracy and had missed what users actually need from the interface. In a workplace data analysis tool, the UI has to make it clear where numbers come from. Without traceable context, users end up re-running the SQL even when the result looks correct. ...

Three multi-candidate experiments from post 9 produced no meaningful improvement. Before moving on to the Schema Binding Plan, I wanted to test one more hypothesis: model tier as the bottleneck. I expected Gemini Pro to improve the current 56% accuracy baseline over flash-lite. I also ran the error-type classification and Spider experiment as part of that test. Switching to Pro Made Things Worse Prompts, context, and pipeline stayed the same. Only the model changed, and the same 50 BIRD questions ran against it. The metric is EX (Execution Accuracy): whether the generated SQL produces the correct result when executed against the database. ...

I hit 80% on my own 30-question benchmark, but only 56% on BIRD Mini-Dev’s 50 public questions. Nine experiments later, I had ruled out the multi-candidate hypothesis from three different angles. What’s left is schema understanding and methodology.

Super-sub types clarify business classifications at the logical model level. When converting to a physical model, three options emerge — and in a DW, that choice reshapes the entire dimension design.

Same Crow’s Foot, different meaning. A single dashed line means different things in different tools. If you want models to serve as a shared language on your project, start by aligning on notation.

Even when the ERDs look similar, the design philosophies are completely different. OLTP is about transactional integrity; DW is about analytical access paths. That difference creates unfamiliar things like Unknown records and point-in-time data.

How DW modeling considerations have shifted with Synapse, BigQuery, and Redshift. Kimball, Data Vault, One Big Table — practical criteria for choosing the right approach.

When dimension data changes, do you overwrite history or preserve it? We implement SCD Type 1, 2, and 3 differences in SQL, then build a production pattern with dbt snapshot.

Cleanse and standardize the raw data stacked in Bronze. Fix types, unify column names, remove duplicates. We define this process as SQL models in dbt.

There are two ways to load data into Bronze. Overwrite everything, or bring only what changed. Which one you choose completely changes the complexity of your pipeline.

Bronze, Silver, Gold. What changes when you load data into separate layers. We build it hands-on with DuckDB and dbt.

If GEO optimizes for consumer AI, AEO optimizes for coding agents. This article covers document length constraints, llms.txt, skill.md, and AGENTS.md — the files that matter.

Even with perfect On-Site GEO, half of AI citations come from external channels. We cover platform-specific Off-Site strategies and how to diagnose your robots.txt setup.

How product master DB data flows through a 3-stage pipeline to become JSON-LD in your HTML . Covers the pipeline architecture and SSR-based automated deployment.

ChatGPT favors Wikipedia, Perplexity leans on Reddit, and Gemini prefers official websites. Covering all AI platforms with a single strategy is impossible.

Only 9% of Google’s top 10 pages are cited by AI. In an era where SEO rankings no longer guarantee AI citations, we break down the three core principles of GEO and their academic foundations.