Wrap-up

Look back at what you built and where to go from here.

~10 min0 of 2 steps done

You made it! Look back at what you built, and think about how it applies to your own data.

What you built

A source data product with contracts. You put the orders tables under an ODCS contract, made it testable, and added semantics, quality rules, ownership, and service levels.
Safe evolution. You shipped a breaking change as a new major version (orders_v2) and went through the migration lifecycle.
Data products. You described Orders and SKU Sales with ODPS, including input and output ports.
Contract-first development. You designed SKU Sales before writing SQL and used the failing tests as the specification, for yourself or an AI agent.
Consumer-driven contracts. You made explicit which fields you depend on.
Automation. GitHub Actions tests every change and stops breaking changes in pull requests.
If you did Part D: a platform where other teams discover your data products, and semantics that define your business language once.

Reflect

Apply it to your own data

Take five minutes and write down short answers. They make a good first draft of a proposal for your team.

Which dataset in your company would benefit first from a contract? Think of data that many teams use, that breaks often, or that feeds critical reports.
Who would own the contract? Who answers questions about the data, and who decides about changes?
Who are the consumers? Do the owners know them today?
Where would the contract tests run? In the producer's pipeline, in CI on every change, on a schedule?
What is the first quality rule you would write? What went wrong recently that a test would have caught?

How to get started in your organization

Start small. Put one important dataset under contract, as you did with Orders. One contract tested every day convinces more than a big rollout plan.
Go contract-first for new data products. Agree on the interface with your consumers before you build. It costs little and saves rework.
Put contracts in Git and test them in CI. An untested contract goes stale like any other documentation.
Make breaking changes visible. Run datacontract breaking in pull requests, and release breaking changes as new major versions with a migration period.
Let consumers speak up. Consumer-driven contracts show producers what really matters.

Go further

Open Data Contract Standard (ODCS) and Open Data Product Standard (ODPS): the full specifications
Data Contract CLI: all commands, importers, and exporters (GitHub)
Data Product CLI: lint and publish ODPS data products
Data Contract Editor: the visual editor in your browser, no installation needed
Entropy Data docs: the data product platform from Part D

Share your feedback

Something didn't work? A step was unclear? An idea for an exercise? Open an issue on GitHub. Every bit of feedback improves the tutorial.

Thanks for working through the tutorial, and good luck with your first data contract in production!

What you built

A source data product with contracts. You put the orders tables under an ODCS contract, made it testable, and added semantics, quality rules, ownership, and service levels.

Safe evolution. You shipped a breaking change as a new major version (orders_v2) and went through the migration lifecycle.

Data products. You described Orders and SKU Sales with ODPS, including input and output ports.

Contract-first development. You designed SKU Sales before writing SQL and used the failing tests as the specification, for yourself or an AI agent.

Consumer-driven contracts. You made explicit which fields you depend on.

Automation. GitHub Actions tests every change and stops breaking changes in pull requests.

If you did Part D: a platform where other teams discover your data products, and semantics that define your business language once.

Reflect

Apply it to your own data

Take five minutes and write down short answers. They make a good first draft of a proposal for your team.

Which dataset in your company would benefit first from a contract? Think of data that many teams use, that breaks often, or that feeds critical reports.
Who would own the contract? Who answers questions about the data, and who decides about changes?
Who are the consumers? Do the owners know them today?
Where would the contract tests run? In the producer's pipeline, in CI on every change, on a schedule?
What is the first quality rule you would write? What went wrong recently that a test would have caught?

How to get started in your organization

Start small. Put one important dataset under contract, as you did with Orders. One contract tested every day convinces more than a big rollout plan.

Go contract-first for new data products. Agree on the interface with your consumers before you build. It costs little and saves rework.

Put contracts in Git and test them in CI. An untested contract goes stale like any other documentation.

Make breaking changes visible. Run datacontract breaking in pull requests, and release breaking changes as new major versions with a migration period.

Let consumers speak up. Consumer-driven contracts show producers what really matters.

Go further

Open Data Contract Standard (ODCS) and Open Data Product Standard (ODPS): the full specifications

Data Contract CLI: all commands, importers, and exporters (GitHub)

Data Product CLI: lint and publish ODPS data products

Data Contract Editor: the visual editor in your browser, no installation needed

Entropy Data docs: the data product platform from Part D

Share your feedback

Something didn't work? A step was unclear? An idea for an exercise? Open an issue on GitHub. Every bit of feedback improves the tutorial.

Thanks for working through the tutorial, and good luck with your first data contract in production!