The Data App Framework, v2.0 · October 2026
Venkata M Sangaraju, Sr. Database Engineer
On October 8, Anthropic put Claude Dashboards into beta. You connect Redshift, BigQuery, ClickHouse, Databricks or Snowflake, ask a question in plain English, and Claude writes the queries, picks the charts, and keeps the dashboard current. Four days later, Google announced Looker Data Apps in preview: an AI coding agent generates the app, and you publish it into Looker, where every query runs under the viewer's Looker permissions. Three weeks before either, Tableau ran its Dreamforce keynote under the title "Beyond BI" and introduced Tableau Data Apps, which you vibe-code with an outside agent and publish onto Tableau's governed data. Sigma's homepage now calls it a platform for "analytics, apps, and agents." Databricks has Apps. Snowflake has Streamlit and Native Apps. Domo has been selling "apps" for a decade and must be enjoying this.
So everyone has data apps, and nobody agrees on what one is.
I work on governed conversational analytics, and I keep having the same argument in design reviews. Someone shows an impressive demo, and the questions that decide whether it survives production get pushed to phase two: whose permissions does it run under, where do its metric definitions live, what happens when it writes something back. Those questions are the product, not a later phase.
Platform teams are hearing a version of this a lot right now. Someone starts building in Claude Dashboards and likes what they get. Then they notice that their row-level and column-level security, and the role mappings behind it, already live in Looker or Tableau, and none of it carries over to the new tool. Nobody wants to rebuild a security model for every new tool. They want the new app to inherit the one they already trust. That's a reasonable ask, and today it's harder than it should be.
This framework is my attempt to write down the vocabulary those reviews need: a definition, levels, principles, the failure modes I keep seeing, and a scorecard. Map your product against it and tell me where it's wrong.
What a data app is
A data app is a software application whose primary interface is live data, built on governed definitions, whose output is a decision or an action and not only a display.
Live data rules out the static extract dressed up as an app. Governed definitions rules out the app that quietly re-implements "revenue" in its own SQL and drifts from the official number for a year. And decision or action rules out most of what got announced this year. If nothing can change because the app exists, it's a report with better marketing.
Under this definition a dashboard isn't a different species from a data app. It's the simplest kind. What separates products is how much they're trusted to do, and in production systems trust should come in levels.
The autonomy levels
Classify a data app by the most consequential thing it is allowed to do, the way self-driving got classified by how much of the driving the machine does. Governance follows the level, not the vendor or the roadmap.
| Level | What the app may do | Governance floor |
|---|---|---|
| L0 View | Shows governed metrics; filtering is the whole interaction | Certified definitions, viewer-level access control |
| L1 Explore | Drill-downs, follow-up questions, conversational querying | Row/column security enforced when the query runs, not in the UI; queries logged |
| L2 Simulate | What-if inputs and scenarios; nothing is written anywhere | Assumptions stored with every output, so a scenario can be re-run and audited |
| L3 Act | Writes back to the warehouse or triggers a workflow; a human approves each action | Runs as the end user; every write approved, logged and reversible |
| L4 Delegate | An agent acts on its own inside a pre-approved mandate | Machine-readable mandate with scope, limits and expiry; a kill switch; lineage on every action |
Two clarifications, because this is where marketing will try to blur things. Level is per capability, not per app: an app that views at L0 and submits at L3 is an L3 app for governance purposes. And levels can't be skipped. An app that writes back while its row-level security lives only in the UI is missing a level, and that gap is where incidents come from.
Now place the market. The BI vendors are climbing from the bottom. They're strong on L0–L1 governance and are adding write-back and actions: Sigma writes back to the warehouse and runs actions inside warehouse permissions, and Tableau's MCP servers push governed answers into Slack, Teams, Claude and ChatGPT, with published Data Apps inheriting Tableau's permissions.
The AI labs are coming down from the top, with generation nobody can match and governance still arriving. Claude Dashboards shows the query behind every chart and when each chart last refreshed, a level of query transparency BI tools don't usually put in front of business users. Anthropic also positions it as working alongside BI tools for quick, exploratory questions, with a hand-off to Sigma, Hex, Omni and others when a question needs deeper analysis (Looker and Tableau are listed as coming soon). In this framework's terms, that's an L1 product that sends you to the governed layer when the stakes go up. It's an honest description of where each side is strong today.
Four principles
1. Definitions before displays. A metric gets defined once, in the semantic layer, and every app consumes that definition. Once an app embeds its own calculation you have two sources of truth, and eventually a meeting about why they disagree. Looker built its product around this idea with LookML more than a decade ago, and it's still the clearest example of a metric defined once and reused everywhere.
2. Run as the user, not as the app. Queries and actions execute with the requester's identity and permissions, down to the data and back up to whatever the app triggers. That can happen in two ways. The warehouse can see the user directly, through per-user credentials. Or a governed semantic layer can compile that user's row and column policy into every query it generates, on every surface, even though the warehouse sees one connection. Looker's access filters and Tableau's data policies work the second way, and it counts. What doesn't count is an app that connects to the warehouse with its own credentials and enforces permissions only in its interface. That app has stepped around the governed layer, and every user of it effectively holds the app's access. Pull up your warehouse query log and check where the app's queries come from. If it's a service account that isn't your governed semantic layer, your row-level security is a rumor.
3. Writes are transactions, and derived data keeps its lineage. A write-back needs the acting identity, the data it was based on, its approval state, and a way to reverse it. Whatever the app writes becomes someone else's source data tomorrow, so it should carry its lineage with it. When a number is wrong in a quarter-end review, "the app did it" isn't an answer. You need to know which app ran, as whom, on what data, and who approved it, and you can only answer that if the platform recorded the derivation at write time. I make the formal case for derivation-aware access control in agent systems in "Lineage-Aware Memory Governance" (IEEE Access, 2026). The short version is that access decisions have to know where data came from.
4. Generated apps are drafts, and drafts need owners. A prompt-generated app is unreviewed code whose author happens to be a model. Treat it like unreviewed code from a new hire: fine for exploration, gated before production, with the gate proportional to the autonomy level. Light for L0, mandatory for L3. Anthropic ships Dashboards switched off by default for Enterprise organizations, so an admin has to turn it on, and that's the right default for this category. Every app that does reach production also needs a named owner, a review date, and a way to be retired. BI teams spent a decade producing dashboard sprawl, thousands of unowned near-duplicates. Generated apps can produce the same sprawl in a quarter, and these ones hold credentials and can write.
Where governance has to live
Every platform here is some arrangement of the same parts: sources, a data platform with its own security model, a governance layer (definitions, identity, policy, lineage), an app runtime, and the surfaces where people meet the app, from portals and embeds to chat tools and AI assistants. The architectural question that matters is whether the governance layer is a plane every runtime and surface passes through, or a feature each app implements for itself.
Feature-level governance breaks down once the app is distributed. MCP is about to put the same app inside your portal, your Slack, your CRM and two AI assistants. If policy lives in the app, you maintain it in five places and the weakest copy defines your actual security. If it lives in the plane, enforced when the query executes against definitions written once, a new surface inherits it. Sigma argues for this with its warehouse-native design, which runs live queries with governance at the source. Tableau argues for it with Tableau Knowledge and its auto-built knowledge graph. They put it at different layers, but the instinct is the same, and I think it's correct.
Failure modes
These are the ones I see most often. Name them in reviews.
The service-account masquerade. The app queries the warehouse with its own service account, outside the governed layer, and per-user security exists only in its UI. Check the warehouse log.
Forked definitions. The app computes its own version of a governed metric. To test, change the certified definition. If the app's number doesn't move, it's a fork.
Stale data that looks live. A "live" badge on a dashboard fed by an hourly pipeline, refreshing at per-click warehouse prices. Or an upstream schema change makes the app's queries fail quietly, and the first person to notice is an executive quoting an old number. Ask for the refresh contract per widget, and ask which contract tests catch a schema change.
Unreviewed promotion. An app built for exploration picks up a submit button along the way, and nobody reclassifies or re-reviews it. There is probably an L3 capability in your estate right now that no one remembers approving.
Scorecard
For vendor evaluations and release gates. Mark each question Described, Partially described, or Unknown — anything the platform's public material does not describe is Unknown, never absent. An app that fails question 2 or 4 shouldn't run above L1.
- Do the metrics resolve to the governed semantic layer, or does the app define its own?
- Does every query and action run under the end user's identity, either directly or through a governed layer that enforces that user's policy?
- Is row/column policy enforced at execution time on every surface where the app appears?
- Can every output be traced to its inputs, definitions and derivations?
- Can a reviewer see the generated SQL and logic before release?
- Is the app in a registry, with an owner and a review date?
- Is freshness a stated contract, and do contract tests catch schema or definition changes before users do?
Using this
The canonical copy of this framework lives at github.com/sangaraju1988/data-app-framework, versioned, with issues open. Cite and fork that copy and file corrections there; this post is the announcement. The first product mapping, for Claude Dashboards, is already in the repo. Vendors, publish your mapping against the levels and the scorecard. Builders, classify what you're shipping before your security team does it for you.
Venkata M Sangaraju is a Sr. Database Engineer working on governed conversational analytics and agent memory governance, and the author of "Lineage-Aware Memory Governance" (IEEE Access, 2026).
Top comments (0)