PRD: Generative UI Trust Runtime

Document ID: PRD-005 File Path: docs/01-product/prd-generative-ui-runtime.md Version: 1.0.1 Status: Shipped (v1.2 scope) — RM-GUI Phases 1–3 complete (2026-07-15) per the v1.2 roadmap; deliberately deferred slices (the GRD-203 LLM-judge variant, EMB-702’s outbound MCP tools) remain open per §10 Owner: Product / Founder Last Updated: 2026-07-15

1. Purpose

PRD-003 made the platform safe and honest. PRD-004 made it a capable, operable AI product. This PRD answers the question neither of them asked: what is the product, and who buys it?

It repositions Wovyr from a horizontal “AI Agent Operating System” — a crowded, capital-intensive category — into a focused wedge product built on that platform: the Generative UI Trust Runtime: the infrastructure that lets AI agents render rich, interactive interfaces to humans safely, auditable, and with a durable human-in-the-loop decision cycle.

The product thesis combines three market plays into one coherent offering:

The trust & security layer for generative UI — when an AI draws the interface at runtime, every existing security assumption of the web breaks. A generated form can be a hallucinated phishing vector; prompt injection can manifest as UI. Wovyr validates, constrains, sandboxes, and audits every generated interface before a human sees it.
Generative UI for enterprise internal tools — the beachhead vertical. Internal dashboards, admin panels, and ops consoles that generate themselves around the operator’s intent, backed by the platform’s tenancy, RBAC, and audit.
The UI layer for the agent economy — the runtime any agent (Wovyr-native or external, via MCP) uses when it needs to show a human something or ask a human for a decision: structured UI frames out, validated human decisions back, durably, with the workflow suspended in between.

The strategic decision behind this repositioning is recorded in ADR-0011. Execution is phased in the v1.2 roadmap.

This is a planning input, not a promise. Requirements graduate to committed work through the roadmap and, where they change a boundary contract, through an ADR.

2. Problem Statement

2.1 The market problem

Software interfaces are shifting from hard-coded pages to interfaces generated at runtime around user intent — Google ships generative UI in Gemini’s dynamic view and AI Mode in Search; standards (A2UI, MCP Apps, AG-UI) are emerging; the AI-powered design/interface tooling market is ~$8.2B in 2026 growing >20% CAGR. Meanwhile every agent product on the market talks to users through walls of text, because rendering generated UI safely is an unsolved infrastructure problem:

No enforcement point. Generated UI reaches the user’s screen unvalidated. Nothing today can express or enforce “an agent-generated interface may never render a payment-credential field” or “a destructive action button must carry a human-approval gate.”
No provenance. When a user claims “the AI showed me a confirm button and I clicked it,” no system of record can prove what was actually rendered, to whom, with what content, generated by which model from which prompt.
Prompt injection becomes UI injection. A poisoned tool result or retrieved document can steer the model into rendering a deceptive interface — the phishing page is now generated inside the trusted product’s own chrome.
The decision loop is not durable. “Agent shows options → human picks one → agent continues” is the fundamental interaction of the agent era, and in every mainstream framework it lives in ephemeral process state — a crash, deploy, or timeout loses the interaction.
Enterprises can’t adopt what they can’t govern. Security teams block generative-UI features for exactly these reasons. The absence of a governance layer is the adoption bottleneck — and therefore the product opportunity.

2.2 The positioning problem

As a horizontal agent platform, Wovyr competes with LangGraph, Temporal, the Vercel AI SDK, and every cloud vendor’s agent framework. As the trust and interaction runtime for agent-generated UI, it competes with almost nobody today, and the platform’s existing depth (sandboxing, audit, signing, durable workflows) converts from maintenance burden into unfair advantage. Same code, different company.

3. Baseline (as of 2026-07-14): what the platform already provides

The repositioning is credible precisely because the hard backend half exists:

