> ## Documentation Index
> Fetch the complete documentation index at: https://docs.summand.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core concepts

> How connectors, datasets, views, experiments, and components fit together.

Summand's data model is small. Most of the product makes sense once you've internalized seven terms.

<CardGroup cols={2}>
  <Card title="Connector" icon="plug" href="/concepts/connectors">
    A pointer to where your data lives — a CSV upload, a database, a Fivetran-managed source, a Delta Sharing endpoint.
  </Card>

  <Card title="Dataset" icon="table" href="/concepts/datasets">
    A specific table within a connector, with a curated Parquet copy that everything else queries.
  </Card>

  <Card title="View" icon="layer-group" href="/concepts/views">
    A saved SQL transformation over one or more datasets, with a visual builder and live Athena preview.
  </Card>

  <Card title="Experiment" icon="flask" href="/concepts/experiments">
    A scheduled run of one or more components against a dataset or view. Cron-driven, versioned outputs.
  </Card>

  <Card title="Component" icon="puzzle-piece" href="/concepts/components">
    A unit of analysis — predictors, surprise finding, column stats, custom — with typed inputs and outputs.
  </Card>

  <Card title="Semantic layer" icon="layers" href="/concepts/semantic-layer">
    The bundle of artifacts each experiment run writes: column stats, model graphs, embeddings.
  </Card>

  <Card title="Sharing" icon="users" href="/concepts/sharing">
    Per-user grants plus visibility settings, enforced through OpenFGA on every read.
  </Card>
</CardGroup>

## How they fit together

```
Connector (CSV / Postgres / MySQL / Snowflake / Azure SQL / Delta Sharing / Fivetran)
   └── Dataset (one per table, curated Parquet copy)
         │
         ├── Chat — Summand, grounded in the dataset
         │
         ├── View(s) — SQL transformations, optionally cross-dataset
         │      └── Chat or experiments can target a view instead of the dataset
         │
         └── Experiment(s) — scheduled component runs
                └── Components produce semantic-layer artifacts per run
                      └── Visible to chat, queryable downstream
```

A connector can have many datasets — one per table for databases. CSV connectors are always single-dataset. Datasets are the unit you chat about, query in views, and target with experiments.

## Identifiers

Every resource has a stable, URL-safe ID:

| Resource                  | Prefix | Example                   |
| ------------------------- | ------ | ------------------------- |
| Connector                 | `con_` | `con_01J5R...`            |
| Dataset                   | `ds_`  | `ds_01J5R...`             |
| View                      | —      | UUID-keyed under the user |
| Experiment                | —      | UUID-keyed                |
| Run (component execution) | `run_` | `run_01J5R...`            |

IDs are immutable. Display names can change without invalidating shared links.

## Lifecycle

1. **Create connector** — upload a CSV or point Summand at a data source.
2. **Datasets land automatically** — for CSVs, one dataset on upload; for databases, one per table you enable.
3. **Pick an action**:
   * **Chat** with Summand for ad-hoc questions.
   * **Create a view** to save a SQL transformation you'll re-use.
   * **Create an experiment** to schedule recurring analysis.
4. **Read results** — through chat, in the global Surprises page, or in a view that pulls experiment outputs.
5. **Share** — invite teammates with explicit grants, or change visibility.
6. **Refresh** — for live sources, click *Refresh* to re-read; experiments will re-run on their next schedule against the fresh data.