Overview
In this episode of The Dashboard Effect, Landon Oaks and Azure Data Architect Mark Binder pull back the curtain on Project Celeste, an internal AI initiative Blue Margin is building to help engineers and analysts navigate unfamiliar data systems. The conversation is early-stage and honest about it, covering what the tool is designed to do, the technical decisions behind its architecture, and where the team is headed as they prepare to roll it out internally.
For anyone interested in how a data engineering firm is approaching AI integration from the inside, this episode offers a rare and candid look at the process before it becomes a polished product. See how Blue Margin’s Managed Data Platform puts the AI tooling and data architecture principles behind Celeste to work in client environments, turning internal innovation into practical capability for the organizations Blue Margin serves.
What This Episode Covers
Natural Language to SQL (2:51 – 3:10)
At its core, Celeste allows users to ask questions in plain language and converts those questions into SQL queries that run against data systems like NetSuite. The goal is to reduce the time engineers spend reverse-engineering unfamiliar schemas before they can start asking meaningful questions of the data.
A Privacy-First Approach (3:23 – 4:06)
Rather than feeding raw client data into an AI model, Celeste works with metadata: schema information like table and column names, combined with business context. This keeps sensitive data out of the AI entirely, addresses the practical limitations of large context windows, and makes the approach viable for real client environments where data exposure is not an option.
Reducing Hallucinations Through Design (4:08 – 4:35)
By grounding the AI in schema and business logic rather than raw data, the system is designed to generate accurate queries more consistently. When the AI does hallucinate, the result is a query that simply fails to run, making the error immediately visible rather than silently producing a wrong answer. That failure mode is intentional and useful.
Developer Productivity as the Primary Goal (5:03 – 5:29)
The clearest value Celeste offers is helping developers get oriented in complex, unfamiliar databases faster. Even if an initial query needs manual refinement, having accurate table and column references as a starting point significantly reduces the time spent on exploration before any real work can begin.
Current Status: Experimental and Internal (0:36 – 0:53)
Celeste is not a product for sale. It is an internal initiative designed to help Blue Margin teams develop firsthand experience with AI integration in real data environments. The team is treating it as a learning exercise as much as a productivity tool, with a planned rollout to internal developers within the next week or two at the time of recording.
Who It’s For
This episode is worth your time if you are a data engineer or analyst who regularly works with unfamiliar databases and wants to understand how AI tooling might reduce that onboarding overhead, a technology leader evaluating how to introduce AI into your team’s existing workflows without exposing sensitive data, a developer curious about the practical architecture decisions behind a natural language to SQL tool, or anyone building internal AI tools and looking for a realistic account of what early-stage development actually looks like.
Why It’s Worth a Listen
Most AI product coverage focuses on capabilities at launch, after the hard decisions have already been made and the rough edges have been smoothed over. This episode is different. Landon and Mark are talking about a tool that is still being built, and the conversation reflects that: specific, technical, and unpolished in the best way.
The privacy-first architecture is worth particular attention. The decision to work with metadata rather than raw data is not just a compliance choice. It is a practical one that makes the tool more reliable and more scalable across different client environments. Understanding why that decision was made and what it enables is useful for anyone designing AI integrations where data sensitivity is a real constraint.
And the honest framing around hallucinations is refreshing. Rather than treating them as a problem to be eliminated, the team has designed around them in a way that makes failures obvious and correctable. That kind of pragmatic thinking about AI limitations is more useful than the assumption that the model will just get it right.