Existing asset	Role in this product
Durable workflow engine — `ActivityError::Interrupted`, `wait`/`signal`, `human` activities that suspend durably and resume via server signal	The decision loop: agent renders UI → execution suspends durably → human decision arrives as a signal → execution resumes. Crash-safe by construction
Agent run loop streaming structured events over SSE (`RunEventSink`: deltas, tool-call fragments, reasoning)	The transport: UI frames become a new event type on an already-shipped channel
`Guardrail` trait — staged Allow/Redact/Block, fail-closed, output buffering	The architectural pattern for the UI policy engine: a UI frame is checked before anything renders, or nothing renders
Tamper-evident hash-chained audit log (`wovyr-audit`)	The provenance layer: a verifiable record of every frame shown and every decision taken
Plugin signing (ed25519) + marketplace + human-review verified badge	The signed component registry: UI component templates as signed, reviewed, versioned artifacts
Sandbox spectrum (native/WASI/container/gVisor/microVM) incl. in-process Wasmtime with fuel/memory limits	Isolation for untrusted UI logic (validators, custom component behaviors)
Multi-tenancy, RBAC, quotas, KMS, secrets vault	The enterprise floor the beachhead sale requires
MCP client (`wovyr-tools::mcp`)	The interop on-ramp: external agents and tool servers reach the UI runtime through open protocol
TypeScript + Python SDKs	The base for the renderer SDK

The gap this PRD closes: the entire UI-facing half — a frame protocol, a policy engine, a renderer SDK, the human-decision API surface, and the packaging that makes all of it embeddable in someone else’s stack in an afternoon.

4. Goals & Non-Goals

4.1 Goals

G1 — Ship the UI frame protocol: a declarative, schema-validated representation of agent-generated interfaces, transported over the existing agent/workflow event stream, designed for compatibility with emerging open standards (A2UI / MCP Apps shapes) rather than as a proprietary invention.
G2 — Ship the trust layer (wovyr-ui-guard): declarative policy validation of every frame before render (forbidden field classes, intent-consistency, deception-shape checks), fail-closed, with every allow/redact/block decision recorded in the tamper-evident audit chain.
G3 — Ship the interaction loop: a first-class “render frame → suspend durably → receive validated decision → resume” primitive, built on the existing human/wait workflow machinery, exposed via API + SDKs.
G4 — Ship the renderer SDK: an embeddable TypeScript/React (+ web component) runtime that renders validated frames and returns typed decisions. Meet the market where it is; Angular dashboard consumption follows.
G5 — Ship the beachhead surface: a generative internal-tools experience on the dashboard — operator intent in, governed adaptive interface out — as the first packaged, sellable expression of G1–G4.
G6 — Be embeddable: a team running LangGraph/Vercel AI/plain API calls can adopt the trust runtime as middleware + SDK without migrating their stack.
G7 — Prove it with design partners: five external teams shipping agent products using the runtime, with the killer demo (§9) reproducible from the repo.

4.2 Non-Goals

Building a browser. The runtime is embedded in hosts (web apps, dashboards, agent products); a consumer browser is explicitly out of scope (see the market analysis in ADR-0011 §Context).
Inventing a closed UI standard. We adopt/extend open shapes and win on the runtime and enforcement, not the schema.
A visual design tool. No Figma competitor, no drag-and-drop builder.
General-purpose arbitrary HTML/JS rendering of model output. The security model depends on a constrained, declarative component vocabulary; raw model-authored HTML/script is rejected by design.
Replacing the platform roadmap. v1.1 Phase 3 (ecosystem & scale) items continue where they serve this product; purely horizontal platform breadth is deprioritized, not deleted.

5. Personas & Use Cases

5.1 Personas

P1 — Agent product engineer (primary): ships an agent feature inside a SaaS product; needs the agent to show seat maps / comparisons / confirmations, not paragraphs; blocked by security review.
P2 — Enterprise security engineer (the approver, often the economic buyer’s gatekeeper): must answer “what can the AI show our users, and can we prove what it showed?”
P3 — Internal-tools / platform-ops engineer (beachhead buyer): drowning in requests for one-off dashboards and admin panels; wants governed, self-generating internal surfaces.
P4 — Compliance / audit officer: needs the rendered-interface system of record after the fact.

5.2 Canonical use cases

