Skip to main content
An experiment is a recurring run of one or more components (predictors, forecasts, column stats and others) against a dataset or view. Experiments are how recurring analysis happens in Summand — instead of remembering to re-run a notebook, you wire up an experiment and it runs forever.

​
Anatomy

Experiments are stored as DynamoDB items keyed under the user. EventBridge Scheduler is what actually fires them on cron — Summand’s runtime is Lambda + Step Functions, not a long-running scheduler service.

​
Schedule options

Six presets cover the common cases:
  • Daily at 3 AM (cron(0 3 * * ? *))
  • Daily at 6 AM
  • Every 6 hours
  • Every 12 hours
  • Weekly Monday 3 AM
  • Weekly Sunday 3 AM
Or write your own AWS EventBridge cron / rate expression:
Note that EventBridge cron uses six fields, not the standard five — the day-of-week field has special semantics. The in-product editor validates and surfaces a human-readable description (e.g. “At minute 0, every 6 hours”) so you can sanity-check before saving.

​
Components

A component is a unit of analysis with declared inputs and outputs. The component catalog defines what’s available; today it includes:
  • Predictors — fit an EBM and write feature importance and shape functions.
  • Column stats — per-column distributions, missingness and cardinality.
  • Forecast, outlier report, correlations, missing-value patterns and distribution profile.
  • Computed-context pieces — UMAP, feature metadata, and similar artifacts.
Each component has typed inputs that the experiment editor renders as form fields (number inputs for thresholds, dropdowns for column references, etc.). For example, the Predictors component has an input for “target column” — that’s where target column lives in the product today, not on the dataset. See Components for the full catalog and what each one does.

​
Sources: dataset vs. view

You can target either a dataset or a view:
  • Dataset — components run on the curated Parquet for that dataset. The simplest case.
  • View — components run on the SQL view’s output. Use this when you need to filter, join, or aggregate first, or when you want experiments to share a common definition (define the cohort once as a view, point multiple experiments at it).
An experiment can use a view you own or a view shared with you. You need read access to the view when you create the experiment, and a run is skipped if that access is later revoked.

​
Outputs

Each run writes:
  • A new computed-context version for the source, with each component’s output in S3.
  • A row in Run history with status, duration, and any error.
Outputs are queryable from chat (“what did the last predictor run say?”) and viewable on the dataset’s Components tab.

​
Run history

The experiment detail page shows the most recent runs with status (running / completed / failed), duration, and (on failure) the error message. Older runs paginate further back. Failed runs are kept — Summand doesn’t auto-retry. You can:
  • Manually re-run from the experiment detail page (a one-shot trigger; doesn’t change the schedule).
  • Edit and re-save to fix the configuration; the next scheduled tick picks up the change.
  • Pause if the underlying source is broken upstream and you don’t want to spam failures.

​
Manual triggers

Hit the Run now button to fire an experiment outside its schedule. The run shows up in history alongside scheduled runs; the next scheduled tick runs as normal. This is the right way to test a configuration before letting it go on cron.