> 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/consume/v1/activate/reusability.md). # Reusability When an existing product already contains data you would otherwise rebuild, you do not start from raw sources. A published product can become the upstream input for a new one: the upstream owns the curated, governed, trusted output, and the downstream inherits and extends it. This is a consumption decision with a build follow-through, so this page covers *when* to reuse; the *how* lives in Build. ## When reuse is the right call Before starting a new product from raw sources, ask: does a published product already contain data I would otherwise rebuild? Reuse fits when: * An existing product covers the shared foundation (customer profiles, product catalogs, transaction facts) that multiple teams need. * You need to extend, not replace: the published product is most of what you need, and your team owns only the remaining domain-specific logic. * The upstream data is owned and refreshed by another team, so their published product is the correct interface. * Two products in your organization contain identical logic over the same source, a signal to consolidate onto one owner. ## When to build your own instead | Situation | Better approach | | ------------------------------------------------------------- | -------------------------------------------------------- | | No published product covers your domain | Start from raw source data | | The upstream has failing quality or unreliable freshness | Build your own until it stabilizes, or contact the owner | | Your use case needs a different grain or structure | Building independently is simpler | | The upstream owner cannot meet the SLAs your consumers expect | Evaluate the dependency risk first | | The upstream is experimental or draft | Wait until it is published and stable | ## Before you depend on a product Confirm it is published and active, quality signals are passing, freshness meets your needs, the output has the columns and grain your models need, and you have asked the owner whether the output schema is stable. You will find the owner in the **Members** section of the product page; reach out before committing, especially for production use. When all of that checks out, you've reached the end of the consumer journey: everything from here is a build task, not a consumption one. Follow the step-by-step build guide: Build → Recipes → Reuse a Data Product. It shows how to declare the upstream output in `inputs.yaml`, build downstream models on it, and publish your own semantics and 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/consume/v1/activate/reusability.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.