# Views

> A view is a named query plus a rendering configuration over the same records; the view types a pod implements.

URL: https://docs.synap.live/docs/build/concepts/views · Status: beta

## The Idea in One Line

> Same data. Any lens. No code changes.

A view is not a copy of your data — it is a named query + rendering configuration. Change the view type and the same entities become a kanban board, a timeline, a graph, a masonry feed. The data never moves. Only the lens changes.

This is Config-over-Code in action: **every view is a JSON configuration**. AI can generate a complete dashboard from a plain-language description. No developer required.

## View types

The view types a pod implements are defined in `packages/types/src/renderables/views.ts` of the backend repository.
19 are implemented:

| Category | View types |
|---|---|
| Structured | `sheet`, `table`, `list`, `grid`, `gallery`, `kanban`, `matrix`, `masonry`, `calendar`, `gantt`, `timeline`, `graph`, `flow`, `map`, `zoom_map` |
| Canvas | `whiteboard` |
| Special | `pipeline`, `branch_tree`, `bento` |

Not every implemented type can be created as a new view: `table` (superseded by `sheet`), `branch_tree` (only
meaningful inside a conversation), `zoom_map` (retired as a new view) and `pipeline` (created by its own flows) remain
renderable for existing views but are not offered when you create one. `mindmap` is defined but not implemented.

New view types are adapters in the view renderer; the data layer does not change.

## AI-Generated Views

Because every view is a configuration, AI can generate views from natural language:

- *"Create a pipeline view of my deals grouped by stage"* → kanban config, `groupBy: dealStage`
- *"Build a team dashboard with open tasks, recent activity, and deal velocity"* → bento config with 3 widget blocks
- *"Show me a graph of how my contacts relate to each other"* → graph view config

The AI writes the config. The view renderer runs it. No code touched.