Your first data product

You will create a data product, carry it through the nine steps of Source, Refine and Deliver, and watch each of the three gates close. By the end it is a table in production, with a named person behind every decision that put it there.

Before you start

A terminal at the repository root, with the factory's environment set up — see Run it locally. You do not need an ANTHROPIC_API_KEY for most of this walk; where a step can use one, the text says so, and says what to do without it.

1. Start the factory

python -m dpf showcase
python -m dpf serve

showcase loads a warehouse of sample source systems and tables, and several data products already sitting at different points in the process, so there is something to look at right away. serve starts the web interface.

Open http://127.0.0.1:8200. You should see the product list, with those products at different points in the process, and one of them marked live.

2. Define the data product and choose the source tables

Select + in the sidebar, or New data product on the product list, to open /new. Fill in:

• Name: Customer contact snapshot
• Use case it serves: Service desk — look up who a customer is
• Description: Who each customer is and how to reach them, for the service desk to look somebody up in seconds. Refreshed daily. Not for marketing use — consent is tracked separately.
• What it must do:

  One row per customer, with their name, email and phone number
  Refreshed every day from the CRM

• Whose data it reads: search for customer_master and tick it — one table is enough to carry this walk.

Select Create. The description needs 12 words or more, and What it must do needs 2 lines or more — the form refuses to save and says which is short.

What you should see: the product's page, with "Customer contact snapshot created — 2 stated requirements across 1 source system." and a primary button, Data contract v0.1 →. The phase strip at the top shows Source, with its first two steps already done — defining the product and choosing its tables are both decided at creation.

3. Data contract v0.1

Select Data contract v0.1 →. This step writes the first version of the product's data contract: which tables, from which systems, and why — one section per source system in scope, here one, for the system you chose. It finishes once every section is signed by its system's owner and the matching access request is approved. That closes the approval to load gate.

Drafting a system's first section needs an ANTHROPIC_API_KEY: there is no way to write one by hand until a draft of it exists. If you do not have a key, open a product from the list whose next step reads Draft the requirements → instead of Data contract v0.1 → — its v0.1 is already signed — and pick up at step 4 below, on that product. Everything from here to Go live works the same way on either product.

With a key, on your own product:

1. Open the role badge at the foot of the sidebar and, under Act as, choose Revenue ops. The use case team is who asks.
2. Select Draft v0.1, then Send to <owner> — this only records that you asked; nothing is emailed.
3. Select Access requests →, then Raise in ServiceNow.

Now answer it. None of the showcase's source systems has an owner registered as a user, and in any case the person who asked can never be the person who answers — a rule this process checks by name, not only by role, so it still applies if you stayed signed in as the same person. Switch Act as again, to Philipp, the Administrator. Back on the contract's section, select Granted; on Access requests, select Approve.

What you should see: the step collapses to one line naming what it produced, who decided it and when. The phase strip shows Source complete and approval to load closed.

4. Draft the requirements

With a key, select Run the agent, then Accept the ticked ones on what it proposes. Without one, open Add a requirement and write one by hand: a title, a statement, and one line under Acceptance criteria.

What you should see: the step lists at least one requirement, with its key (REQ-1) and priority, and no longer blocks the next step.

5. Design the data model

Select Design the tables → — there is no separate agent-free page, because the editor is the manual path. A minimal table is enough:

1. Under Add a table, type customer_contact_snapshot, then select Add.
2. Type customer_id in the new attribute box and select Add attribute; do the same for email.
3. On customer_id, set Key to primary key, tick not null, and under From type customer_id.
4. On email, under From type email.
5. Under One row per…, type customer.
6. Select Save the design.

Then open Column descriptions →. For each column, write one line, select Save, then select Sign off.

What you should see: a badge reading complete · nothing to settle; once every description is signed off, the step collapses as done.

6. Data contract

Select Write it myself for a blank draft, or Run the agent for one grounded in the model. Fill in at least The decision it serves and Explicitly not for — the draft cannot be saved without both — then select Save my version. Finally, select Accept — this is what consumers are promised.

What you should see: a badge reading version 0.2.0 agreed — before it goes live, every agreed version of a contract is a 0.x. Refine is complete, and the agreement gate is closed.

7. Build and validate

Select Build 0.2.0 and run its checks. This compiles the model to SQL, runs it, and checks every acceptance criterion — nothing here is a judgement call.

What you should see: a message that every check passed, and a new release, numbered #1.

8. System integration test

Enter a Consumer and an Email, then select Ask to sign off. On the new row, select Send for signing, then Signed. (In this open, un-signed-in demo the same person may ask and sign; on a deployment with accounts, two different people would — see Governance.)

What you should see: the row reads signed, and the sign-off gate closes.

9. Go live

Say what you checked, then select Approve #1; the release row says it goes live as 1.0.0. Once approved, select Promote #1 to production.

What you should see: a message confirming it is live, with its row count. Deliver is complete, all three gates read closed, the data contract is published as 1.0.0, and the product you created has a table in production with a document trail behind every step that put it there.

What you did

• Every decision above belongs to one job in the factory — see the guide for the use case team, the source owner, the data engineer and the administrator.
• Why the gates are closed by different people, and what that does and does not catch, is in Governance.
• The nine steps, their phases and who is accountable for each are generated in full in Workflow.