UI
The web UI — what it's for, and when to reach for it instead of the CLI.
The UI is the human surface; the CLI is the automation surface. They expose the same features against the same backend — the difference is the contract. The CLI assumes you want to script things or point a coding agent at them. The UI assumes you'd rather read a preview in a browser than render it in a terminal.
Feature parity. Everything you can do in the UI, you can do with the CLI. The UI exists because some tasks — reviewing preview rows, writing freeform feedback, browsing the shape of a delivered dataset — are easier with a cursor and a scroll wheel than with a pipe and a flag.
The sections in this guide
Creating a dataset
Describe what you want; we design it from there.
Reviewing a preview
The three example rows, and how to approve or send feedback.
Managing Resources
Register a database or a document library your dataset should reflect.
Settings
Workspace, preferences, and developer options.
When to use which surface
Use the UI for judgment calls. Reviewing the three preview rows is the clearest example: you're making a human decision about whether the shape is right, and a browser is the natural place to make it. Writing freeform feedback — a paragraph of prose, not a flag — also belongs here. So does browsing your list of datasets to find the one you started last Tuesday.
Use the CLI for automation. Anything you'd put in a shell script — creating a dataset from a brief file, polling status in CI, downloading the finished artifact into a local folder — is cleaner from the terminal. And if you want your coding agent (Claude Code, Cursor, Windsurf) to drive the whole flow, the CLI is what it should reach for; every subcommand is progressively disclosable via --help. See Claude Code workflow.
The two surfaces share state. A dataset you create in the CLI shows up in the UI list, and vice versa. Approve a preview in the browser; download the artifact from a Makefile target. You don't have to pick one.
What's here and what isn't
The UI today covers the full dataset lifecycle (create, watch progress, review preview, approve or feedback, download) and the Resource lifecycle (register, inspect, remove). It does not expose internal factory state, per-rollout sandbox URLs, or any plumbing the CLI also hides — the surfaces stay aligned by design.
For auth, sign-in happens at /login. It's a redirect flow; there's nothing to document beyond "click the button." Your active workspace and any org-switching controls live in Settings.
Screenshots
We'll add screenshots throughout this section in a subsequent pass. For now every page describes what you'll see in words, section by section — enough that the docs are useful today and the images slot in later as <img> tags.