MVG: Interactive Native UI Controls

Customer Benefit: Agents answer with working controls (choices, tables, charts) your app renders natively, and each click returns to the same run.

Overview

Traditional AI agents return markdown text, static images, or unstructured JSON. When an agent returns tabular data, a chart, or a set of options, users cannot interact with it directly. When they reply, the conversation restarts a new reasoning turn, losing state and risking hallucination.

MVG (Machine-Verified Geometry) returns typed UI instructions—stat cards, sortable/filterable tables, interactive charts, and choice buttons—that your application renders natively. Every user interaction (clicking a bar, selecting a row, clicking an option) emits a typed event that resumes the exact same run.

Comparison: Siliqun Rotor vs. Google A2UI

Both Siliqun Rotor and Google A2UI share the foundational principle that UI is data, never code. Here is how Siliqun Rotor differs in design and runtime execution:

Capability	Google A2UI (v0.9.1 / v1.0)	Siliqun Rotor MVG
Run & State Binding	Client actions return as a generic `actionResponse` to the agent; state lifecycle management is delegated entirely to the external model or agent framework.	Events carry `run_id`, `render_id`, `state_version`, and a per-render `sequence`. The host resumes that specific run and rejects stale state, out-of-order calls, or replays.
Validation Before Execution	An action response sends user selections directly to the agent runtime.	Selected values are validated against the run's pending `ask` before state changes. A click that leads to an action changing data still waits for confirmation.
Security & Authority	Actions execute within client component contexts.	Authority never originates from the browser. Organization, project, tenant, and principal boundaries are derived strictly from the authenticated server session.
Model Dependency	Typically generated by an LLM interpreting component catalog definitions.	Generated deterministically by the Tier 1 shaper from grammar and data rows on CPU; an external LLM is completely optional.

Supported MVG Controls

Stat Cards: Key metrics, trend percentages, and currency values with semantic badges.
Interactive Bar Charts: Scalable SVG/DOM charts with category labels, series legends, hover value tooltips, and bar selection events (select_bar).
Searchable & Selectable Tables: Full-width data tables with live client-side search filtering (.sqr-table-filter), sortable column headers, and selectable rows emitting select_row.
Choice Buttons: One button per option, emitting choice_select.

Resuming the Run

A saved workflow run that waits for one value from a list of options returns that ask with a render_id. The run's revision is the state_version. Your application renders the options as choice buttons (the SDK's renderMvg and mount), and a click emits choice_select. resumeMvgChoice passes the choice to your authenticated call to the run's answer route:

POST /v1/runs/{run_id}/answer

{
  "values": { "leave_type": "vacation" },
  "mvg": { "render_id": "rnd_04b2c1...", "state_version": 3, "sequence": 1 }
}

The engine checks the choice before the run changes:

The run must belong to the authenticated organization and project. The event carries no tenant or project.
state_version and render_id must be the run's current ones. Otherwise it answers stale_state.
sequence must be higher than any sequence already accepted for that render_id. Otherwise it answers replayed_event.
The value must be one of the options the run is waiting for. Otherwise it answers invalid_choice.

A refused choice changes nothing. An accepted choice continues the same run from its waiting step, and the run's recorded steps keep the render and sequence. An action that changes data still waits for confirmation. In Studio, a saved workflow run that waits for one of a list of options shows these buttons.