From 3fba070a2d7bc2f0f01d764d57a53ca0005c2c62 Mon Sep 17 00:00:00 2001 From: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> Date: Wed, 13 May 2026 10:48:39 -0700 Subject: [PATCH 1/3] Add living dashboards article Signed-off-by: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> --- ...Interfaces - AI Generated Data Surfaces.md | 298 ++++++++++++++++++ assets/openui-living-dashboard-contract.svg | 53 ++++ 2 files changed, 351 insertions(+) create mode 100644 Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md create mode 100644 assets/openui-living-dashboard-contract.svg diff --git a/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md new file mode 100644 index 0000000..14ad6ac --- /dev/null +++ b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md @@ -0,0 +1,298 @@ +# From Static Dashboards to Living Interfaces + +How AI is redefining the way we display data. + +Static dashboards were built for a world where the important questions were +known before the meeting started. + +That world still exists. Finance needs a month-end close dashboard. Support +needs a queue health dashboard. Engineering needs deploy health. These pages +work because the audience, metrics, layout, and decision cadence are stable. + +The problem is everything around those stable dashboards. A product lead asks +why activation dropped for one segment. A success manager wants the same number +filtered by customer tier and renewal date. An executive wants the answer in two +charts and one risk table, not the twelve panels the BI team designed last +quarter. + +Traditional dashboards are pages. Living interfaces are answers. + +The shift is not that AI makes charts prettier. The shift is that AI can compose +the right data surface for the user's current intent, while the application keeps +control of the metrics, permissions, components, and actions. OpenUI matters in +that architecture because it gives the model a constrained interface language +instead of asking it to improvise prose, raw JSON, or arbitrary frontend code. + +## The Static Dashboard Contract + +A static dashboard is a contract between a builder and a future viewer: + +- these are the metrics, +- this is the layout, +- these are the filters, +- these are the drilldowns, +- and these are the actions we expect you to take. + +That contract is efficient when the future viewer is predictable. A revenue +dashboard can put bookings, churn, pipeline, and forecast on the same screen +because the business reviews those numbers every week. A latency dashboard can +show p95, p99, error rate, and deploy markers because the incident workflow is +well understood. + +Static dashboards fail when the user is not trying to monitor a known state, but +to investigate a fresh question. + +In that mode, the user usually does not need another dashboard. They need a +temporary workspace assembled around a specific question: + +```txt +Why did new-team activation fall in the west region last week, and which +accounts should customer success contact first? +``` + +A fixed dashboard might contain every ingredient for that answer, but it makes +the user assemble the argument manually. They click through cohort filters, copy +numbers into a note, compare charts by memory, export a table, sort it, and then +write the action list somewhere else. + +The data is present. The interface is not shaped around the job. + +## What A Living Interface Changes + +A living interface is generated around intent. It still uses real metrics and +real components, but its layout is assembled at runtime for the question in +front of the user. + +For the activation question, one user might need an executive summary: + +- current activation rate, +- delta versus baseline, +- top three affected segments, +- confidence level, +- recommended next action. + +Another user might need an anomaly drilldown: + +- cohort line chart, +- region and plan filters, +- event funnel comparison, +- suspicious step dropoff, +- link to the underlying query. + +A customer success manager might need an action queue: + +- impacted accounts, +- ARR tier, +- renewal date, +- owner, +- suggested outreach reason, +- button to create follow-up tasks. + +These should not be three permanent dashboards if the business only asks this +exact question once. They should be three generated data surfaces over the same +metric contract. + +![Living dashboard contract](../assets/openui-living-dashboard-contract.svg) + +The model should not invent the activation rate. It should not make up account +ARR, customer names, or a renewal risk score. Those still come from application +tools and governed data systems. The model's job is composition: choosing a +useful interface shape, arranging validated data, and exposing safe next actions. + +That is the important boundary. A living interface is not "the model owns the +dashboard." It is "the model composes an allowed interface from trusted data." + +## The Four-Part Runtime Contract + +AI-generated dashboards need a stricter contract than a normal chat answer. +Without one, the model can produce a nice-looking but untrustworthy interface. + +The useful contract has four parts. + +First, the metric contract belongs to the application. Metric names, filters, +aggregation windows, permissions, and freshness rules should be defined outside +the model. If activation means `activated_accounts / new_accounts` with a +seven-day window, the model should receive that as a named metric, not rewrite +the formula from memory. + +Second, the data comes from tools. The model can request `activation_summary`, +`funnel_breakdown`, or `at_risk_accounts`, but the application executes those +queries and returns structured results. This keeps the generated interface tied +to auditable data. + +Third, the component vocabulary is constrained. The model can compose `Metric`, +`LineChart`, `SegmentTable`, `Alert`, `FilterBar`, and `ActionList` because the +application has registered those components. It cannot emit arbitrary React, add +unapproved controls, or invent a dangerous action. + +Fourth, actions are validated. A generated "create outreach task" button should +send a typed payload back to the application. The application checks +permissions, required fields, idempotency, and audit logging before anything +happens. + +That contract is where OpenUI fits. OpenUI gives the model a UI-native way to +describe the data surface while the app keeps ownership of data, components, and +effects. + +## A Concrete Example + +Imagine the user asks: + +```txt +Show me why activation dropped for west-region self-serve teams last week. +``` + +A text-only assistant might answer: + +```txt +Activation dropped from 42% to 34%. The biggest drop was in workspace invite +completion. West-region self-serve teams created fewer integrations, and 18 +accounts with upcoming renewals were affected. +``` + +That is useful, but it collapses a workflow into a paragraph. The user still has +to ask follow-up questions, verify the numbers, and find the accounts. + +A static dashboard might have the same information scattered across five panels. +The user has to know which filters to apply and which chart matters. + +A living interface can render the answer as a small investigation workspace: + +```txt +Dashboard(title:"Activation drop: west self-serve") { + Metric(label:"Activation",value:"34%",delta:"-8 pts") + LineChart(metric:"activation_rate",groupBy:"week",highlight:"last_7_days") + Funnel(steps:["signup","invite","integration","first_report"],compare:"baseline") + SegmentTable(source:"at_risk_accounts",columns:["account","arr","owner","renewal"]) + ActionList(actions:["create_success_tasks","open_query","save_view"]) +} +``` + +This is not a complete OpenUI application. It is the shape of the contract: +known components, named metrics, explicit sources, and safe actions. + +The interface can also adapt to role. For an executive, the same data may render +as a short risk memo with two charts. For a product manager, it may show funnel +steps and event definitions. For success, it may lead with accounts and task +creation. + +The data does not change. The surface changes because the user's next action is +different. + +## Why Chat-Over-Data Is Not Enough + +Many teams already have natural-language analytics. A user asks a question, the +system writes SQL, returns a chart, and explains the result. That is useful, but +it often stops at a single answer. + +Living interfaces go further in three ways. + +They preserve state. If the user changes the segment from west to northeast, the +chart, table, summary, and action list should update together. A paragraph does +not have that kind of state boundary. + +They expose affordances. A user can sort the account table, inspect the funnel +dropoff, save the view, or create follow-up tasks. They do not need to ask the +assistant for every tiny operation. + +They make verification visible. A generated data surface can include query +links, metric definitions, freshness badges, and confidence warnings. That is +harder to communicate in prose without burying the user. + +In other words, chat-over-data answers the question. A living interface supports +the work that follows the answer. + +## The Implementation Pattern + +A practical architecture can be simple: + +1. The user asks a question in natural language. +2. The application classifies the intent and checks permissions. +3. Data tools return metric packets, segment tables, and allowed actions. +4. The model receives the packets plus a constrained component manifest. +5. The model emits OpenUI-style interface output. +6. The renderer displays the interface and sends user actions back to app code. + +The critical move is step four. The model should not receive an unlimited design +system. It should receive a small vocabulary that matches the workflow. + +For a data workspace, that might be: + +- `Metric` for headline numbers, +- `TrendChart` for time series, +- `BreakdownChart` for grouped comparisons, +- `SegmentTable` for accounts, users, or events, +- `FilterBar` for safe filters, +- `Definition` for metric explanations, +- `ActionList` for allowed next steps. + +This keeps the generated UI predictable. It also makes the model's output easier +to validate. If the renderer sees a component outside the manifest, it rejects +it. If a table references a source that was not returned by the data layer, it +fails closed. If an action payload is missing required fields, the app does not +execute it. + +The result is adaptive without being uncontrolled. + +## What Developers Still Own + +Living interfaces do not remove frontend engineering. They move it to a better +boundary. + +Developers still own component quality. A generated chart is only useful if the +chart component handles empty states, loading states, accessibility, mobile +layouts, and dense labels. + +Developers still own data correctness. The model should not be trusted to +calculate revenue, retention, or activation from raw guesses. It should arrange +results from metric services that already enforce definitions. + +Developers still own permissions. A support manager and a contractor might ask +the same question, but the account table and available actions should differ. + +Developers still own replay. If a generated interface drives a business decision, +the team should be able to replay the metric packets, model output, and action +payloads later. Otherwise the interface becomes impossible to audit. + +Developers still own fallback behavior. When generation fails, the app should +show the underlying metric packet, a safe summary, or a saved dashboard. The +user should never be blocked by a malformed layout. + +OpenUI helps with the composition layer, but it does not absolve the product of +these responsibilities. That is a good thing. Dynamic UI needs constraints to be +usable in real software. + +## Where Static Dashboards Still Win + +Static dashboards are not going away. + +They are better when the business needs a canonical view. Board reporting, +compliance metrics, incident scorecards, SLA dashboards, and audit trails should +not be regenerated differently for every user. Stable views create shared +language. + +They are also better when a team needs muscle memory. An on-call engineer should +not wonder where error rate moved today. A finance analyst should not relearn +the close dashboard every month. + +The right split is not static versus AI. It is stable versus situational. + +Stable questions deserve stable dashboards. Situational questions deserve +generated interfaces around intent. + +## The Dashboard Becomes A Starting Point + +The most realistic future is hybrid. A user starts from a dashboard, asks a +follow-up question, and the system generates a temporary interface next to the +canonical view. + +The static dashboard provides trust and orientation. The living interface +provides adaptation and action. + +For teams building AI products, that is the opportunity. Do not make the model +describe dashboards in prose. Do not make users hunt through a dashboard backlog +for every new question. Give the model a safe component vocabulary, connect it to +trusted data tools, and let it assemble the interface the moment requires. + +Dashboards used to be destinations. In AI-driven products, they become raw +material for generated workspaces. diff --git a/assets/openui-living-dashboard-contract.svg b/assets/openui-living-dashboard-contract.svg new file mode 100644 index 0000000..b306f4e --- /dev/null +++ b/assets/openui-living-dashboard-contract.svg @@ -0,0 +1,53 @@ + + Living dashboard runtime contract + A diagram showing user intent, governed metrics, data tools, constrained components, and validated actions feeding a generated data surface. + + + + Living dashboards are generated from contracts, not guesses + The model composes the interface; the application owns data, permissions, components, and effects. + + + User intent + question, role, goal + + + Metric contract + definitions, filters + + + Data tools + audited results + + + OpenUI vocabulary + allowed components + + + Model composes + layout + components + safe action payloads + + + + + + + Generated + data surface + + + + + + + + + + + + + + Runtime output is adaptive; data and effects stay governed. + From fe7c8706208842e60f19f4e59778ee344fd14fab Mon Sep 17 00:00:00 2001 From: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> Date: Wed, 13 May 2026 10:59:58 -0700 Subject: [PATCH 2/3] Fix dashboard heading capitalization Signed-off-by: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> --- ...hboards to Living Interfaces - AI Generated Data Surfaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md index 14ad6ac..22d2e58 100644 --- a/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md +++ b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md @@ -280,7 +280,7 @@ The right split is not static versus AI. It is stable versus situational. Stable questions deserve stable dashboards. Situational questions deserve generated interfaces around intent. -## The Dashboard Becomes A Starting Point +## The Dashboard Becomes a Starting Point The most realistic future is hybrid. A user starts from a dashboard, asks a follow-up question, and the system generates a temporary interface next to the From b0e30ca7f6c35032bb3ef21cae1db848cbda39c1 Mon Sep 17 00:00:00 2001 From: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> Date: Wed, 13 May 2026 11:01:37 -0700 Subject: [PATCH 3/3] Address living dashboard review notes Signed-off-by: Alex Roesler <183014507+Aroesler1@users.noreply.github.com> --- ...ds to Living Interfaces - AI Generated Data Surfaces.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md index 22d2e58..9c275b6 100644 --- a/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md +++ b/Articles/From Static Dashboards to Living Interfaces - AI Generated Data Surfaces.md @@ -57,7 +57,7 @@ write the action list somewhere else. The data is present. The interface is not shaped around the job. -## What A Living Interface Changes +## What a Living Interface Changes A living interface is generated around intent. It still uses real metrics and real components, but its layout is assembled at runtime for the question in @@ -219,9 +219,10 @@ system. It should receive a small vocabulary that matches the workflow. For a data workspace, that might be: - `Metric` for headline numbers, -- `TrendChart` for time series, -- `BreakdownChart` for grouped comparisons, +- `LineChart` for time series, +- `Funnel` for step-by-step conversion paths, - `SegmentTable` for accounts, users, or events, +- `Alert` for exception or risk flags, - `FilterBar` for safe filters, - `Definition` for metric explanations, - `ActionList` for allowed next steps.