PromptUI does not treat every prompt the same. The current architecture starts by clarifying the request, then routes the build into the cheapest lane that can still meet the quality bar.
Step 1: Clarification first
PromptUI starts by understanding what the user is actually trying to ship. That means product intent, app surface, and complexity come before code generation. This is one of the biggest differences between PromptUI and one-shot code generators.
Step 2: Route to the right build lane
For simpler prompts, PromptUI can use a fast path. For larger or riskier builds, it uses the quality pipeline. For higher-risk cases under controlled beta, Verified Builder adds a stronger verification lane before the session is treated as ready.
The key idea is that model choice matters, but lane choice matters even more. A strong model on the wrong lane still produces the wrong trade-off.
Step 3: Generate, validate, and repair
Once the lane is chosen, PromptUI writes files, validates output, patches structural issues, and keeps the proof attached to the session. That includes the preview surface, policy/repair checks, and deploy handoff when the build is ready.
Step 4: Preview and deploy
PromptUI is designed so the generated app is not the end of the workflow. The system keeps preview, share, and deploy close to the same build record, which makes product review and follow-up much simpler.
Step 5: Carry the product story forward
After build and deploy, the same product context can move into Growth Agent for launch workflows and Creator Video for storyboards, captions, render passes, and media packaging.
Where Verified Builder fits
Verified Builder is important, but it should be described precisely. It is a stronger controlled-beta lane for higher-risk prompts, not a blanket claim that every public build now runs through the same deep verification path.