UC1 — Governed confirmation: a procurement agent composes an order-confirm interface; policy blocks the variant containing a card-number input, allows the safe variant; the user’s Approve click resumes the durable workflow; the entire exchange is in the audit chain. (This is the killer demo, §9.)
UC2 — Generative internal tool: an on-call operator types “show me failed workflows for tenant X in the last hour, with retry buttons” — the surface generates itself, every action button mapped to a permission-checked API call, destructive ones gated by the human-approval activity.
UC3 — External agent, embedded trust: a team’s existing (non-Wovyr) agent emits frames to the runtime over HTTP/MCP; gets back policy verdicts and, eventually, the user’s decision — Wovyr as middleware, not as their framework.
UC4 — Injection containment: a poisoned retrieval document steers a model toward rendering a credential-harvesting form; wovyr-ui-guard blocks the frame class, the block lands in the audit log, the user never sees it.

6. Workstreams & Requirements

Requirement IDs are stable and referenced by roadmap tickets (RM-GUI-P1..P3). Each requirement is testable; “fail-closed” carries the same meaning as in PRD-003/004: an error or an unvalidated state must never degrade into rendering.

WS1 — UI Frame Protocol (`wovyr-ui`, new crate) — UIP-1xx

UIP-101 Define UiFrame: a versioned, declarative, JSON-serializable tree over a constrained component vocabulary (layout, text, media-by-reference, input controls, action buttons), each node typed and schema-validated (schemars, consistent with SBX-303). No raw HTML, no script, no external resource loading by URL without an explicit allow-listed media policy.
UIP-102 Frames carry provenance metadata: run/execution id, generating model id, prompt/template reference (SAF-202 registry pin where used), content hash. Hash is computed over the canonical serialized form.
UIP-103 Frames carry intent declarations: each actionable node (button, form submit) declares the machine-readable effect it will trigger (tool call, workflow signal payload, URL). No anonymous actions — undeclared effects are a validation error.
UIP-104 Transport: a UiFrame event on the existing RunEventSink → SSE channel (pattern of AIC-202), and as a workflow activity output. Non-streaming fetch of the current pending frame via REST for pull-based hosts.
UIP-105 Interop mapping: documented, tested translation to/from the emerging open shapes (A2UI-style component JSON; MCP Apps resource/tool conventions) so external agents can target the runtime without adopting Wovyr end-to-end. The mapping is versioned; unsupported foreign constructs fail closed with a named reason.
UIP-106 Protocol versioning: UiFrame carries a semver’d schema version; runtime rejects newer-than-understood frames (same stance as MIG-A1’s schema-version refusal).

WS2 — UI Trust & Policy Engine (`wovyr-ui-guard`, new crate) — GRD-2xx

GRD-201 A UiPolicy declarative document (YAML, like agent/workflow manifests): rules over frame structure and content — forbidden component classes (e.g. password_input, payment_card_input deny-by-default), required approval gates on action classes, content redaction rules, allowed media origins, maximum interaction depth.
GRD-202 Enforcement is a guardrail stage: UiGuard implements the existing Guardrail-shaped contract (Allow/Redact/Block, fail-closed) applied to every frame between generation and emission. With a UI guard configured, no raw frame reaches the sink unchecked — the SAF-201 buffering stance applied to frames.
GRD-203 Intent-consistency check: the declared effect of every actionable node (UIP-103) is validated against the actual bound target — a button whose label/semantics class says “cancel” cannot bind to a destructive tool call class; a frame generated in a run whose stated goal is X carrying actions of class Y requires policy opt-in. (Heuristic + optional LlmModerator-style schema-constrained judge, same self-judging-bias caveats as SAF-201.)
GRD-204 Deception-shape checks: block frames that visually impersonate host chrome or auth surfaces (component vocabulary + policy make most of this structural: there simply is no “browser chrome” component; credential-input classes are deny-by-default per GRD-201).
GRD-205 Every verdict (allow/redact/block, rule id, frame hash) is recorded through wovyr-audit’s hash chain. A blocked frame’s content is retained (encrypted at rest via the existing KMS envelope path) for forensics, policy- controlled.
GRD-206 Policies are tenant-scoped (via wovyr-tenancy), versioned, and immutable-once-referenced (SAF-202 pin semantics); a run records which policy version judged its frames.
GRD-207 Fail-closed floor for hosted runs: a hosted deployment with no UI policy configured denies frames carrying input/action nodes (display-only frames pass) — mirror of SEC-303’s deny-all default; WOVYR_UNRESTRICTED_UI=1 is the documented trusted-first-party escape hatch.
GRD-208 Custom validators run sandboxed: a tenant-supplied validation hook executes as a wasm32-wasi module in the existing WasiSandbox (fuel/memory limits), never natively in the server process.

