TextQL Advances Ontology Engine to Automate Data Analytics Verification

The Analytics Factory: Building the Machine That Understands Your Business With TextQL — Ai4

Ai4

Traditional semantic layers fail to validate novel business questions, necessitating version-controlled ontologies as code to achieve automated verification in AI data loops.

AI-assisted summary of The Analytics Factory: Building the Machine That Understands Your Business With TextQL — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 19, 2026, this presentation features Benjamin Shi, VP of Growth & Strategy at TextQL. According to the page description, the talk examines the concept of the analytics factory, explaining how ontology as code serves as the blueprint for AI agents and why automated verification is the critical bottleneck in AI analytics.

## TL;DR The presentation argues that the modern data stack functions like a slow, manual assembly line that lacks effective verification loops for business logic. While software engineering has advanced into automated 'loop engineering' using compilers and automated testing, data analytics still relies on human spot-checks for semantic correctness. By implementing an 'ontology as code' framework—operationalized through TQL files—organizations can establish a true business compiler that automatically verifies entity grains, relationships, and business rules, enabling reliable AI-driven analytics factories.

## Atmosphere & style The presentation carries a sharp, authoritative, and forward-looking tone characteristic of an executive technical keynote. Shi delivers his insights with structured, logical precision, using clear conceptual diagrams to contrast software engineering paradigms with data analytics pipelines. Watching the talk feels like an intellectually engaging architectural briefing that demystifies current AI limitations while offering a systematic blueprint for modern enterprise data infrastructure.

## Key takeaways - [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) Software engineering paradigms evolved rapidly from Prompt Engineering in 2023 to Loop Engineering in 2026, focusing on validating LLM output and iteratively executing tasks. - [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) The four-step execution cycle for software loops consists of Assemble Context, Act, Verify, and Decide. - [01:48](https://www.youtube.com/watch?v=KDms50mACvY&t=108s) Automated verification is the core unlock that enables autonomous software loops and transforms development into a software factory. - [01:48](https://www.youtube.com/watch?v=KDms50mACvY&t=108s) Software development is transitioning from 'Lit Factories' (with human inspection) toward 'Dark Factories' (fully automated end-to-end execution without human intervention). - [03:14](https://www.youtube.com/watch?v=KDms50mACvY&t=194s) The modern data engineering stack operates as a rigid, manual assembly line without feedback loops, requiring new datasets to restart the entire pipeline from scratch. - [04:34](https://www.youtube.com/watch?v=KDms50mACvY&t=274s) Data loops fail because standard query verification checks syntax and execution, but lacks automated verification for semantic definitions, grain alignment, and business intent. - [04:34](https://www.youtube.com/watch?v=KDms50mACvY&t=274s) Traditional semantic layers act as closed-world systems that only validate pre-defined, anticipated metrics rather than answering novel, exploratory questions. - [07:15](https://www.youtube.com/watch?v=KDms50mACvY&t=435s) Ontology as code serves as a compiler for business meaning, structuring entities/relationships, business logic, and population constraints to verify arbitrary queries. - [07:15](https://www.youtube.com/watch?v=KDms50mACvY&t=435s) TextQL integrates ontology into the execution loop during context assembly and post-execution verification to check join grains, metric definitions, and cardinality. - [10:13](https://www.youtube.com/watch?v=KDms50mACvY&t=613s) Ontologies can be auto-compiled by ingesting existing data artifacts, query logs, BI definitions, and documentation, updating dynamically as novel patterns emerge. - [10:13](https://www.youtube.com/watch?v=KDms50mACvY&t=613s) The TQL file format unifies plain-English documentation, executable logic, and warehouse-level access permissions into a single artifact to provide AI locality. - [10:13](https://www.youtube.com/watch?v=KDms50mACvY&t=613s) Structuring the ontology as version-controlled code in Git allows metric definitions to be managed via pull requests across complex enterprise data estates.

## Detailed walkthrough ### [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) The Evolution of Software Engineering Loops

Ben Shi, who leads growth and strategy at TextQL, introduces himself and his background, having spent five years at Blackstone managing firm-wide data and AI infrastructure initiatives while serving as a venture partner with Snowflake Ventures. He posits that the dramatic transformation observed in software engineering over the last four years is about to strike the data field, though a critical missing piece currently stands in the way.

To illustrate this transformation, he traces the rapid progression of software engineering paradigms over recent years: * **2023:** *Prompt Engineering* — focused purely on crafting the right prompt for the LLM. * **2024:** *Context Engineering* — focused on shaping and expanding what the model knows. * **Late 2024 / Early 2025:** *Harness Engineering* — equipping models with tools and giving them the autonomy to execute tasks. * **Present (2026):** *Loop Engineering* — shifting focus from whether a model can perform a task to validating its output, feeding the result back into the system, and letting it execute iteratively.

Every software loop follows a four-step execution cycle:

``` +-------------------+ +-------------------+ | Assemble Context | --> | Act | +-------------------+ +-------------------+ | v +-------------------+ +-------------------+ | Decide | <-- | Verify | +-------------------+ +-------------------+ ```

- **Assemble Context:** Gathering relevant files, specifications, and context. - **Act:** Writing code and invoking API calls. - **Verify:** Checking the output for syntax errors, structural defects, or behavioral mismatches. - **Decide:** Determining whether to retry, pay, or ship to production.

---

