How to Package Data Products Inside a Data Catalog

---

Packaging a data product in a data catalog means bundling assets with what a consumer needs to use them without asking anyone: a purpose, a few output ports, documentation, a contract, an owner and a status. In Atlan that takes 7 steps, ending with a test by people and an AI agent before access widens.

---

The Open Data Product Standard (ODPS) describes the package, and the Open Data Contract Standard (ODCS) the promise behind each port. In Bitol’s words, “data products encompass multiple contracts along with additional metadata” (Bitol, 2025). A data catalog makes those parts browsable, and an enterprise context layer makes them readable by agents.

Field	Detail
Difficulty	Intermediate
Prerequisites	Products module enabled by an admin, domain policies, cataloged source assets, a business owner
Optional	Data contracts (private preview in Atlan, enabled on request)
Tools needed	A data catalog with a data products module, a YAML editor, an MCP client that signs in with OAuth
Output	A published, certified data product with explicit output ports, a contract or documented promise per port, and a passed agent test
Standards referenced	ODPS v1.1.0, ODCS v3.2.0 (both released 2026-09-08)

---

Why does packaging a data product matter when AI agents are consumers?

An agent has no colleague to ask, so the package has to answer its questions in advance. For the definition itself, see what a data product is.

The idea predates agents. In 2020, Zhamak Dehghani, then Director of Emerging Technologies at Thoughtworks North America, wrote that “data mesh introduces the concept of data product as its architectural quantum” (martinfowler.com, 2020), the root of data mesh and AI. ODPS v1.1.0 now adds an optional context block of instructions and constraints for AI agents (Bitol).

Package element	Question a consumer asks without it	ODPS v1.1.0 field	Where it lives in Atlan
Purpose	What is this for?	description.purpose	Product description
Output ports	Which table do I query?	outputPorts	Output ports
Documentation	What does net_revenue mean here?	description.usage, context	README, linked glossary terms
Contract and SLA	Can I rely on it tomorrow?	outputPorts[].contractId	Contracts tab (private preview)
Owner	Who do I ask when it breaks?	team	Owners
Access	Am I allowed to see it?	not covered	Visibility, domain policies
Status	Is it ready?	status	Draft or Published, certificate

In Atlan, “from a single data table to a collection of data assets, anything can be a data product” (Atlan docs). A person can ask what a column means; an agent works only from what the package says. See how agents and humans discover data differently, why AI agents need an enterprise context layer and what makes data AI-ready.

---

What do you need before you package a data product?

Organization

• A data domain that matches a business function, such as “finance and sales” or “regions of operation” (Atlan docs). Domains act as bounded context spaces.
• A business owner, a technical owner and an agreed first use case.
• Two success measures, such as Atlan’s suggested “reduction in time to find data, and reduction in questions routed to engineering” (Atlan docs).

Platform

• The products module enabled by an admin, plus create, update and delete permissions through domain policies (Atlan docs).
• Source assets already cataloged with lineage.
• Optional: data contracts, supported only on Tables, Views and Materialized views (Atlan docs).

An AI readiness assessment helps you pick a first domain whose assets are already in decent shape.

---

Step 1: Scope the data product around one consumer use case

Scope the product around one consumer question. That boundary sets how many ports and contracts you will maintain.

How to do it

1. Write the question in one sentence, for example “How many orders shipped each day, by region?”
2. Pick the domain that owns the answer. A shared asset can still appear in several domains and products (Atlan docs).
3. Name the product so the question is obvious. Names cap at 80 characters (Atlan docs).
4. If you keep an ODPS descriptor, fill in id, name, version, domain and status. Only apiVersion, kind and id are required (Bitol).

Check before moving on: someone outside the team, given only the name and description, writes the same purpose as the owner.

Common mistakes: Atlan’s rollout guide lists “one product per report or dashboard” and “spending the whole session on definitional debate” as pitfalls (Atlan docs). Let several reports read one product. See how to build data products for the wider sequence.

---

Step 2: Bundle the assets and choose a few output ports

Output ports are the product’s public interface. Consumers query them; everything upstream stays internal. In Atlan, “output ports determine how data products connect to one another” (Atlan docs). You cannot set input ports by hand, because other products’ output ports become your inputs in business lineage (Atlan docs).

How to do it

1. Under Select assets, choose Add via filters. “Match all” joins criteria with AND, “Match any” with OR, and View assets previews the result (Atlan docs). Write the rule against the consumption-layer schema so stg_ and int_ tables stay out.
2. Mark each consumption-layer asset as an output port. More than one is fine, for example “a dashboard for visualization plus a materialized view for extraction on the same product” (Atlan docs).
3. Open the Lineage tab and confirm upstream products show up as inputs.

