FabricFabricExperiments
Platform

Studio UI

The organization-scoped UI for experimentation, Databricks quality evidence, governance, and enterprise identity.

apps/studio is a Next.js UI over @fabricorg/experiments-api-client.

Studio does not access the database directly. Server components and server actions forward the user cookie to apps/api, preserving a single auth and authorization boundary.

Fabric family experience

Studio uses the same application language as Fabric Runway and Fabric GTM Brain:

  • warm paper canvas, elevated white surfaces, and thin warm borders,
  • near-black ink with burnt-sienna actions, links, active states, and focus rings,
  • Geist for interface text, Fraunces for display headings, and Geist Mono for technical content,
  • the official theme-aware Fabric wordmark with an adjacent Experiments product suffix,
  • compact navigation, modest corner radii, and semantic status colors,
  • system light and dark themes, reduced-motion support, visible keyboard focus, and touch-sized controls on coarse pointers.

The visual layer does not change Studio's organization, authorization, experiment, Quality, or governance boundaries. The repository-level Fabric family contract rejects regressions to product-specific fonts, blue or purple branding, substitute logos, and inaccessible legacy color aliases.

Reusable cross-application interaction patterns come from the public @fabricorg/ui package. Prompts and Skills now consume its identical authoring shell and tree contract; Experiments retains all prompt, Skill, tenant, version, and governance behavior.

Organization model

Studio follows the same SaaS shape as the main Fabric app:

  • Better Auth owns user and organization identity.
  • New users create an organization at /app/new-organization.
  • Organization routes are URL-scoped: /app/{orgSlug}/....
  • Org switches redirect to the selected org URL.
  • API calls resolve the org slug to an organization ID before making org-scoped requests.

Current surfaces

  • sign up and login,
  • first-run organization creation,
  • organization switcher,
  • unified organization Overview with Experiment, Validate, and Govern paths,
  • workspace readiness checklist and experiment/Quality/governance health,
  • six-stage dotted lifecycle map,
  • experiment Pipeline and Table views,
  • drop-in install snippet generator,
  • five-section no-code experiment create/edit workflow with Mojito-parity fields,
  • generated spec preview,
  • YAML import using the shared @fabricorg/experiments-yaml parser,
  • document-oriented prompt authoring with GitHub-flavored Markdown write/preview,
  • tenant-scoped, versioned Skills with rendered instructions, declared permissions, approval policy, and behavior test cases,
  • split composer/result Playground with optional pinned Skill composition and rendered Markdown model output,
  • durable prompt + Skill replay over frozen datasets and evaluator sets,
  • experiment detail,
  • frequentist and Bayesian result views,
  • CUPED-adjusted rates and variance reduction,
  • time-to-convert, conversion-depth, and explicit-dimension segment tables,
  • lifecycle actions: submit for review, approve, start, pause, resume, conclude, kill,
  • audit log,
  • Quality Center for BDD scenarios, Databricks live checks, JUnit runs, CI revision metadata, structured failures, and Databricks query-history links,
  • Harness agents for the live Fiber job catalog, mutation safety, terminal setup, and the latest operator certification state,
  • organization API key management,
  • production Quality promotion policy, evidence freshness, retention, and legal hold,
  • enterprise SAML/OIDC sign-in and SCIM provisioning endpoints.

One product, two evidence types

Studio has two result surfaces with distinct jobs:

SurfaceAnswersInputs
ExperimentsDid a treatment change a product or business metric?Exposures, conversions, assignments, covariates, dimensions
QualityDid a workload, table, pipeline, notebook, job, contract, or CLI preflight behave correctly?BDD evidence, Databricks live-suite JSON, JUnit XML, Fabric CLI check JSON

The Harness agents page connects those surfaces operationally. It shows the finite jobs available to fx harness fiber, links their scheduled certification to Quality Center, and documents which inputs can produce side effects. Fiber is a terminal operator for experiment workflows; Quality remains the retained history for BDD, live workload, and CLI evidence.

Use fx login once and fx test publish to send runner evidence to /app/{orgSlug}/quality. The run detail page preserves scenario/check status, duration, failure details, environment and revision metadata, artifact links, and Databricks resource links. See Publish results to Quality Center. History is paginated and every list/detail lookup is scoped by the authenticated organization ID.