[01:48](https://www.youtube.com/watch?v=KDms50mACvY&t=108s) Software Verification and Factory Autonomy

The third step—**Verify**—is the foundational unlock that makes the entire autonomous software loop possible. Models were capable of writing code long before anyone trusted them to do so in production. The key difference in software is that the discipline spent 50 years making the question "Is this correct?" cheap, automated, and machine-checkable. Compilers automatically catch structural errors, automated tests verify behavior against intent, and the vast majority of flawed outputs die inside the loop before a human ever sees them.

When this verification loop is executed thousands of times across tasks, it transforms software development into a software factory. Borrowing terminology from modern manufacturing, Shi draws a distinction between two operating models: - **Lit Factory:** Human operators remain on the floor. While autonomous agents and machines execute the work, a human manually inspects and reviews whatever survives the automated verification gates before deployment. - **Dark Factory:** Operates with the "lights off"—zero human involvement on the floor because the automated end-to-end verification process is entirely trusted.

Most software engineering teams currently run "lit" factories where developers review what passes automated testing, but the industry trajectory points firmly toward running darker factories as verification quality improves.

---

[03:14](https://www.youtube.com/watch?v=KDms50mACvY&t=194s) The Modern Data Stack's Manual Assembly Line

When contrasting software development with data analytics, the modern data engineering pipeline resembles a fragmented, highly manual assembly line rather than an automated factory.

``` +------------------+ +------------------+ +------------------+ +------------------+ | Centralize Data | --> | Model into | --> | Write Semantic | --> | Wire to MCP / | | (Months/Quarters)| | Marts (Medallion| | Layer (Manual) | | Hope Agent Works | +------------------+ +------------------+ +------------------+ +------------------+ | ( NO FEEDBACK LOOP) <---------------------------+ ```

Before an organization can query a new dataset, it traverses four rigid steps: 1. **Centralize Data:** Ingesting and centralizing raw datasets, which routinely takes months or quarters. 2. **Model into Marts:** Structuring data through medallion architectures (bronze, silver, gold layers) into data marts. 3. **Write Semantic Layer:** Data analysts or AI engineers handwrite metric definitions one by one. 4. **Wire to MCP:** Exposing the semantic layer to Model Context Protocol (MCP) servers and hoping an AI agent interprets it correctly.

Every stage and handoff requires manual human effort and consumes real calendar time. Crucially, no feedback loop exists—learnings from a single dataset do not make the next dataset any easier or faster to process, forcing every new data request to start back at step one.

---

[04:34](https://www.youtube.com/watch?v=KDms50mACvY&t=274s) The Verification Failure in Data and Semantic Layer Limits

Analyzing why software loops closed while data loops failed reveals a fundamental gap in verification gates. In a standard SQL query lifecycle: - **Syntax Check:** Verified by a gate (Pass). - **Execution Check:** Verified by a gate (Pass). - **Table Structure Check:** Verified by a gate (Pass). - **Semantic Definitions** (e.g., Is "active customer" defined correctly?): Unchecked / Dashed gate. - **Grain & Join Alignment:** Unchecked / Dashed gate. - **Intent Mismatch** (Did it actually answer the business question?): Unchecked / Dashed gate.

``` Query ---> [ Syntax ] ---> [ Execution ] ---> [ Table Form ] - - -> [ Semantic Def ] - - -> [ Join Grain ] - - -> Decision (Pass) (Pass) (Pass) (Unchecked) (Unchecked) ```

Because semantic gates have never been automated, the only check between a running query and an executive business decision is a human looking at a dashboard and declaring, "That looks right to me." This is not merely a maturity gap; data analytics has historically lacked a true compiler for business meaning.

While semantic layers act like data contracts that verify predetermined metrics well (e.g., approved metrics like `revenue by region` or `churn rate`), they operate as **closed-world systems**. They only validate questions that engineers anticipated in advance. When a business user asks an exploratory, ad-hoc question outside the catalog—such as *"What is our margin by cohort, excluding pilots?"*—the semantic layer does not fail loudly; it simply has nothing to say.

In contrast, a true compiler does not store a list of pre-approved programs. It encodes the underlying rules of the language itself, enabling it to check and validate completely novel programs it has never encountered before.

- Traditional semantic layers provide a static list of pre-approved answers. - A true business compiler provides rules against which *any* novel answer can be algorithmically verified.

---

[07:15](https://www.youtube.com/watch?v=KDms50mACvY&t=435s) Ontology as Code: A Compiler for Business Meaning

To solve this gap, enterprise analytics is shifting toward ontologies—a mechanical, formal type system for business operations. An ontology acts as a compiler across three structured layers:

1. **Entities & Relationships:** Pre-declares entity grains and cardinalities, preventing fan-out joins that silently double revenue numbers. 2. **Business Logic as Rules:** Establishes composable definitions (e.g., defining "active customer" through explicit rule constraints rather than saved queries), stopping AI agents from inventing metrics on the fly. 3. **Constraints & Population Filters:** Enforces valid populations, unit conversions, and regional filters that any valid query must respect.

Applying this ontology compiler inside the 4-step loop (**Context $\rightarrow$ Act $\rightarrow$ Verify $\rightarrow$ Decide**) provides the missing automated verification mechanism.

``` +-----------------------------------------------------------------------------------+ | TextQL Ontology | | +------------------------+ +-------------------------+ +--------------------+ | | | Entities/Relationships | | Business Logic & Rules | | Constraints/Filters| | | +------------------------+ +-------------------------+ +--------------------+ | +-----------------------------------------------------------------------------------+ | (Context In) ^ (Verify Out) v | +------------------+ +------------------+ +------------------+ | Assemble Context | -----> | Act | ---------> | Verify | +------------------+ | (SQL/Python Push)| | (Check Grain/ | +------------------+ | Joins/Rules) | +------------------+ | v +------------------+ | Decide | | (Dashboards/Apps)| +------------------+ ```

TextQL operationalizes this via two main integration points: - **On Context Assembly:** Supplies the tables, lineage, and domain definitions an AI agent needs to interpret a query. - **On Verification:** Validates the generated SQL's join grain, metric definitions, and cardinality against the business model on every single pass before passing results to dashboards, playbooks, or data apps.

---

[10:13](https://www.youtube.com/watch?v=KDms50mACvY&t=613s) Self-Building Ontologies, TQL Files, and Portability

Building an ontology does not require an expensive, manual greenfield modeling project. TextQL's engine auto-compiles the ontology by ingesting existing raw enterprise artifacts—warehouse schemas, historical query logs, BI tool definitions, and internal documentation accumulated over years.

As queries are executed, the ontology learns dynamically. When definitions drift or novel query patterns emerge, agents propose ontology updates that a human admin can review and approve, shifting human labor from manual pipeline maintenance to managing the analytics factory.

The atomic building block of this ontology is a file format called **TQL**.

``` +------------------------------------------------------------------+ | TQL File | |------------------------------------------------------------------| | 1. Plain-English Documentation (Semantic meaning & parameters) | | 2. Executable Logic (Parameterized SQL) | | 3. Warehouse-Level Access (RBAC & Security permissions) | +------------------------------------------------------------------+ ```

Traditional data stacks scatter these elements across disparate systems—documentation lives in a wiki, business logic in BI tools, and permissions in database settings. TQL unifies all three into a single file artifact, providing "AI locality" where human reviewers and AI agents evaluate meaning, code, and access control in one place.

Because TQL structures the ontology as code files, it integrates with modern software toolchains: - Version-controlled in Git repos. - Metric updates (e.g., redefining `active_customer`) ship via pull requests with peer review. - Highly portable across complex enterprise data estates (e.g., spanning 38,000+ disparate table columns across dozens of legacy systems).

- The ontology acts as a single centralized abstraction layer compiling downstream into data models, pipeline configs, dashboards, data apps, playbooks, scheduled reports, and autonomous agents. - Ben Shi concludes by referencing his technical article, *"Semantic layers are a patch. Ontologies are the fix,"* and invites attendees to connect at `benjamin@textql.com` or `she@textql.com`.

## Video description Benjamin Shi - VP, Growth & Strategy, TextQL

AI can build software faster. But that does not mean it builds better software.

The software industry’s answer is not better prompts. It's the software factory: a system built around better blueprints. Define what good looks like once, and AI can build toward it, test its work, and improve over time. The blueprint becomes the asset. The code becomes an output.

Data is next, but the modern data stack was built for an older model of analytics. It resembles an early assembly line: fixed stages, manual handoffs, fragmented context, and weeks of cycle time. It was built for questions you can anticipate, not for exploration that moves freely across the business.

The next model is the analytics factory. Its foundation is ontology as code: a single, version-controlled definition of the business that storage, pipelines, metrics, dashboards, playbooks, and agent workflows can all build from. Change the definition once, and the factory retools around it.

This talk explores what an analytics factory looks like in production: how the ontology becomes the blueprint AI agents work against, why verification rather than generation is the real bottleneck in AI analytics, and what it takes to move beyond a stack built for predetermined questions.

[Source](https://www.youtube.com/watch?v=KDms50mACvY)

中文简报

TextQL推进本体引擎以实现数据分析自动化验证 传统语义层无法验证全新的业务问题，因此需要受版本控制的“本体即代码”在AI数据循环中实现自动化验证。 该演讲指出，现代数据栈的运作方式犹如一条缓慢的人工流水线，缺乏针对业务逻辑的有效验证闭环。尽管软件工程已借助编译器和自动化测试迈向自动化的“循环工程”，但数据分析在语义正确性上仍依赖人工抽检。通过实施以TQL文件落地的“本体即代码”框架，企业可以构建真正的业务编译器，自动验证实体粒度、实体关系和业务规则，从而打造可靠的AI驱动型分析工厂。 软件工程范式从2023年的提示词工程迅速演进至2026年的循环工程，重点转向验证LLM输出和迭代执行任务。 (0:08) 软件循环的四步执行周期由组装上下文、行动、验证和决策构成。 (0:08) 自动化验证是实现自主软件循环并将开发转化为软件工厂的核心关键。 (1:48) 软件开发正从“有人巡检的工厂”（包含人工检查）向“黑灯工厂”（无需人工干预的全自动端到端执行）转变。 (1:48) 现代数据工程栈如同僵化且缺乏反馈回路的人工流水线，一旦出现新数据集就需要从头重启整条流水线。 (3:14)

Reading summary

Ben Shi of TextQL argues that applying autonomous software engineering loops to enterprise data requires moving beyond closed-world semantic layers to formal business ontologies that serve as automated verification compilers. Software Automation Powered by Automated Verification (0:08) Shi outlines the progression of software engineering paradigms from prompt engineering in 2023 to context engineering in 2024, harness engineering in late 2024 and early 2025, and loop engineering by 2026. This loop operates through a four-step cycle: Assemble Context, Act, Verify, and Decide. Shi identifies the verification step as the foundational unlock for autonomy. Because software engineering spent fifty years making correctness machine-checkable via compilers and automated tests, defective outputs are caught inside the loop before reaching humans. Over time, this continuous verification cycle transforms software development into a factory model. Shi distinguishes between 'lit factories,' where human developers manually inspect outputs that clear automated test gates, and 'dark factories,' which operate with zero floor-level human intervention because the automated end-to-end verification process is fully trusted. The Verification Breakdown in Traditional Data Pipelines (4:34) In contrast to software development, Shi describes the modern data stack as a fragmented, manual assembly line. Centralizing data, modeling it into medallion data marts, handwriting metric definitions, and exposing them to Model Context Protocol (MCP) servers consumes calendar months and lacks an iterative feedback loop. While standard data pipelines verify SQL syntax, execution, and table structures, they lack automated gates for semantic definitions, join grain alignment, and business intent. As a result, manual human inspection of dashboards remains the sole check before executive decisions. Shi contends that traditional semantic layers operate as closed-world systems that only validate pre-cataloged metrics like churn rate or regional revenue. When users ask ad-hoc exploratory questions outside the catalog—such as margins by cohort excluding pilots—semantic layers fail silently rather than acting like a true programming compiler that evaluates arbitrary, novel logic against foundational language rules. Business Ontologies as Rules-Based Verification Compilers (7:15) To address this gap, TextQL proposes using enterprise ontologies as a mechanical, formal type system for business operations. This ontology functions across three structural layers: entities and relationships with pre-declared grains and cardinalities to stop fan-out joins from duplicating revenue figures; composable business logic rules that prevent AI agents from hallucinating metric definitions; and population constraints enforcing valid unit conversions and geographic filters. Integrated into the four-step loop, the ontology serves two roles. During context assembly, it supplies the necessary tables, lineage, and domain definitions. During verification, it algorithmically inspects generated SQL against the business model's join grains, metric definitions, and cardinality rules on every pass before passing results to downstream dashboards, playbooks, or data applications. Automating Ontology Construction via Portable TQL Files (10:13) Shi asserts that constructing an enterprise ontology does not require greenfield manual modeling. TextQL's engine auto-compiles the initial model by ingesting existing warehouse schemas, historical query logs, BI definitions, and internal documentation. As business definitions drift or novel queries arise, autonomous agents propose ontology updates for human administrators to review and approve, shifting human effort from manual pipeline maintenance to factory oversight. The atomic unit of this ontology is a file format called TQL. While traditional stacks disperse documentation across wikis, logic across BI tools, and permissions across database settings, TQL unifies plain-English documentation, parameterized SQL, and warehouse-level role-based access control into a single artifact. Stored as code, TQL files integrate into Git workflows, allow metric adjustments via pull requests, and support portability across enterprise estates spanning tens of thousands of columns across legacy systems. Shi concludes that ontologies provide the essential centralized abstraction layer required to reliably compile downstream data applications, reports, and autonomous agents, characterizing traditional semantic layers as merely a temporary patch.

精炼阅读摘要

TextQL增长与战略负责人Ben Shi指出，软件工程已通过低成本的自动化验证闭环迈向工厂化，而现代数据栈因缺乏针对业务语义的机器可查编译器，仍停留在碎片化的人工装配线模式。他主张将“本体即代码”（Ontology as Code）作为业务编译器，填补数据领域的验证缺口，从而构建真正自主的分析工厂。 软件工程闭环与自动化工厂演进 (0:08) Ben Shi回顾了近四年软件工程范式的快速演变：从2023年的提示工程（Prompt Engineering）、2024年的上下文工程（Context Engineering），演化到2024年末至2025年初的框架工程（Harness Engineering），并进入2026年以闭环迭代为核心的循环工程（Loop Engineering）。每个自主循环均包含组装上下文（Assemble Context）、行动（Act）、验证（Verify）和决策（Decide）四步。软件学科历经50年建设，使验证环节变得廉价且可机器自动化检查，绝大多数缺陷在人工介入前即被编译器或自动化测试拦截。 这种验证能力使软件开发走向工厂化模式。Shi将软件工厂划分为两类：一类是当前绝大多数团队采用的有灯工厂（Lit Factory），机器执行大部分工作，但人类需对通过自动化测试的产物进行最终审查；另一类则是完全不需要人工在场的无灯工厂（Dark Factory），全流程完全依赖高置信度的端到端验证。随着验证质量提升，软件工程整体正朝着无灯工厂的方向演进。 数据栈断环与传统语义层局限 (3:14) 与软件工程相比，现代数据栈依然呈现出高度手动的单向装配线形态。组织在查询新数据集时，必须耗费数月或数个季度经历数据集中、分层建模（如铜、银、金牌架构的数据集市）、人工编写语义层指标，最后接入MCP（Model Context Protocol）服务器并寄希望于AI智能体正确理解。各环节严重依赖人工交接且缺乏反馈机制，历史数据集的处理经验无法加速新任务，导致每次需求都必须从头开始。 Shi分析认为，数据领域循环断裂的核心在于语义验证闸门的缺失。传统的SQL引擎仅能检查语法、执行状态和表结构，却完全无法核实业务定义（如活跃客户的确切口径）、颗粒度与连接匹配，以及是否回应了实际商业意图。由于缺乏针对业务含义的“编译器”，最终结果往往只能靠人工审视看板主观判断。传统的语义层仅属于封闭系统（Closed-world System），只能校验工程师预设的静态指标；一旦业务提出探索性或未收录的即席问题，语义层无法算法化地报错或校验，暴露出其作为过渡修补手段的局限性。 以本体作为业务编译器的自动化闭环 (7:15) 为了实现自主的数据分析循环，需要引入本体作为企业业务运作的形式化类型系统与语义编译器。该本体在架构上分为三层：一是预先声明实体颗粒度与基数的实体与关系层，杜绝导致收入重复计算的扇出连接（Fan-out Joins）；二是业务逻辑与规则层，通过组合规则定义核心指标，防止AI随机发明指标；三是约束与过滤层，在底层强制执行有效人群筛选与单位换算。 在TextQL的设计中，本体编译器被深度嵌入至“上下文-行动-验证-决策”循环的两端。在上下文组装阶段，本体为智能体提供准确的表结构、血缘关系与领域定义；在验证阶段，本体在SQL或Python生成后，逐次检验其连接颗粒度、指标定义和数据基数。只有完全通过业务模型验证的结果，才会被推送至下游看板、行动手册或数据应用，以此替代脆弱的人工作业检查。 TQL文件化架构与自构建机制 (10:13) 本体的落地无需推倒重来开展高成本的手工建模工程。TextQL通过摄取企业现有的数仓架构、历史查询日志、BI工具元数据以及内部文档，自动编译并初始化本体。在日常查询运转中，当指标口径发生偏移或出现全新查询模式时，系统会自动学习并提议更新，由数据管理员集中审核批准，将人类劳动力从繁琐的流水线维护转变为对分析工厂的管控。 该方案将单一TQL文件作为原子构建模块，将原本分散在各处的自然语言文档、参数化SQL可执行逻辑以及数仓级访问控制（RBAC与安全权限）整合为一体，构建起高内聚的“AI局部性”（AI Locality）。TQL文件使本体能够像代码一样纳入Git进行版本管理，指标变更支持拉取请求（PR）与同行评审，并能跨越企业数万列异构数据表完成统一抽象，向下编译并驱动数据管道、报表与各类自主智能体。 Ben Shi主张，传统的语义层仅是应对指标混乱的临时修补，而基于代码的本体才是从根本上解决业务验证难题的路径。然而，企业在数十种遗留系统和复杂历史数据上自动提取与校准规则时，如何确保自构建本体的初始准确性，并平滑承接既有数据治理流程，仍是企业实际落地过程中需要持续检验的工程挑战。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 19 日发布，由 TextQL 增长与战略副总裁 Benjamin Shi 进行主题演讲。视频简介指出，数据分析领域正从传统的手工装配线模式转向以“代码化本体（Ontology as Code）”为核心的分析工厂，旨在突破传统固定问答模式的限制，解决 AI 分析中真正的瓶颈——验证机制。 ## TL;DR 演讲指出软件工程已迈向以自动化校验为核心的“闭环工程”，而传统数据栈因缺失业务语义的编译器，导致 AI 难以在没有人类肉眼审核的情况下可靠运转。TextQL 提出“分析工厂（Analytics Factory）”概念，利用多层架构的“本体（Ontology）”充当企业的类型系统，从而对任意未经预设的复杂业务查询进行粒度与逻辑编译。通过将自然语言、参数化 SQL 和权限控制融合为 Git 版本受控的 TQL 文件，系统能够自动构建、学习并自维护，构建起可信的数据自动化验证闭环。 ## Atmosphere & style 演讲展现出理性、严谨且极具行业洞察力的技术叙事风格。主讲人结合其在黑石集团与 Snowflake Ventures 的一线工程经验，以制造业“装配线”与“黑灯工厂”为生动隐喻，层层剖析传统语义层的封闭缺陷。整场演讲逻辑推进紧凑从容，从对行业痛点的犀利诊断平滑过渡到底层架构方案的推演，传递出重塑企业数据范式的高度自信与笃定。 ## Key takeaways - [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 软件工程的 AI 范式经历了从提示词工程、上下文工程、工具调用到闭环工程（Loop Engineering）的演进，核心瓶颈已从模型生成能力转向结果验证机制。 - [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 软件工程能够实现自动化“软件工厂”并迈向“黑灯工厂”，关键在于拥有编译器和自动化测试，将代码正确性转变成低成本且可由机器自动校验的问题。 - [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 传统数据栈仍处于早期手工装配线阶段，从数据清洗、集市建模、语义层配置到 MCP 接入周期漫长，且各环节之间完全缺失反馈循环。 - [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 数据分析领域存在致命的“语义验证断层”：一条查询能够成功执行并返回规整数据，丝毫不代表其 Join 粒度、业务定义和逻辑是正确的。 - [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 现有语义层本质上是“封闭世界”清单，只能校验预先批准的静态问题，无法对探索性、未预料到的即席业务提问进行通用校验。 - [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 本体（Ontology）是企业的“类型系统”，通过实体关系、业务规则与约束层，扮演着如同编程语言编译器一样的角色，能够校验任意未见过的查询逻辑。 - [08:33](https://www.youtube.com/watch?v=KDms50mACvY&t=513s) TextQL 分析工厂将闭环工程平移至数据资产，以本体作为核心编译器，输入端注入业务上下文，输出端对模型生成的粒度和逻辑进行循环编译校验。 - [08:33](https://www.youtube.com/watch?v=KDms50mACvY&t=513s) TextQL 本体具备自构建与自学习能力，能从数仓 Schema、历史查询日志和文档中自动编译生成，并通过 Agent 提交 PR、人类审核的方式持续维护。 - [08:33](https://www.youtube.com/watch?v=KDms50mACvY&t=513s) TQL 文件格式将业务自然语言、参数化 SQL 逻辑与仓储级 RBAC 权限熔铸为单一原子工件，全面支持 Git 版本控制与指标审查流程。 - [14:07](https://www.youtube.com/watch?v=KDms50mACvY&t=847s) 分析工厂（Analytics Factory）的实现标志着数据领域终于拥有了属于自己的业务编译器，使 AI 数据智能体能够基于统一可信的蓝图稳定交付。 ## Detailed walkthrough ### [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 软件工程的演进：从提示词工程到“闭环工程” TextQL 增长与战略副总裁 Ben Shi（此前曾在黑石集团（Blackstone）深耕数据与 AI 基础设施达五年之久，并曾担任 Snowflake Ventures 的投资合伙人）指出，过去四年软件工程领域经历了一场深刻的范式变革，而这一转变即将发生在数据领域。软件工程的 AI 演进历程经历了四个清晰阶段：2023 年的核心是**提示词工程（Prompt Engineering）**，专注于精心构建发送给大语言模型（LLM）的指令；2024 年演进至**上下文工程（Context Engineering）**，重点在于塑造模型所掌握的背景知识；随后一年多前扩展到**工具调用工程（Harness Engineering）**，赋予模型使用工具和自主行动的能力；如今行业的前沿则落脚在**闭环工程（Loop Engineering）**。此时的核心问题不再是“模型能否完成任务”，而是“我们能否验证模型的产出、将结果反馈回去并让它反复迭代运行”。 ```mermaid flowchart LR accTitle: 闭环工程的四个阶段 A["装配上下文<br/>(Assemble Context)"] --> B["执行动作<br/>(Act: Code/API)"] B --> C["验证结果<br/>(Verify)"] C --> D{"决策分支<br/>(Decide)"} D -- 重试 --> A D -- 交付/上线 --> E["产出结果<br/>(Ship)"] ``` 闭环工程由四个核心步骤构成：装配上下文（Assemble Context）、通过编写代码或调用 API 执行动作（Act）、验证结果（Verify）、最后做出重试或直接交付的决策（Decide）。Ben 强调，整个闭环的解耦关键在于第三步——**验证（Verify）**。大模型在很久以前就能编写代码，但软件工程之所以能将闭环跑通，是因为软件行业耗费了整整 50 年时间，将“这段代码是否正确？”变成了一个极低成本且可由机器自动校验（machine-checkable）的问题：编译器能自动捕获结构性语法错误，自动化测试能对照业务意图检验行为，绝大多数错误答案在触达人类之前就死在了这个验证闭环内。单次运行这个闭环是自动化，当跨任务运行成千上万次时，它就构成了现代**软件工厂（Software Factory）**。 借用制造业的概念，自动化工厂可分为“开灯工厂（Lit Factory）”与“黑灯工厂（Dark Factory）”。开灯工厂中机器在作业，但现场依然有人类负责巡检下线的成品；而黑灯工厂则完全无需人类介入，因为端到端的验证机制获得了绝对信任。当前绝大多数软件团队运行在“开灯”状态——AI 循环做功，工程师审核通过验证卡口的产出。然而演进方向非常明确：校验机制越受信任，人类需要介入的环节就越少，工厂就越能走向“黑灯”。工厂的黑暗程度，直接取决于验证能力的完备程度。 --- ### [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 传统数据栈的困境：手工装配线与缺失的“验证编译器” 与高度自动化的软件工程相比，企业数据领域目前的现状仍如同一条完全依赖手工的早期装配线。在黑石及其众多被投企业的工作经历让 Ben 深刻体会到这一点：当业务部门想对新数据集提问时，首先需要经历数月甚至数个季度的集中化清洗与迁移；随后工程师按照奖章架构（Medallion Architecture，铜/银/金层）将其建模为数据集市（Data Marts）；接着由 AI 工程师或数据分析师手动逐一编写语义层（Semantic Layer）来定义指标；到了 2025、2026 年，团队又加上了第四步——通过模型上下文协议（MCP, Model Context Protocol）将其接入，并“祈祷”AI 智能体能够正确使用它。 ```mermaid flowchart TD accTitle: 传统数据处理管线与验证断层 subgraph S1["传统数据装配线（耗时长、无反馈循环）"] D1["数据集中化<br/>(数月/数季度)"] --> D2["数据集市建模<br/>(奖章架构)"] D2 --> D3["手工编写语义层<br/>(逐个定义指标)"] D3 --> D4["接入 MCP<br/>(祈祷 Agent 正确使用)"] end subgraph S2["查询验证断层对比"] Q1["语法正确？<br/>(有效卡口 ✓)"] --> Q2["能否执行？<br/>(有效卡口 ✓)"] Q2 --> Q3["返回规整数据表？<br/>(有效卡口 ✓)"] Q3 -.-> Q4["'活跃客户'定义正确？<br/>(虚线缺失卡口 ✗)"] Q4 -.-> Q5["Join 粒度是否匹配？<br/>(虚线缺失卡口 ✗)"] Q5 -.-> Q6["是否回答了真实问题？<br/>(虚线缺失卡口 ✗)"] end ``` 这种传统模式存在两大致命缺陷：第一，每个步骤与交接全凭手工，每一次状态流转都消耗漫长的日历时间；第二，管线底部从未形成任何**反馈循环（Feedback Loop）**，在单个数据集上积累的经验无法降低下一个数据集的处理成本，面对新数据只能从第一步从头来过。 数据闭环之所以无法闭合，根本原因在于**语义验证卡口的缺失**。追踪一条 SQL 查询从产生到执行的过程： - **语法是否有效？**（已有卡口，轻松通过） - **查询能否运行？**（已有卡口，顺利通过） - **是否返回了结构完备的数据表？**（已有卡口，通过） - **“活跃客户”的定义是否准确？**（卡口缺失） - **表关联（Join）的计算粒度（Grain）是否正确？**（卡口缺失） - **它是否真正解答了业务所提出的实际问题？**（卡口缺失） 能够成功运行的查询，丝毫不代表其业务逻辑的正确性。在当今的企业环境中，阻隔在错误查询与最终业务决策之间的唯一防线，竟然只是人类看着仪表盘说一句“我觉得看起来差不多”。这并非单纯的成熟度滞后，而是因为数据学科历史上从未拥有过一套能够针对“业务语义与含义”进行校验的**编译器（Compiler）**。 --- ### [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 语义层 vs 本体（Ontology）：封闭世界目录与业务类型系统 许多人会认为现有的语义层（Semantic Layer）已经承担了验证职责。语义模型确实能充当极佳的数据契约，但它本质上是一个**封闭世界（Closed World）**目录：只要提问预先定义在目录中（如“按区域划分的收入”、“活跃用户数”、“客户流失率”），它在运行时就能进行精准校验。然而，对话式数据分析的全部价值，恰恰在于解答那些**事先未被预料到的问题**——例如在某个周二下午突然提出的业务探索需求：“按群组（Cohort）拆分利润率，并排除试用期客户（Pilots）”。当问题超出目录范围时，语义层并不会显式报错，而是直接失声沉默。 编译器的工作机制与此截然相反：它即便从未见过你的程序代码，也能依据编程语言本身的语法与类型规则完成全面检查，而不是仅仅比对一份“预先批准的程序清单”。数据领域在过去两年积累了大量“已批准的答案清单”，却从未拥有过“能校验任意答案的通用规则系统”。这正是**本体（Ontology）**的用武之地。 本体绝非抽象比喻，它在机械层面就是**企业的类型系统（Type System for the Business）**。通过本体的多层架构，即使是从未被提出过的复杂问题也能被严格编译校验： 1. **实体与关系层（Entities and Relationships）**：提前显式声明数据粒度（Grain）与基数（Cardinality），能够直接捕获诸如扇出关联（Fan-out Join）等暗中将收入数据凭空翻倍的低级逻辑错误。 2. **业务逻辑规则层（Business Logic as Rules）**：将“活跃客户”等核心指标定义为可组合的业务规则而非静态保存的查询，防止 AI 智能体根据不同过滤条件自行胡乱捏造定义。 3. **约束层（Constraints）**：硬性规定查询必须遵守的有效样本群（Population）、过滤条件、度量单位与换算规则。 --- ### [08:33](https://www.youtube.com/watch?v=KDms50mACvY&t=513s) TextQL 的本体架构与 TQL 文件格式：打造自构建的分析工厂 将闭环工程（Context → Act → Verify → Decide）平移至数据资产时：上下文来自表结构、血缘关系与历史查询；执行动作是通过将 SQL 下推至数据仓库或运行 Python 分析；决策是重试、输出答案或上报；而核心的破局点就是 TextQL 历时三年打造的**TextQL 本体（TextQL Ontology）**。该本体在闭环中承担两项关键职能：在输入端注入智能体解析问题所需的表引用、血缘与定义上下文；在输出端针对模型每一轮生成的计算粒度、表关联与逻辑进行严格编译校验，循环往复直至生成完全经验证的数据应用、仪表盘、业务手册（Playbooks）或自主智能体。 ```mermaid flowchart TB accTitle: TextQL 分析工厂运作架构 subgraph Inputs["输入源（历史资产积累）"] I1["数仓 Schema"] I2["查询日志 Query Logs"] I3["BI 报表定义"] I4["企业文档 Wiki"] end subgraph Core["TextQL 核心引擎"] O1["自编译生成本体<br/>(Self-Building)"] TQL["TQL 文件原子单位<br/>• 业务自然语言 (AI Locality)<br/>• 参数化 SQL 计算逻辑<br/>• 仓储级 RBAC 权限配置"] O2["自学习与维护<br/>(Agent 提 PR + 人工审核)"] end subgraph Outputs["分析工厂输出成果 (Git 版本受控)"] OUT1["数据管道配置"] OUT2["动态仪表盘 / 数据应用"] OUT3["分析 Playbooks / 调度报表"] OUT4["自主数据 Agent"] end Inputs --> O1 O1 --> TQL TQL --> O2 TQL --> Outputs ``` 针对“构建本体是否只是将手动工作转移了阵地”的疑问，TextQL 采用了完全不同的自动化路径： - **本体自构建（Self-Building）**：直接连接企业现有系统，从数仓 Schema、历史查询日志、BI 定义及文档等沉淀多年的原始材料中自动编译出本体，无需从零开展繁重的手动绿地建模（Greenfield Modeling）。 - **本体自学习与自维护（Learns with You）**：团队提出的每一次查询都会使系统更敏锐。当业务定义发生漂移时，智能体会主动提出本体更新建议（Proposal），由管理员审核批准。这相当于工厂在自主维护其验证器，人类的工作从装配线苦力升格为分析工厂的管理者。 本体的物理原子单位是一种名为 **TQL** 的文件格式（每个 TQL 文件代表一个语义模型）： - **顶部自然语言（Plain Language）**：用直白语言向人类与 AI 解释数字背后的业务含义，充当内联文档。 - **参数化计算逻辑（SQL Logic）**：包含底层具体执行、已参数化且随时可运行的 SQL。 - **权限控制（RBAC Permissions）**：在数据仓库层面直接强制执行的角色访问控制。 传统数据栈将这三者割裂在 Wiki 文档、BI 工具与外部权限系统三套独立体系中，而 TQL 将其熔铸为单一工件，实现了专为 AI 局部性（AI Locality）设计的统一表示。由于以文件形式存在，整个本体完整继承了现代软件工具链——基于 Git 托管、具备版本控制、通过 Pull Request 进行指标变更审查。 在一套拥有 38,000 个分散字段、跨越十余年历史、极少重叠的企业真实异构数据资产上，TextQL 能够将其统一提炼为版本可控、完全可移植的 TQL 本体。基于这套统一资产，企业上层的所有输出——从管道配置、数据应用到自主 Agent——全部面向同一套语义模型进行编译与验证。 --- ### [14:07](https://www.youtube.com/watch?v=KDms50mACvY&t=847s) 总结与展望：数据领域的编译器时代 软件工厂之所以能够爆发，是因为软件工程在几十年前就将“正确性校验”变成了低廉且自动化的机制；而**分析工厂（Analytics Factory）**之所以在今天成为可能，正是因为数据领域终于迎来了属于自己的编译器——TextQL 本体。 - **核心论文参考**：Ben Shi 在 TextQL 技术博客上发表了专题文章《语义层是补丁，本体才是解药》（*Semantic layers are a patch. Ontologies are the fix.*），系统阐述了封闭语义模型与开放本体编译器的深层理论差异。 - **联系与演示**：现场观众可通过官方渠道获取产品演示，或直接通过邮件（benjamin.shi@textql.com）与团队联系，实地见证分析工厂在真实企业级数据环境中的运行成效。 ## Notable quotes > [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 此时的核心问题不再是‘模型能否完成任务’，而是‘我们能否验证模型的产出、将结果反馈回去并让它反复迭代运行’。 — Benjamin Shi > [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 软件行业耗费了整整 50 年时间，将‘这段代码是否正确？’变成了一个极低成本且可由机器自动校验（machine-checkable）的问题。 — Benjamin Shi > [00:08](https://www.youtube.com/watch?v=KDms50mACvY&t=8s) 工厂的黑暗程度，直接取决于验证能力的完备程度。 — Benjamin Shi > [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 能够成功运行的查询，丝毫不代表其业务逻辑的正确性。 — Benjamin Shi > [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 在当今的企业环境中，阻隔在错误查询与最终业务决策之间的唯一防线，竟然只是人类看着仪表盘说一句‘我觉得看起来差不多’。 — Benjamin Shi > [03:16](https://www.youtube.com/watch?v=KDms50mACvY&t=196s) 数据学科历史上从未拥有过一套能够针对‘业务语义与含义’进行校验的编译器（Compiler）。 — Benjamin Shi > [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 语义模型确实能充当极佳的数据契约，但它本质上是一个封闭世界（Closed World）目录。 — Benjamin Shi > [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 数据领域在过去两年积累了大量‘已批准的答案清单’，却从未拥有过‘能校验任意答案的通用规则系统’。 — Benjamin Shi > [05:43](https://www.youtube.com/watch?v=KDms50mACvY&t=343s) 本体绝非抽象比喻，它在机械层面就是企业的类型系统（Type System for the Business）。 — Benjamin Shi > [08:33](https://www.youtube.com/watch?v=KDms50mACvY&t=513s) 这相当于工厂在自主维护其验证器，人类的工作从装配线苦力升格为分析工厂的管理者。 — Benjamin Shi > [14:07](https://www.youtube.com/watch?v=KDms50mACvY&t=847s) 语义层是补丁，本体才是解药（Semantic layers are a patch. Ontologies are the fix.）。 — Benjamin Shi > [14:07](https://www.youtube.com/watch?v=KDms50mACvY&t=847s) 软件工厂之所以能够爆发，是因为软件工程在几十年前就将‘正确性校验’变成了低廉且自动化的机制；而分析工厂之所以在今天成为可能，正是因为数据领域终于迎来了属于自己的编译器——TextQL 本体。 — Benjamin Shi ## Mentioned Benjamin Shi, TextQL, Blackstone (黑石集团), Snowflake Ventures, Model Context Protocol (MCP), Medallion Architecture (奖章架构), TQL, Git, Python, SQL, Ai4 ## Video description Benjamin Shi - VP, Growth & Strategy, TextQL AI can build software faster. But that does not mean it builds better software. The software industry’s answer is not better prompts. It's the software factory: a system built around better blueprints. Define what good looks like once, and AI can build toward it, test its work, and improve over time. The blueprint becomes the asset. The code becomes an output. Data is next, but the modern data stack was built for an older model of analytics. It resembles an early assembly line: fixed stages, manual handoffs, fragmented context, and weeks of cycle time. It was built for questions you can anticipate, not for exploration that moves freely across the business. The next model is the analytics factory. Its foundation is ontology as code: a single, version-controlled definition of the business that storage, pipelines, metrics, dashboards, playbooks, and agent workflows can all build from. Change the definition once, and the factory retools around it. This talk explores what an analytics factory looks like in production: how the ontology becomes the blueprint AI agents work against, why verification rather than generation is the real bottleneck in AI analytics, and what it takes to move beyond a stack built for predetermined questions. [Source](https://www.youtube.com/watch?v=KDms50mACvY)

Source quotes

[0:08] Benjamin Shi: 此时的核心问题不再是‘模型能否完成任务’，而是‘我们能否验证模型的产出、将结果反馈回去并让它反复迭代运行’。 [0:08] Benjamin Shi: 软件行业耗费了整整 50 年时间，将‘这段代码是否正确？’变成了一个极低成本且可由机器自动校验（machine-checkable）的问题。 [0:08] Benjamin Shi: 工厂的黑暗程度，直接取决于验证能力的完备程度。 [3:16] Benjamin Shi: 能够成功运行的查询，丝毫不代表其业务逻辑的正确性。 [3:16] Benjamin Shi: 在当今的企业环境中，阻隔在错误查询与最终业务决策之间的唯一防线，竟然只是人类看着仪表盘说一句‘我觉得看起来差不多’。 [3:16] Benjamin Shi: 数据学科历史上从未拥有过一套能够针对‘业务语义与含义’进行校验的编译器（Compiler）。 [5:43] Benjamin Shi: 语义模型确实能充当极佳的数据契约，但它本质上是一个封闭世界（Closed World）目录。 [5:43] Benjamin Shi: 数据领域在过去两年积累了大量‘已批准的答案清单’，却从未拥有过‘能校验任意答案的通用规则系统’。 [5:43] Benjamin Shi: 本体绝非抽象比喻，它在机械层面就是企业的类型系统（Type System for the Business）。 [8:33] Benjamin Shi: 这相当于工厂在自主维护其验证器，人类的工作从装配线苦力升格为分析工厂的管理者。 [14:07] Benjamin Shi: 语义层是补丁，本体才是解药（Semantic layers are a patch. Ontologies are the fix.）。 [14:07] Benjamin Shi: 软件工厂之所以能够爆发，是因为软件工程在几十年前就将‘正确性校验’变成了低廉且自动化的机制；而分析工厂之所以在今天成为可能，正是因为数据领域终于迎来了属于自己的编译器——TextQL 本体。

Original transcript

[0:08] Good afternoon everyone. Uh my name is Ben. I  lead growth and strategy at TexQL. Uh before [0:13] that I spent five years at Blackstone working on  data and AI infrastructure initiatives across the [0:18] firm. Uh and also served as a venture partner with  Snowflake ventures. So today I want to talk about [0:24] what we call the analytics factory. Uh the core  argument is this uh the transformation that has [0:30] happened in software engineering over the last  four years [snorts] uh is about to happen to data [0:35] and there's one specific missing piece standing in  the way. So I'll walk you through what that piece [0:41] is uh how we've built it at TexQL and how you can  bring that to your enterprise teams. So to begin [0:49] let me start with what happened in software. So  in 2023 uh the discipline was prompt engineering [0:57] crafting the ask uh for your LLM. Then it expanded  in 2024 to context engineering shaping what the [1:04] model knows. Uh then harness engineering over  a year ago which is giving models tools and [1:10] the autonomy to act. The latest frontier uh if  you've been following along is loop engineering. [1:15] So the question is no longer uh can the model  do the task but it's can we validate what it [1:21] did feed the result back and let it run again and  so each of these stages uh absorb one be absorbed [1:28] the one before it and loops is where the industry  has landed today so here's what a loop looks like [1:36] uh there are four steps assemble context act  through writing the code and calling the API [1:42] verify the result and then decide by retrying  pay or shipping. I want to focus on the third [1:48] box here box here because it is the unlock for  everything that follows. So the reason this [1:54] loops this loop works in software is not the act  step. Models could write code long before anyone [2:00] trusted them to. Um the reason that it works  is that software has spent 50 years making [2:05] uh is this correct? A cheap and machine checkable  question. So compilers catch structural errors [2:12] automatically. tests check behavior against  intent and most wrong in answers die inside [2:18] this loop before they ever reach a human. So you  run this loop once and it's automation. You run [2:24] it thousands of times across uh every task and  it becomes a software factory. Uh many of you [2:31] in this room have seen this working. Uh it's  why Agentic coding tools ship production code [2:36] today. And I think there's a spectrum here worth  noting as well. um borrowed from manufacturing. So [2:43] a lit factory has people on the floor itself. The  machines are doing the work, but a human inspects [2:49] what comes off the line. A dark factory runs with  the lights off, so no one's on the floor at all. [2:54] Uh because the verification is trusted end to  end. So most software teams today run lit. Um [3:00] the loop does the work, an engineer reviews what  survives the gates, but the direction of travel [3:04] is very clear. U the more of the checks are  trusted, the fewer things a human needs to do. [3:10] uh and the darker the factory gets. And so  how dark you can run is a direct function of [3:14] how good your verification is. Now let's take  a look at data which is vastly different from [3:22] software. Um I've lived this experience previously  at Blackstone and many of its portfolio companies. [3:27] So uh this kind of comes from direct experience.  Today before anyone can ask a question of a new [3:33] data set uh someone has to centralize it. That can  take months maybe even quarters. uh then someone [3:40] models this into marts maybe through what we call  like a medallion architecture. So bronze, silver, [3:44] gold into marts. Then you have an AI engineer or  data analyst handw write a semantic layer over it [3:51] uh defining the metrics one at a time. And now in  2026 or even in 2025 there's been a fourth step [3:57] which is wire it to the MCP and just hope that the  agent uses it correctly. So there are two things [4:03] to notice about this diagram. Uh the first is that  every step is fairly manual. Every handoff is very [4:09] manual. Every transition costs real calendar time.  And then secondly, if you look at the bottom here, [4:14] as what we've called out, there's no feedback  loop that ever forms. Um, and so nothing that you [4:20] learn on a single data set can make the next one  cheaper. And so the next data set starts back at [4:26] uh step one. So while software built a factory,  uh data data teams are still working this assembly [4:33] line by hand. So uh why did the loop close for  software but never for data? And the answer is [4:42] kind of represented on the right side of the slide  here. So if you follow a query from left to right, [4:48] is the syntax valid? Um there's a gate for  that. It passes. Does it run? That gate also [4:54] exists. It passes. Does it return a well-formed  table? Passes as well. Now for the next three [5:01] uh are are more semantics. So is active customer  the right definition? Is the join at the right [5:07] grain? Did the answer the qu did it answer the  question that was actually asked? And so those [5:12] gates are drawn dashed here because they were  never fully built. A query that runs tells you [5:18] nothing about whether it's right or not. And today  the only check between that query and kind of like [5:22] a business decision that gets made afterwards is  a person looking at a dashboard and saying that [5:27] looks right to me. And so to be precise, this is  not really a maturity gap. uh or data isn't really [5:33] behind on building this. It's that uh there's  really never been a compiler for this type of [5:37] meaning and uh it's a primitive that this data  discipline has never really had. And so some of [5:43] you are probably wondering uh well this is what my  semantic layer is for. So I want to give semantic [5:49] layers its full credit first. Uh so a semantic  layer in semantic models verifies extremely well. [5:55] It's basically a data contract. uh but it only  answers questions within its own catalog. So [6:02] um revenue by region approved active users also  approved uh churn rate someone's defined that it's [6:09] kind of what we call is closed world. Uh so it can  check any question that someone has anticipated [6:15] in advance at runtime. But the entire point of  conversational data analytics is the questions [6:22] that nobody has really anticipated. Uh so margin  by cohort excluding pilots that's potentially [6:29] a real question uh from a real Tuesday afternoon  like today and it may not be in someone's semantic [6:35] layer catalog today. Uh so when a question  steps outside of the catalog uh the semantic [6:40] layer doesn't really fail loudly. It just has  nothing to say and that's kind of by design [6:45] um in terms of how we think about determinism. A  compiler on the other hand as you see on the right [6:51] here works very differently. It's never seen your  program before, but it checks it anyways because [6:56] it encodes the rules of the language itself. Uh  not just a list of like approved programs. And [7:02] so that's the the distinction. So it's a list of  approved answers versus rules that any answer can [7:08] be checked against. And so data has had plenty of  the first over the last two years um but never has [7:15] really had the second. And this is really where  ontologies come in. So if you've been following [7:21] the space, ontologies have become the new flavor  of the year within enterprises. Um, and ontology [7:28] is a type system for the business. And I mean that  mechanically, not as just like a metaphor. So take [7:35] a question that nobody has anticipated and run  it through the stack. So the first layer is the [7:40] entities and relationships. Grain and cardality  declared ahead of time. This catches potentially [7:46] like a fan out join uh that might quietly double  your revenue uh figure without you realizing. [7:52] The second layer is business logic as rules. So  active customers an agreed composable definition [7:59] not really a saved query and maybe different  teams have different definitions of what an [8:03] active active customer is with different filters.  Um and this catches an agent inventing definitions [8:10] on the fly. The third layer here is constraints.  So what are the valid populations? So the filters [8:14] I mentioned before, units and conversions that  a query must respect. Um, and so the question [8:22] may ne may have never been asked before, but it's  still checkable. Uh, and that's kind of like what [8:26] we consider like the compiler property. Uh, so  the result is checked and and not simply just [8:31] eyeballed. So let's come back to the loop that we  illustrated before. Context, act, verify, decide. [8:40] Um these are the same four steps that power the  software factory now run against your data. So [8:45] context is your tables lineage past queries act  is leveraging uh or pushing down SQL to your [8:52] warehouse leveraging Python analyses and things  of that nature. Um deciding is retrying answering [8:59] or escalating. And the open question for data  is this third bug here which is always verify. [9:03] So every wrong answer uh may have survived  a dashboard but uh because nothing would [9:08] actually check whether it was correct or not. So  everything I've walked through uh is kind of where [9:14] the industry is headed. Uh this is where uh textql  comes in. Actually this is a problem the problem [9:20] space that we tackle. At the core of our platform  is the textql ontology. Uh so it's the type system [9:27] uh for the business from two slides ago that  we illustrated but built as a working product. [9:31] Um it's wired into the loop at two points that you  see here. Uh on the way in it supplies context. So [9:37] the tables reference the lineage the definitions  that the agent needs to interpret your question. [9:43] On the way out it's the verification. So the grain  the joins definitions checked against the model um [9:49] on every single pass. So this loop repeats itself  until the answer is verified and you get like a [9:54] working product whether that's a a data app or  dashboard or a playbook or even an agent itself. [10:00] So it's the same loop in the same factory, but the  piece that was missing here is uh what we've sent [10:05] what we've spent the last three years building.  So again, I'm sure the natural question is [10:13] uh didn't we just relocate the manual work here?  Uh someone still has to build the ontology. Uh and [10:20] this is where our approach is a little bit  different. Um so firstQL's ontology builds [10:25] itself. So you point it at your systems uh and it  compiles the ontology from what already exists. [10:31] So that could be warehouse schemas, query logs,  BI definitions, documentation. This raw material [10:38] uh has been accumulating in your stack for years  and so we operationalize it. Uh this isn't a green [10:44] field modeling project. Uh I've previously run  those and this is not it. Uh and the second is [10:49] that it's the once you generate the ontology,  how do you maintain it? And so the ontology [10:55] learns with you. Every query your team asks makes  the system sharper. Uh so when definitions drift, [11:02] agents propose updates the ontology and  a human admin approves them. So that's [11:07] the factory maintaining its own verifier. This  labor doesn't really disappear. Um it kind of [11:13] moves from the assembly line to actually running  this data factory, this analytics factory itself. [11:22] And I'll show you here what uh the unit that  the ontology is made of. It's a file format we [11:28] call TQL. Uh and each TQL you can think of as  a semantic model. The ontology is a collection [11:34] of these TQL files. Uh so it's basically the atom  that makes up the ontology. So if we look at what [11:42] one file holds, uh the English at the top here  and so this is what the number means uh in plain [11:48] language. uh basically inline documentation  describing uh the SQL underneath so how it's [11:55] computed parameterized and ready to run and  the permissions the rolebased access and uh is [12:01] enforced at the warehouse level so this seems like  common knowledge but a traditional stack actually [12:06] scatters these across three different systems  so the definitions live in a wiki as docs the [12:12] logic may live in BI tools the permissions live  somewhere else entirely uh in this TQL format [12:18] uh they're a single artifact uh which means that  the agent uh reads the meaning and the logic in [12:24] the same place and so does a human rever. This is  what we mean by a format designed for AI locality. [12:31] And because the unit is a file, the ontology  inherits uh the entire software tool chain. It's [12:37] get backed, it's versioned, it's reviewed.  A change to a metric like active customer [12:42] uh ships through a pull request. Uh and that's  how the semantic model stays trustworthy as it [12:47] evolves. And here's what it looks like  uh against a real data estate. So on the [12:56] left here are dozens of systems accumulated over  the last decade. 38,000 columns across multiple [13:05] uh systems and very few of them overlap. And this  might reflect some of your own systems today. [13:10] And in the middle is the textual ontology. Uh so  it's a single ontology represented as TQL files. [13:17] And on on the right here is everything you can  build on top of it. So that can be data models, [13:24] uh pipelines as config, dashboards, data apps,  playbooks, agents, scheduled reports, you name [13:31] it. And this is what we mean by the analytics  factory. So rather than building the semantic [13:37] layer and doing these manual handoffs every step  of the way, the ontology now uh creates all of [13:43] or powers all of the outputs uh for your teams  in terms of decisions and insights. So you set [13:48] it up once, you verify it everywhere and you can  even take this because it's git bagged. It's fully [13:54] portable as well. So every artifact on the right  compiles against the same TQL, the same semantic [13:59] models and the same verification. And that's  the factory running against your stack today. [14:07] Um, and so just to close, software factories  exist because software made correctness checkable [14:14] and cheap. Analytics analytics factories  will exist because data finally has its [14:20] compiler. And so in our view that compiler  is the textual ontology. Uh and that's what [14:26] we're aiming to bridge or the gap that we're  bridging today. Um so if you want to learn more [14:32] uh the QR code here links to our website.  Um there's also a technical piece that I [14:37] wrote uh called semantic layers are a patch.  Ontologies are the fix. Uh so if you're uh [14:42] interested in digging deeper on the argument.  You can feel free to visit our technical blog. [14:45] Uh if you want to see the analytics factory run  against real data uh you can find me afterwards [14:50] uh or reach my email at benjamin.gextql.com That's  sheextql.com. I'm happy to show you directly.