In the running example, fct_orders_daily and orders_kpi_view are ports; stg_orders_raw and int_orders_deduped stay internal.

Here is the same product as an ODPS v1.1.0 descriptor (media type application/odps+yaml;version=1.1.0, per the ODPS README). It validates against the v1.1.0 JSON Schema:

apiVersion: v1.1.0
kind: DataProduct
id: 3f9c2a10-6b4e-4d2a-9e71-0c5d8b7a1f42
name: Daily shipped orders
version: 1.0.0
status: draft
domain: sales
description:
  purpose: Daily shipped orders by region, for fulfillment and finance
  usage: Query fct_orders_daily for counts; use orders_kpi_view for dashboards
context:
  instructions: Count shipped orders from fct_orders_daily. Do not query staging or intermediate tables.
outputPorts:
  - name: fct_orders_daily
    description: One row per region per ship date
    type: table
    version: 1.0.0
    contractId: 9a7d0e21-4c3b-4f8e-a1d2-5e6f7a8b9c01
  - name: orders_kpi_view
    description: Dashboard view with metric logic applied
    type: view
    version: 1.0.0
    contractId: 2c8e4b6d-1f3a-4e5b-8d7c-9a0b1c2d3e45
team:
  name: Sales data products
  members:
    - username: jdoe
      role: business owner
    - username: asmith
      role: technical owner
support:
  - channel: "#orders-data"
    tool: slack
    url: https://example.slack.com/archives/orders-data

Keep the descriptor in Git as the tool-neutral record, and set the same facts on the product in Atlan. It omits inputPorts because Atlan derives inputs from lineage.

Check before moving on: every output port answers part of the Step 1 question, and no stg_ or int_ asset is a port.

Common mistakes: “marking every lineage asset as an output port” floods “the consumer view with upstream technical tables” (Atlan docs). See data lineage for AI and MCP for data lineage.

---

Step 3: Document the product to a good-enough bar

Atlan’s rollout guide sets “a minimum viable bar” of “description, owner, domain assignment, and certificate status,” and says to enrich to “good enough,” not perfect (Atlan docs).

How to do it

1. Write the description as the question the product answers.
2. Add a README with “links to the support/intake channel so consumers know how to request changes,” and add business terms from the underlying tables up to the product level (Atlan docs).
3. Record the metric definitions, or point to your semantic layer. See managing KPI definitions and a business glossary.
4. Put the rules an agent must follow (“count orders from fct_orders_daily only”) in the description and README. In ODPS v1.1.0 they go in context.instructions, “natural language guidance for AI agents and tools on how to use this entity” (Bitol).

Check before moving on: a new analyst can say what the product is for from the description alone, and every metric name resolves to one definition.

Common mistakes: “requiring 100% enrichment before rollout” stalls launches (Atlan docs), and column docs pasted into the description bury the purpose. The context layer glossary and business context for AI help you choose product-level terms.

---

Step 4: Attach a data contract and SLA to each output port

A data contract is the written promise behind one output port: schema, quality rules and freshness.

ODCS v3.1.0 deprecated the contract’s top-level dataProduct field (Bitol, 2025); v3.2.0 still accepts it, marked “DEPRECATED since v3.1.0” (Bitol). The product points to each contract through outputPorts[].contractId instead (Bitol). ODCS v3.2.0, released on 2026-09-08, is current (GitHub).

How to do it

1. Write one contract per output port. This one covers fct_orders_daily; orders_kpi_view gets its own. It declares every column the SLA references and validates against the ODCS v3.2.0 schema, following the SLA and data quality docs:

apiVersion: v3.2.0
kind: DataContract
id: 9a7d0e21-4c3b-4f8e-a1d2-5e6f7a8b9c01
version: 1.0.0
status: active
schema:
  - name: fct_orders_daily
    properties:
      - name: ship_date
        logicalType: date
        required: true
      - name: region
        logicalType: string
        required: true
      - name: order_count
        logicalType: integer
        required: true
        quality:
          - metric: nullValues
            mustBe: 0
slaProperties:
  - property: latency   # data no older than 1 day, measured on ship_date
    value: 1
    unit: d
    element: fct_orders_daily.ship_date

2. Check whether contracts are on for your tenant. They are in private preview, “enabled for a larger cohort of customers on request” (Atlan docs). Only Table, View and MaterialisedView assets support them. Iceberg tables and columns do not, and neither do non-SQL ports such as API specs, reports and streams (Atlan docs).
3. If they are on, create a contract from the asset’s Contracts tab, which drafts it “based on asset metadata,” or import one with the Atlan CLI “from your local machine to Atlan directly or through a CI/CD pipeline.” The CLI uses “Atlan’s YAML contract template” and the docs do not mention ODCS, so map your ODCS fields into that template (Atlan docs). Set the port’s contractId to the ODCS id.
4. If they are off, or the port is not a SQL asset, request the preview. Meanwhile, copy the columns, null rule and freshness target from the ODCS file into the README.