WS3 — Interaction Loop (durable decisions) — HIL-3xx

HIL-301 A ui workflow activity: emits a validated frame and suspends durably (built on the existing Interrupted/Waiting machinery); the activity’s output is the human’s decision payload.
HIL-302 Decisions are typed and validated: a decision must match one of the frame’s declared actionable intents (UIP-103) and its input values must satisfy the frame’s input schemas — an out-of-vocabulary decision is rejected fail-closed at the API boundary, never delivered to the workflow.
HIL-303 Decision API: POST /api/v1/ui/decisions/{frame-id} (authenticated, RBAC-checked — the decision taker is recorded, not just the decision), internally a workflow signal (reuse of the human-approval signal path).
HIL-304 Agent-loop integration: run_agent supports a “present frame, await decision” step so single-agent runs (not only workflows) get the loop; budget/step accounting per AIC-101/103 applies.
HIL-305 Timeouts & escalation: a pending frame may carry a durable timer (existing G1 timer machinery) with policy-defined expiry behavior (fail/default/escalate).
HIL-306 Decisions land in the audit chain with the frame hash they answer — the pair (frame shown, decision taken, by whom, when) is the product’s core evidentiary object.

WS4 — Renderer SDK — RDR-4xx

RDR-401 @wovyr/ui-react: a React component that consumes the SSE frame stream (or pull API), renders the component vocabulary with a themeable design-token system, and posts decisions to HIL-303. Zero required backend besides the Wovyr server.
RDR-402 A framework-agnostic web-component build sharing the same core, for non-React hosts (incl. the Angular dashboard).
RDR-403 The renderer verifies frame integrity (hash) and renders only vocabulary components — unknown node types render as a visible, inert “unsupported” placeholder, never skipped silently, never interpreted loosely.
RDR-404 Streaming ergonomics: progressive frame rendering as the model composes (the ToolCallDelta coalescing pattern the dashboard test console already uses), with the guard-buffering rule: with an output UI guard configured, only checked frames render (GRD-202 supersedes streaming).
RDR-405 Accessibility floor: vocabulary components ship WCAG-conformant by construction (labels, focus order, contrast tokens) — “adaptive interfaces are accessible interfaces” is a stated product differentiator.
RDR-406 SDK docs + quickstart: frame-to-pixel in under 30 minutes on a fresh React app (measured, part of acceptance).

WS5 — Signed Component & Template Registry — CMP-5xx

CMP-501 UI component templates (parameterized frame fragments) are packageable, ed25519-signed artifacts (the existing plugin signing/verification path) with semver’d compatibility ranges.
CMP-502 The marketplace’s human-review verified-badge workflow extends to UI templates: a “verified” template class that stricter policies can require (GRD-201: “only verified templates may render payment-adjacent flows”).
CMP-503 Template resolution is registry-pinned like prompts (SAF-202): a pinned template renders byte-identically across runs.

WS6 — Beachhead: Generative Internal Tools — ITS-6xx

ITS-601 A dashboard “Surfaces” area: operator intent (natural language) → agent-composed internal tool frame over the platform’s own APIs (workflow list, memory, tenancy admin) — dogfooding UC2 on Wovyr’s own operational surface.
ITS-602 Every action node binds to a permission-checked API call under the operator’s own RBAC identity — the generated UI can never do what its viewer cannot (enforced server-side at decision time, HIL-303, not just at render).
ITS-603 Destructive action classes auto-gate through the human-approval activity (a second approver or explicit confirm policy, tenant-configurable).
ITS-604 Surfaces are saveable/shareable as pinned template + policy pairs — the “six hand-built report views become one adaptive view” story, reproducible.

WS7 — Embeddability & Ecosystem — EMB-7xx

EMB-701 Standalone mode: the trust runtime (WS1+WS2+WS3 API) runs as a middleware service in front of any agent stack — frames in over HTTP, verdicts and decisions out — no Wovyr agent/workflow adoption required. One binary, the appliance stance of ADR-0010.
EMB-702 MCP surface: expose the runtime as MCP tools (ui_present, ui_await_decision) so MCP-speaking agents get governed UI with zero custom integration; complement of the existing MCP client.
EMB-703 Python/TS SDK parity for frame emission and decision consumption.
EMB-704 A public conformance suite: policy test vectors (frames that must block/redact/pass) any deployment can run — the security claim is verifiable, not marketed.

