Skip to main content
Curious writes the variants. options.approval decides whether a person reads them before users do.

Two modes

  • "manual": generated variants enter a review queue. They do not serve until someone approves them in the dashboard. While any variant is pending, Curious generates no more, so the queue never piles up.
  • "auto": generated variants serve as soon as they exist, within the format, the requirements and the instructions you declared.

The default is manual

When a declaration does not set approval, the experiment takes the running experiment’s value if it is a successor, then the organization’s default from the dashboard, and otherwise manual. A new account therefore reviews everything until it chooses not to. The value is stored on the experiment when it is created and updates in place when you change it, so a later change of defaults never alters a live experiment underneath you.

What pending looks like from the API

Nothing changes in your code. A decision for an experiment whose variants are all pending serves the control, and experiment_status stays initializing until the first variants are live. If decisions keep returning the control after the experiment should have started, pending approval is the first thing to check: see Every decision returns the control. You are notified by email while variants wait.

Reviewing

Each pending variant shows its content and the hypothesis behind it. Approving makes it live. Rejecting takes it out, with an optional note; rejected variants and their notes ride the next generation round as negative examples, so a rejection teaches rather than just filters. You can also conclude a live variant by hand when you want it gone.

Your own variants

Variants you declare through arms are validated synchronously and serve at once, whatever the approval mode: declaring is reviewing.