How GovernedUI works inside your product

1. A user asks in the host app

A request starts in the embedded chatbox, with the user’s current task and role as context. The result appears in the UI Canvas of that same application, so the user does not have to move work into a separate app builder.

“Show monthly revenue alongside our customer accounts. Break it down by business unit, and keep the monthly trend.”

2. The host exposes approved capabilities

The product team publishes specific data and actions from its own APIs and, where approved, connected systems such as a warehouse or ERP. Each capability has a defined input, output, owner, and access boundary. The model does not receive open-ended access to those systems.

• A revenue metric with an agreed definition
• Account records limited to the current user’s access
• Approved chart, table, and form components

3. Policy checks the proposed screen

GovernedUI maps the request to available capabilities and builds a structured UI specification. The host checks permissions, allowed components, data shape, masking, and any action approval before rendering. The interface uses the host design system so it looks and behaves like part of the product.

4. The user reviews and refines

The user can ask a follow-up question, adjust the result, and return to a saved dashboard snapshot. The demo shows this loop with synthetic CRM data. A production connection to customer data, live refresh, or an ERP requires a scoped adapter and deployment review.

What a first evaluation covers

The current paid evaluation is deliberately narrow: one host application, two data sources, and agreed revenue metrics for an embedded dashboard. Integration effort, data accuracy, dashboard edits, and repeat use are evaluated against acceptance criteria agreed before the pilot.