See Prompts, Skills, and Playground for the authoring model, Markdown behavior, Skill lifecycle, and evaluation flow.

No-code experiment authoring

The authoring form builds an ExperimentSpec and submits domain actions through the hosted API. It supports beginner-friendly fields plus Mojito-parity controls for:

  • sample rate and holdback,
  • manual exposure,
  • divert-to-variant,
  • trigger DSL (auto, urlMatch, waitForSelector, event),
  • variant payloads,
  • recipe sample rate,
  • declarative DOM operations,
  • raw variant JS/CSS for advanced migrations,
  • shared JS/CSS and metadata.

The form still shows the generated spec so teams can move between no-code Studio authoring and YAML/GitOps.

The form navigation groups those fields into Basics, Activation, Variants, Metrics, and Review. These are authoring sections rather than persisted lifecycle states; they remain mounted so native required-field validation continues to work when a user follows an anchor.

The authoring form submits domain actions through the hosted API:

  • create uses experiment.create,
  • edit uses experiment.update,
  • lifecycle buttons use the corresponding experiment.* actions,
  • updates publish the manifest after successful mutation.

Variant set changes are policy-protected after an experiment starts. The edit UI warns users about this before saving running, paused, or concluded experiments.

Lifecycle experience

Studio projects the governed domain state machine into six visual stages:

Visual stageDomain states
Designdraft
Reviewreview
Readyapproved
Liverunning, paused
Decisionconcluded, killed
Archivearchived

The organization Overview gives new users three explicit jobs: run an experiment, validate a Databricks workload, or govern a release. The Experiments page defaults to a dotted Pipeline but retains a dense Table view. Detail pages render the same lifecycle as completed, current, and upcoming steps, with explicit text labels in addition to color.

This presentation layer does not introduce new domain transitions. Actions still pass through the existing API command handlers and audit trail.

Studio actionAllowed fromResultGuard
Submit for reviewdraftreviewCurrent spec is valid.
ApprovereviewapprovedAuthenticated approver differs from the owner.
StartapprovedrunningApproval evidence exists.
PauserunningpausedManual or applied guardrail action.
ResumepausedrunningKeeps the existing assignment configuration.
Killrunning, pausedkilledCannot be resumed.
Declare winnerrunningconcludedWinner variant and justification are required.
Archivekilled, concludedarchivedFinal state.

Studio hides actions that are not valid for the current state, while the API independently rejects every invalid transition. Approval identity, tenant, and owner identity come from the authenticated request context rather than form fields.

YAML import

The import page accepts one or more .yaml or .yml files. Files are parsed in the browser with the shared YAML package, then valid specs are sent to a server action.

Import behavior:

  • if the experiment ID does not exist, Studio invokes experiment.create,
  • if the experiment ID exists, Studio invokes experiment.update,
  • after all imports succeed, Studio publishes the manifest and revalidates experiment/audit pages.

Install snippet

The /app/{orgSlug}/install page generates the customer drop-in snippet for marketing sites and GTM. It includes the tenant manifest URL and tag-loader URL, but does not include a preview secret. Studio preview links are short-lived JWTs signed by the API and verified in the browser with public JWKS.

API keys

Org admins can create and revoke hosted API keys from /app/{orgSlug}/settings.

API keys are intended for CLI and automation workflows such as:

fx push experiments/ --api-url https://api.example.com --api-key fx_key_... --tenant <orgId>

The plaintext key is shown exactly once on creation. Active keys show their prefix, creation time, and last-used timestamp.

SaaS alignment

Studio mirrors the important Fabric SaaS boundaries for customer adoption: Better Auth-owned users and organizations, URL-scoped organization context, explicit organization switching, cookie-forwarded server actions, org-scoped API keys, SAML settings, audit visibility, and product APIs around authorization.

The result is a focused experimentation UI rather than a generic admin console: customers can onboard, install the tag-loader, create or import experiments, preview variants, promote lifecycle states, and automate with API keys without leaving Studio.

On this page