7. Phasing

Detailed tickets live in the v1.2 roadmap.

Phase	Theme	Workstreams	Exit criterion
P1 — Protocol & Trust Core	Frames exist and are governed	UIP-1xx, GRD-201..207, HIL-301..303	UC1/UC4 pass end-to-end against the server API (no renderer yet — assertions over the SSE stream + audit chain)
P2 — Renderer & Interaction Loop	Humans see and decide	RDR-4xx, HIL-304..306, GRD-208, CMP-5xx	The killer demo (§9) runs from a fresh clone in <10 min; SDK quickstart <30 min
P3 — Beachhead & Embeddability	Sellable and adoptable	ITS-6xx, EMB-7xx	Dashboard Surfaces dogfooded on Wovyr’s own ops; standalone mode + MCP surface documented; ≥5 design partners onboarded

8. Success Metrics

Adoption: 5 design partners by P3 exit; SDK quickstart-to-first-frame < 30 min (measured on partner onboarding, not self-reported).
Security efficacy: 100% of the conformance suite’s must-block vectors blocked (EMB-704 is the gate, run in CI); zero policy bypasses in partner red-team exercises.
Provenance: every rendered frame and every decision resolvable to a verified audit-chain entry (verify() clean) in all partner deployments.
Durability: UC1 survives a server kill between frame render and decision (existing crash-recovery test pattern extended to the ui activity).
Business: ≥2 design partners convert to paid pilots; the pitch demo (§9) is the seed-deck centerpiece.

9. The Killer Demo (acceptance narrative)

A procurement agent is asked to reorder lab supplies. It composes a checkout confirmation. Take 1: the model (steered by a poisoned vendor page) includes a card-number input — wovyr-ui-guard blocks the frame, the block is in the audit chain, the user never sees it. Take 2: the safe variant renders in the React SDK; the workflow is durably suspended; the server is killed and restarted; the frame is still pending; the user clicks Approve; the workflow resumes and completes; wovyr audit verify proves the whole exchange — what was shown, what was blocked, who approved, when.

Every clause above maps to a requirement; the demo is an integration test first and a sales asset second.

10. Risks & Mitigations

Risk	Mitigation
Standards war resolves against our chosen mapping (A2UI/MCP Apps shift)	UIP-105 isolates interop in a versioned mapping layer; the enforcement/runtime value is schema-agnostic
Big platforms bundle “good enough” UI trust	Depth moat: tamper-evident audit + durable decisions + sandboxed validators are years of infrastructure, already built; sell to the bundlers (EMB-701)
Constrained vocabulary too limiting for real products	Vocabulary is versioned and extensible via signed templates (CMP-5xx); pressure-test with design partners in P2, not after
Renderer is the weakest muscle (backend-heavy history)	P2 exit criteria are DX-measured; consider a design-partner co-build or frontend hire as the explicit staffing ask
Solo-founder bandwidth across 7 workstreams	Phases are strictly sequential-exit; P1 is server-side only (home turf); cut line documented per phase in the roadmap
LLM-judge checks (GRD-203) over-block and erode trust in the guard	Structural rules are the floor and never bypassed; judge checks are policy-opt-in, shadow-mode first (observe-then-enforce, the PRV-101 stance)

11. Relationship to Other Docs

ADR-0011 — the decision this PRD executes.
v1.2 roadmap — phased tickets.
PRD-004 — v1.1 P3 (ecosystem & scale) items are re-prioritized through this PRD’s lens: MCP surface work and SDK distribution serve EMB-7xx; purely horizontal breadth is deferred.
Vision — updated to reflect the wedge-first strategy (platform as engine, trust runtime as product).

12. Revision History

Version	Date	Description
1.0.1	2026-07-15	Status updated Draft → Shipped (v1.2 scope): RM-GUI Phases 1–3 all landed per the v1.2 roadmap; no content changed
1.0.0	2026-07-14	Initial PRD: repositioning Wovyr as the Generative UI Trust Runtime — trust layer + internal-tools beachhead + agent UI runtime