Gedankenexperiment
Sign in

Data Product Factory

Build data products end to end, in one pane of glass.

From a request for data to a governed table in production. Everybody works on one record, and each decision is ready for an audit.

Open the factory Read the docs

The factory's interface, playing Policy portfolio snapshot through Source, Refine and Deliver: each step ticks, each lands in the activity log, and each gate closes with a name and a time.

Source
Ends withThe tables are loaded
1 Define the data product Data Product Description · 54 words Revenue ops24 Aug 09:29
2 Choose the source tables Sources in scope · 3 tables in 1 system Revenue ops24 Aug 10:56
3 Data Demand Document Policy administration · named use case only Katrin Vogel9 Sep 09:29
GATE approval to loadApproved by Katrin Vogel, source owner · 9 Sep 09:29
Properties
OwnerRevenue ops
Gateclosed
Agreementnone accepted
Livenot promoted
Activity
Description saveddocument.saved
Scope setproduct.scope_set
Demand answereddemand.answered
Gate closedgate.decided

One pane of glass. Every layer, every reader.

Today, each layer lives in its own tool. In the factory, the layers are one record, and everybody reads the same one.

Data the warehouse and the catalogue Development repositories and pipelines Process tickets and email Governance spreadsheets and sign-off mail One record Source owner approves with the purpose Data engineer builds from the agreement Use case team sees who acts next Auditor finds each decision Agents, headless over MCP and the API today: exports only

What changes.

01

Bring the messy request.

Today it sits in email, tickets and spreadsheets. Here it becomes one brief with an owner.

02

Everybody decides on one record.

Owners, engineers and auditors work on the same record. Agents write the first drafts.

03

The agreement keeps it true.

The table ships to its agreement. In production, the factory checks it against the agreement.

Audit-ready by design. Each decision has a name, a time and a version.

  1. Revenue ops asked for Policy portfolio snapshotproduct.created
  2. Katrin Vogel approved the loadgate.decided · approval to load
  3. Revenue ops accepted agreement 2.0.0gate.decided · agreement
  4. Revenue ops signed off the integration testgate.decided · sign-off
  5. Dana Ruiz promoted release #2release.promoted
Named decisions

A person outside the team closes each gate.

No self-approval

The person who asks cannot sign.

A log that only adds

Each event in order, with its version.

Full traceability

Each column traces to the requirement behind it.

Configured, not coded. Your stack, one setting each.

The process is one file, and each connection is one setting. The factory checks both when it starts.

Open the factory

Phases, steps, gates and roles live in one file. To change the process, you change the file.

DPF_WORKFLOW=workflow.yaml
Start small

Start with the demo.

Four products on synthetic insurance data. Select Tutorial for a walkthrough with fifteen stops.

Open the factory
Go further

Bring a real use case.

One data product, on your Databricks and your Entra ID, from request to production.

Write to Philipp

Questions.

How is this different from a data catalogue?

A catalogue describes the tables that exist. The factory controls how a new table comes to exist: who asked, who approved, and what it promises.

Do the agents decide anything?

No. An agent writes a draft. A named person accepts it, or writes the text by hand.

What do the agents see?

You choose: the full context, the metadata only, or nothing. One setting controls it.

Can it run in our environment?

Yes. It is one small web application with its own database. It runs next to your Databricks workspace and signs people in with your Entra ID.

What happens when the process changes?

You change workflow.yaml. The factory checks the new file when it starts, and it refuses a process with a missing step or a wrong order.

Is it in production somewhere?

Not yet. It is a prototype, and the demo runs on DuckDB. The Databricks, Entra ID and Jira connectors follow each vendor's published API, and they have not yet run against a customer tenant.