> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/references/dataos-resources/vulcan.md).
# Vulcan
Vulcan is the DataOS resource you use to build a data product as a single object. One project carries the transform logic, the semantic model, the contract, and the serving layer, so you define your data once and expose the same trusted definitions to dashboards, applications, and AI agents.
Vulcan runs on the engine you already use. It works directly on Postgres, Snowflake, Spark, Trino, BigQuery, Databricks, Redshift, and more, so no data movement happens unless you need it.
## Access requirements
Before creating or managing a Vulcan resource, ensure you have the required permissions. See [Vulcan: Access control](https://v2.dataos.info/operate/access-model/resource-level-permissions/vulcan-access-control).
## Why Vulcan exists
Most teams still work with raw tables and tribal knowledge. That works until another team, tool, or AI agent asks the same question. Then the wrong table gets picked, and the answer looks correct but is not.
A data product fixes that. It packages schema, semantics, ownership, lineage, quality, and freshness into one governed asset. Every consumer uses the same definitions and the same trust boundary.
If a contract lives inside one warehouse, it stays locked there. Most teams run more than one engine: analytics may live in Snowflake, operations in Postgres, and machine learning on Spark or a lakehouse. Vulcan sits above those engines, so the same data product contract reaches every consumer regardless of where the data physically lives.
## What you author in one project
Vulcan covers the full data product lifecycle in one stack:
1. **Input and output.** Point a single config at your engine. Vulcan runs your transformations on that engine, and no data leaves it unless you choose to move it.
2. **Transformation.** Build models in SQL, Python, or both in one project. Use `vulcan plan` to preview impact before execution, and `vulcan run` to apply changes on your schedule.
3. **Quality.** Catch issues before they reach consumers. The linter surfaces errors early, audits block bad rows at write time through assertions, data quality (DQ) checks watch for anomalies and drift, and tests validate logic locally without warehouse cost.
4. **Semantics.** Define dimensions, measures, segments, and metrics once. Vulcan validates them against your models and serves them through REST, GraphQL, and SQL APIs.
This flow turns raw data into a governed interface that every consumer can use.
```mermaid
%%{init: {"theme":"base","themeVariables":{"fontFamily":"PP Neue Montreal, Inter, Helvetica Neue, Arial, sans-serif","fontSize":"14px","primaryColor":"#EDE9E5","primaryTextColor":"#242422","primaryBorderColor":"#242422","lineColor":"#242422","secondaryColor":"#D6CDC6","tertiaryColor":"#FFFFFF","clusterBkg":"#EDE9E5","clusterBorder":"#54DED1","edgeLabelBackground":"#FFFFFF"},"flowchart":{"curve":"basis","padding":12,"nodeSpacing":40,"rankSpacing":50}}}%%
graph LR
subgraph VT ["Vulcan Timeline →"]
direction LR
Engine["Engine
Postgres · Snowflake · Spark · Trino · BigQuery · Databricks"] -.-> Config
Config["Config"] -.-> Linter["Linter
Code Safety"]
Config -.-> Notify["Notifications
Fires across lifecycle"]
Macros["Macros
Variables · Functions"] -.-> Model
Tests["Tests
Logic Validation"] -.-> Model
Signals["Signals
Readiness Gates"] -.-> Model
Config --> Model["MODEL
SQL · Python Transformations"]
Model --> Audits
Audits{"Audits
Blocking Rules"} -->|pass| Checks
Audits -->|pass| Profiles
Audits -->|fail| Stop(("STOP"))
Checks["dq
Data Quality"] --> Sem
Profiles["Profiling
Understanding"] --> Sem
Sem["Semantics
Dimensions · Measures · Segments · Metrics"] --> REST["REST API"]
Sem --> GraphQL["GraphQL API"]
Sem --> MySQL["SQL API"]
end
classDef primary-teal fill:#54DED1,color:#202F36,stroke:#009293,stroke-width:1.5px,font-weight:600;
classDef dark-teal fill:#009293,color:#FFFFFF,stroke:#242422,stroke-width:1.5px,font-weight:600;
classDef ember fill:#FF5537,color:#FFFFFF,stroke:#733635,stroke-width:1.5px,font-weight:600;
classDef cream fill:#EDE9E5,color:#242422,stroke:#242422,stroke-width:1px;
classDef sandpaper fill:#D6CDC6,color:#242422,stroke:#242422,stroke-width:1px;
classDef surface fill:#FFFFFF,color:#242422,stroke:#242422,stroke-width:1px;
class Engine,Config surface;
class Linter,Macros,Tests,Signals primary-teal;
class Model,Sem dark-teal;
class Audits,Stop ember;
class Checks,Profiles sandpaper;
class Notify cream;
class REST,GraphQL,MySQL primary-teal;
style VT fill:none,stroke:none
```
One project carries a data product from source engine to governed API. The audit gate is the control point: bad rows stop there and never reach semantics or downstream consumers.
## What you get
* One project for transformation, quality, and semantics.
* One governed contract across business intelligence (BI), applications, notebooks, and AI.
* One activation layer through REST, GraphQL, and SQL APIs.
## The data product lifecycle
You move a Vulcan data product through three repeatable steps:
1. **Author.** Write models, attach audits as assertions, add DQ checks, and define the semantic model and metrics in one project.
2. **Plan and apply.** Run `vulcan plan` to preview the change, classify its blast radius, and apply it safely. See [Plan](/references/dataos-resources/vulcan/core-concepts/plan.md).
3. **Run and serve.** Run `vulcan run` to keep the applied shape filled with fresh data, then serve it through the APIs. See [Observability](/references/dataos-resources/vulcan/observability.md) for how runs and the semantic query path behave.
## Where to go next
| Page | What it covers |
| ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| [Engine overview](/references/dataos-resources/vulcan/engine-overview.md) | What an engine is in Vulcan and how a gateway connects to it. |
| [Local Development Kit (LDK)](/references/dataos-resources/vulcan/ldk.md) | Installing the Vulcan command-line interface (CLI) and creating your first project. |
| [Configuration](/references/dataos-resources/vulcan/configuration.md) | `config.yaml`, gateways, model defaults, variables, hooks, the linter, and notifications. |
| [Core concepts](/references/dataos-resources/vulcan/core-concepts.md) | Models, plan and state, semantics, data quality, macros, signals, and tests. |
| [Deployment checklist](/references/dataos-resources/vulcan/deployment-checklist.md) | Promoting a data product into a DataOS environment. |
After setup, the project scaffold gives you ready-to-use folders for `audits/`, `dq/`, `tests/`, `models/semantics/`, and `models/metrics/`.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://v2.dataos.info/references/dataos-resources/vulcan.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.