Show HN: Bricksentry – see what a data change does before it ships (Databricks) Brahmareddy, a Databricks Champion, released Bricksentry, an Apache-2.0 open-source change-safety tool that previews what a data change will do to Databricks tables before it ships, including changes made by AI agents editing pipelines. Bricksentry runs a local demo on a 20,000-row revenue table in DuckDB with no Databricks account required, and in that demo it blocks a pull request for a join that duplicates 40 orders and blocks a bad MERGE for 25 duplicate keys, printing and applying the RESTORE command. The tool ships as a Databricks asset-bundle job template, a check-my-table notebook, a GitHub Action for pull requests, and an MCP server that gives AI agents the same checks. The safety check for data changes in the AI era. Change-safety for Databricks pipelines and the AI agents that edit them: know what a change does to your data before it ships. Try it in 30 seconds 1-try-it-in-30-seconds-on-your-laptop · Check every change on Databricks 2-check-every-change-to-your-tables-on-databricks · Docs: bricksentry.org https://bricksentry.org · LinkedIn https://www.linkedin.com/company/bricksentry-org/ Built by Brahmareddy, Databricks Champion. Open source under Apache-2.0. Why the name? Bricks plus entry. Your tables and pipelines are the bricks of the lakehouse, and every change to them is an entry. bricksentry checks each entry, reports what it does, and stands guard before it lands. uvx --from "bricksentry duckdb " bricksentry demo Or pip install "bricksentry duckdb " and then bricksentry demo . In a Databricks or Jupyter notebook, run %pip install "bricksentry duckdb " in one cell, then from bricksentry.demo import run demo; run demo in the next; on Databricks, add dbutils.library.restartPython after the install. No Databricks account and nothing leaves your machine: it runs on a 20,000-row revenue table in local DuckDB. An AI agent previews a DELETE on a clone production untouched , gets its pull request blocked for a join that duplicates 40 orders, fixes it, and is routed to the owners of a certified table downstream. Then a nightly pipeline commits a bad MERGE anyway: bricksentry finds it in the table history, skips the OPTIMIZE after it, blocks it for 25 duplicate keys, prints the RESTORE and applies it. databricks bundle init https://github.com/bricksentry/bricksentry --template-dir templates/job-check cd bricksentry check && databricks bundle deploy databricks bundle run bricksentry demo optional: see a block on a demo table in about 2 minutes One command and a few prompts give you a serverless job that runs after every commit to the tables you pick: the same check as the demo's last step, on your data, with the RESTORE that undoes a bad change and an optional Slack alert. The optional demo job writes a known-bad MERGE to a demo table in your scratch schema and checks it, so your first run ends red with a block. Details below check-every-pipeline-run-automatically-asset-bundle . Put the check inside your pipeline job, right after the task that writes the table: a block fails that task and the tasks downstream don't run. Or run it on pull requests with the GitHub Action for-data-engineers-cli-and-ci , and give AI agents the same checks through the MCP server for-ai-agents-the-mcp-server . Check-my-table notebook: in your workspace, go to Workspace → Import → URL and paste https://raw.githubusercontent.com/bricksentry/bricksentry/main/examples/databricks/bricksentry check my table.py Point the check-my-table notebook https://github.com/bricksentry/bricksentry/blob/main/examples/databricks/bricksentry check my table.py at a Delta table your pipeline writes to. It finds the latest data change in the table's history a WRITE, MERGE, UPDATE or DELETE , compares it with the version before, and shows the verdict a reviewer would have seen before that change shipped: rows added, removed and changed, duplicate keys, totals that moved, what depends on the table, and the RESTORE command to undo it. Your table is only read; the comparison uses two shallow clones in a scratch schema, dropped at the end. If it shows you something, please share what it found https://github.com/bricksentry/bricksentry/issues/new?template=it caught this.yml no table names needed . Real results decide what gets built next. databricks bundle init https://github.com/bricksentry/bricksentry --template-dir templates/job-check cd bricksentry check && databricks bundle deploy -t prod Answer a few prompts tables to watch, key columns if they have no primary key, SQL warehouse, scratch schema, whether to add the demo job, policy, optional Slack webhook secret . You get a serverless job with a table update trigger : whenever a watched table changes, it checks the change, sends the alert and logs the RESTORE that undoes it. To stop downstream tasks when a change is bad, add the same check as a task inside your pipeline job, right after the write the generated README shows the YAML : with --since {{job.start time.iso datetime}} it checks everything the run wrote, and a block verdict fails the task so the tasks after it don't run. From the command line, the same check is one command: bricksentry check-last-change main.sales.orders newest data change vs the version before bricksentry check-last-change main.sales.orders --version 42 a specific version bricksentry check-last-change main.sales.orders --since 2026-11-11T09:00:00Z --fail-on needs human Keys come from bricksentry.yml , --key , or the table's PRIMARY KEY constraint. OPTIMIZE and VACUUM commits are skipped because they don't change data. HR walkthrough notebook: Workspace → Import → URL → https://raw.githubusercontent.com/bricksentry/bricksentry/main/examples/databricks/bricksentry hr walkthrough.py The HR walkthrough https://github.com/bricksentry/bricksentry/blob/main/examples/databricks/bricksentry hr walkthrough.py builds a 200,000-row employee table tagged pii feeding a certified pay summary, then shows everything bricksentry does on it: table and column blast radius, two pull requests one risky, one broken , every rule, an agent's write previewed on a clone with dangerous SQL refused, the PR report, column-level policies, sampling that can't hide a duplicate, lineage from config, alerts and the MCP tools. It removes everything it created at the end. First run on a live workspace by Genie, an AI agent in Databricks, in November 2026. Databricks quickstart notebook: in your workspace, go to Workspace → Import → URL and paste https://raw.githubusercontent.com/bricksentry/bricksentry/main/examples/databricks/bricksentry quickstart.py The quickstart notebook https://github.com/bricksentry/bricksentry/blob/main/examples/databricks/bricksentry quickstart.py creates a small demo table in a schema you choose and runs the same loop on Databricks: Unity Catalog blast radius, a real RESTORE rollback plan, a preview on a shallow clone, a blocked pull request and the fix. Then it checks one of your own tables, read-only, and cleans up after itself. You need a SQL warehouse, CREATE TABLE on the schema you pick, and SELECT on system.access.table lineage for the blast radius. A Jupyter copy is in bricksentry quickstart.ipynb https://github.com/bricksentry/bricksentry/blob/main/examples/databricks/bricksentry quickstart.ipynb . Before a change reaches production, bricksentry answers three questions, in a pull-request comment for humans and in structured JSON for agents: 1. What does it do to the data? A key-based data diff: added, removed and changed rows, schema changes, per-column changes, numeric totals, duplicate keys, and where the change is concentrated "100% of affected rows are region = APAC" . 2. Who gets hurt? The downstream blast radius from Unity Catalog lineage: tables, jobs, notebooks, Lakeflow pipelines, dashboards and queries, with owners and tags. Down to the column: which columns the change touched, whether they are tagged for example pii , and which downstream columns they feed. 3. Is it safe, and how do I undo it? A deterministic policy verdict pass · warn · needs human · block and the exact RESTORE TABLE … VERSION AS OF n rollback. For your Databricks workspace: pip install "bricksentry databricks,mcp " bricksentry init writes bricksentry.yml and policy.yml AI now writes much of our pipeline code, and checking what that code does to the data hasn't kept up. Code review can't see a silent 3% revenue shift or a join that fans out. The tools that do catch this mostly cover dbt, or need a paid platform. Most Databricks work is PySpark notebooks, Jobs and Lakeflow pipelines, and bricksentry is built for that work: - Unity Catalog runtime lineage , not SQL parsing, so PySpark notebooks and jobs are included. - SQL pushdown : all diffing runs on your SQL warehouse, so no Spark session is needed and calls stay cheap enough for an agent loop. - One engine, three faces : CLI and GitHub Action · Python API · MCP server. The quickest way to connect an agent is the bricksentry-mcp package, which installs bricksentry with its MCP and Databricks extras. With uv https://docs.astral.sh/uv/ there is nothing to install first: Claude Code claude mcp add bricksentry -- uvx bricksentry-mcp --config /full/path/to/bricksentry.yml { "mcpServers": { "bricksentry": { "command": "uvx", "args": "bricksentry-mcp", "--config", "/full/path/to/bricksentry.yml" } } } The JSON works for the Claude desktop app, Cursor and other MCP clients. Use a full path to bricksentry.yml , because clients start the server from their own working folder. If an app can't find uvx , use its full path which uvx . To share the setup through a repo, claude mcp add -s project ... writes it to .mcp.json ; a relative path then works when Claude Code starts from the repo root. No config yet? uvx --from bricksentry bricksentry init writes a starter one. Already installed bricksentry with pip? pip install "bricksentry mcp,databricks " and run bricksentry mcp --config /full/path/to/bricksentry.yml instead. Add --transport streamable-http for remote agents. bricksentry is listed in the official MCP Registry https://registry.modelcontextprotocol.io/v0/servers?search=io.github.bricksentry/bricksentry as io.github.bricksentry/bricksentry . | Tool | What the agent gets | |---|---| | whats downstream table, depth, columns? | Downstream assets with owners and tags. Call it before editing. Pass the columns you'll change to see the downstream columns they feed and their tags. | | rollback plan table | The restore SQL. Capture it before changing anything. | | preview write sql, target, keys? | Runs one write against a disposable shallow clone , never production, and returns the diff plus verdict. | | assess change tables, candidates?, pr? | Diffs prod vs. the candidate built by your change, plus lineage and policy. Returns a verdict and an id . | | explain diff assessment id or table | Plain-English summary. | | safe to ship assessment id | safe to ship , the reasons, and an explicit next step to follow. | Designed for agents: - The verdict never comes from an LLM. Rules in policy.yml decide, so the same change always gets the same answer. - Read-only by default. Only preview write writes, and only to a sandbox clone. It accepts a single INSERT / MERGE / UPDATE / DELETE / CREATE OR REPLACE whose target must be the clone, and it refuses DROP, TRUNCATE, ALTER, GRANT and multiple statements. - Errors come back as {"error": ...} , so agents can recover instead of crashing. - Bounded cost: deterministic hash sampling sample pct , capped samples, and lineage limited by depth and lookback window. A full-table checksum guards the sample: if the sample shows no change but the tables differ, the diff re-runs on every row, so a one-row change can't slip through. - Assessments are saved as JSON default ~/.bricksentry/assessments , so explain diff and safe to ship work from another process or a fresh Sentry . The same tools are plain Python functions in bricksentry.agent tools , so you can use them from LangGraph, the OpenAI Agents SDK or the Databricks Agent Framework without MCP. To watch the whole loop, run bricksentry demo see the top of this page . bricksentry demo --report report.md also writes the pull-request comment a reviewer would see. Run the MCP server as a Databricks App so every agent in your workspace can reach it over HTTPS, with no tokens to manage: it runs as the app's service principal, and Unity Catalog grants decide what it can read. deploy/databricks-app https://github.com/bricksentry/bricksentry/blob/main/deploy/databricks-app is a ready app app.yaml , an Asset Bundle, the grants that deploys with two commands: js databricks bundle deploy --var warehouse id=