Check before moving on: every output port has a contract or a README promise.

Common mistakes: one contract for the whole product, or contracts on staging assets. See data contracts for AI and data quality for AI agents.

---

Step 5: Name a business owner and set domain policies

Ownership decides who answers when the product breaks. Domain policies decide who can change and read it.

Atlan’s owner test is “who is most impacted if this data disappeared,” not “who built the tables,” with “one named owner per product” (Atlan docs). Pair that business owner with a technical owner. In ODPS, both go under team.members with a free-text role.

How to do it

1. Assign the business owner and the technical owner on the product.
2. Set domain policies, which “control which users can (or can’t) take certain actions within a data domain or subdomain,” including creating, updating and deleting products (Atlan docs).
3. Give consumers read access: “grant read on the product’s domain through a domain policy,” and “verify query-access policies” before inviting users (Atlan docs).

Check before moving on: the owner field names a person, not a team alias, and a pilot consumer can open the product’s assets.

Common mistakes: “defaulting ownership to data engineering” leaves “consumers with no accountable business contact” (Atlan docs). See who owns the context layer, and agent access control and role-based access control for how the same permissions apply to agents.

---

Step 6: Publish to a pilot group and check the product score

A Draft product “is only visible to product owners”; a Published one is “for users to consume” (Atlan docs). Publish to a small group first so Step 7 can test real consumer identities.

How to do it

1. Set visibility to “Private to selected members” and add your pilot consumers.
2. Set sensitivity (Public, Internal, Confidential) and criticality (High, Medium, Low).
3. Apply the certificate in the Details section, then change status from Draft to Published. Later states are Sunset, “planned for retirement,” and Archived (Atlan docs). See the data product lifecycle.
4. Review the product score once it refreshes.

Atlan scores each product “on a scale of 0-5” across six principles (Discoverable, Understandable, Addressable, Secure, Interoperable, Trustworthy), “updated daily at 4:00 AM UTC” (Atlan docs). Expect a 0 at first: the score “shows 0 right after setup,” and “scores live at the asset level today” (Atlan docs). Use it to find the weakest principle; the AI-ready data checklist adds checks for model-facing products.

Check before moving on: status is Published, visibility is limited to the pilot group, and the certificate is applied.

---

Step 7: Test discovery with people and agents, then widen access

Test the package with a consumer who was not in the room, human or agent, before you open it up.

How to do it

1. Connect an MCP client as a pilot consumer. Atlan’s hosted MCP server is “available on every Atlan tenant with nothing to install” (Atlan docs) at https://mcp.atlan.com/mcp. Use OAuth, where “each person signs in with their own Atlan account,” not an API key, which “acts as one shared identity.” In Claude Code, run claude mcp add --transport http atlan-oauth https://mcp.atlan.com/mcp, then /mcp to sign in (Atlan docs).
2. Ask the Step 1 question in plain words: “How many orders shipped yesterday in EMEA?” The agent should call search_assets, which filters by “type, certification status, tags, domains, glossary terms, and dates” (Atlan docs).
3. Read what came back. get_assets “takes GUIDs from a prior search result” and “returns catalog metadata only” (Atlan docs). That metadata can include owners, certificateStatus, the description and README, and “data products the asset belongs to” (Atlan docs).
4. Score the run. Pass: the agent lands on fct_orders_daily, names its owner, certificate and product, and follows the usage rule. Fail: it picks stg_orders_raw, returns nothing, or cannot say what the table is for. Each failure points back to ports (Step 2), documentation (Step 3) or access (Step 5).
5. Repeat as someone outside the pilot group. MCP “only returns metadata the connected user is permitted to see in Atlan” (Atlan docs), so this user should not see the product.
6. Widen access. Change visibility to domain members or public, and configure a persona landing page so each group “lands on their product on login.” Atlan’s guide calls that “the single highest-impact lever for non-technical adoption” (Atlan docs). See the data products marketplace.

Know the limit. Of the 41 MCP tools listed as of 2026-11-01, none mentions contracts or output ports (Atlan docs). Put anything an agent must obey in the description or README, which get_assets returns. See the Atlan MCP server, an MCP-connected data catalog, how MCP delivers business context and giving AI agents access to enterprise data.

Check before moving on: the pilot agent passes item 4 and the outsider does not see the product.

---

What changes after a data product is published?

“Products stay editable after publishing” (Atlan docs), so plan for change.

