> 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/build/productize/overview.md). # Overview "Productize" is where raw data becomes a data product. It's the **P** of the build pattern, and it's the core of Build: everything in [Understand](/build/understand/overview.md) and [Move](/build/move/overview.md) exists to get you here with the right data. Here's the idea that defines this stage: you create the physical asset and its meaning as **one object**. The transform, the semantic model, the quality contract, and the access policy aren't separate layers you stitch together afterward. They form a single unit, so they can't drift apart. That's what makes a product safe for an AI agent to consume, not just a person: its meaning travels with it. You build a data product with the **Vulcan** resource. This section is task-oriented: it shows you what to create and in what order. For the full syntax of any component, follow the links into [References → Vulcan](https://v2.dataos.info/references/resources/vulcan); Build doesn't restate the reference. ## The worked example The pages here build `orders-analytics`: a governed e-commerce product on PostgreSQL that tracks revenue, customer segmentation, product performance, and fulfillment. `orders-analytics` is organized as a layered pipeline, where each layer reads from the one above it. This pattern is sometimes called a medallion structure: ``` Source tables (public.*_ext) | Extract + Load brought these into reach v bronze.* source-aligned, raw shape, assertions v silver.* facts and dimensions, business logic v gold.* analytics-ready: RFM segmentation, sales funnel v Semantic models --> Metrics ``` Vulcan resolves the run order automatically from the SQL dependencies. You declare what a model reads; you don't orchestrate it. ## What a Data Product is made of A Vulcan Data Product is a set of components you create, all living in one project folder. Each has its own page in this section.

Component	What it is	In orders-analytics
Inputs	The upstream tables your models read from	`input.yaml` (9 tables)
Seeds	Static CSV files loaded as tables	`order_status_lookup.csv` (1 seed)
Data model	SQL or Python files that define transforms; each produces a table or view	`bronze.`, `silver.`, `gold.*` (12 models)
Semantic model	Maps physical tables to business measures, dimensions, segments, and joins	`models/semantics/*.yaml` (6 semantic models)
Metrics	Takes a measure from a semantic model and a time column, and turns it into one queryable time series, so every dashboard, report, and AI agent uses the same definition of a number	`models/metrics/*.yaml` (5 metrics)
Unit test	Unit tests of model logic against mock data	`tests/test_*.yaml` (2 tests)
Assertions	Rules that run at materialization and block bad data	Inline assertions plus `audits/*.sql` (3 audits)
Data quality	Non-blocking rules that monitor a model's data over time, profiling columns and surfacing warnings without stopping the run	`dq/*.yml` (7 DQ packs)

Three of these are easy to confuse, so hold the distinction firmly: unit tests validate logic, assertions attach that rule to a model and block bad data, and DQ checks watch data over time and warn. * **Unit test** - checks a model's SQL logic against mock fixtures, before any real data or warehouse is involved. See [Unit test](/build/productize/unit-test.md). * **Assertion** - attaches a rule, either a built-in function or a named audit, to a model. If the rule fails, the run stops. See [Assertions](/build/productize/assertions.md). * **DQ check** - runs against real data on a schedule. It only warns, so it never blocks the run. See [Data quality](/build/productize/data-quality.md). These are different artifacts, even though they sound similar. See each page for the full picture. ## The order you build in The pages map to the work, in sequence: 1. [Init and configuration](/build/productize/init-and-configuration.md): scaffold the project and set `config.yaml`. 2. [Connect engine](/build/productize/connect-engine.md): wire the project to your warehouse. 3. [Assets](/build/productize/assets.md): declare inputs and seeds, then write data models, semantics, and metrics. 4. [Unit test](/build/productize/unit-test.md), [Assertions](/build/productize/assertions.md), [Data quality](/build/productize/data-quality.md): make the product enforce its own contract. 5. [Governance](/build/productize/governance.md): set the access policy. 6. [Plan & run](/build/productize/plan-and-run.md): validate locally before anything ships. 7. [Git & deploy](/build/productize/git-and-deploy.md): render the deploy manifest, apply it, and verify that the product is live. Follow them in order on your first product. Once the workflow is familiar, combine or skip steps as the work allows. To see every component of `orders-analytics` assembled end-to-end before you start, skim [Recipes → Full lifecycle example](https://github.com/moderndatacompany/dataos/tree/July/documentation/build/recipes/full-lifecycle-example.md). Otherwise, start with [Init and configuration](/build/productize/init-and-configuration.md). --- # 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/build/productize/overview.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.