• A breaking port change gets a new port version. In ODPS, “the combination of the name and version is the key,” and the old port can be flagged deprecated: true (Bitol). Announce it in the support channel.
• A contract change gets a new contract version. Atlan lets you “generate new versions” and “Compare with published version” (Atlan docs).
• An SLA breach needs an alert owner, set in your data observability for AI pipelines and context observability setup.
• Retirement runs from Sunset to Archived, which is “no longer visible to users” (Atlan docs).

Atlan’s guide also warns against “creating a duplicate ‘leadership-suffixed’ product instead of using a persona” (Atlan docs). An agentic data catalog can draft descriptions and terms as the product changes, with the owner signing off.

---

How does Atlan package data products as context for AI?

Without a shared home, descriptions sit in wikis, contracts in repos and access rules in tickets. In Atlan, domains carry policies, products expose output ports linked through business lineage, and contracts (in private preview) attach to Tables, Views and Materialized views. Over MCP, an agent reads a product’s descriptions, owners and certificates within the signed-in user’s permissions. Each product becomes a governed unit in the context graph. Implementing an enterprise context layer for AI covers the wider rollout. Start with one product, and run the Step 7 test before you build the second.

---

Real stories from real customers: Shared language for AI agents

Workday uses the same MCP route for its shared business language:

Workday’s session on its data product standards shows product standards and a shared glossary working together, the pairing Steps 3 and 4 rely on:

---

Is your data product ready to open up to every consumer?

Open the product up when every row passes.

Check	Pass condition
Scope	One consumer question, one owning domain
Output ports	Consumption-layer assets only
Minimum bar	Description, owner, domain, certificate set
Contract	One per SQL output port, or a README promise where contracts are unavailable
Owner	A named person who passes the “most impacted if this data disappeared” test
Access	Visibility and read policy set for the intended consumers
Classification	Sensitivity and criticality set
Score	Weakest principle reviewed after the first refresh
Agent test	Step 7 passes under a pilot consumer’s OAuth sign-in, and an outsider does not see the product

---

FAQs about packaging data products in a data catalog

1. What should a data product include in a data catalog?

A purpose, a few output ports, documentation, a contract or written promise per port, a named owner, access settings and a status. Atlan’s minimum bar to publish is description, owner, domain and certificate status.

2. What is an output port in a data product?

An asset the product exposes for consumers to query, such as a fact table or reporting view. Staging assets stay internal. In Atlan, one product’s output ports become another product’s input ports in business lineage.

3. What is the difference between a data product and a data contract?

The product is the whole package: purpose, ports, team, support and status. A contract is the promise behind one port: schema, quality rules and SLAs. The product points to each contract through contractId on the output port, and ODCS v3.1.0 deprecated the contract’s own dataProduct field.

4. Who should own a data product?

The person most affected if the data disappeared, usually on the business side, paired with a technical owner who maintains the pipelines. Atlan’s rollout guide lists defaulting ownership to data engineering as a pitfall.

5. Can a single table be a data product?

Yes. Atlan’s documentation says anything from a single table to a collection of assets can be a data product. It still needs a description, owner, domain, certificate and a contract or written promise.

6. How do AI agents discover and use data products?

In Atlan, an agent connects to the MCP server, searches assets by domain, certification status and glossary terms, and reads each asset’s description, owners, certificate and data products. It sees only what the signed-in user may see. No MCP tool is described as returning contract terms.

7. What is the Open Data Product Standard (ODPS)?

An open YAML standard from Bitol for describing a data product. Version 1.1.0, released on 2026-09-08, covers fundamentals, input and output ports, support, team and an optional context block for AI agents.

---

Sources

1. What are data products, Atlan docs
2. Create data products, Atlan docs
3. Design and roll out data products, Atlan docs
4. What is a product score, Atlan docs
5. Create data domains, Atlan docs
6. Create domain policies, Atlan docs
7. What is business lineage, Atlan docs
8. Create data contracts, Atlan docs
9. Product release stages, Atlan docs
10. Atlan MCP overview, Atlan docs
11. Set up MCP, Atlan docs
12. MCP tools reference, Atlan docs
13. MCP asset attributes, Atlan docs
14. Open Data Product Standard README, Bitol
15. ODPS fundamentals, Bitol
16. ODPS Context section, Bitol
17. ODPS v1.1.0 JSON Schema, Bitol
18. ODCS v3.2.0 release, Bitol on GitHub
19. ODCS v3.2.0 JSON Schema, Bitol
20. ODCS service-level agreement, Bitol
21. ODCS data quality, Bitol
22. Bitol announces ODCS v3.1.0, Bitol
23. Data Mesh Principles and Logical Architecture, Zhamak Dehghani, martinfowler.com