From Data Pipelines to Business Knowledge: Bringing DDD, Ontologies, and AI Together

A reliable pipeline is not business knowledge. It is the ground that business knowledge stands on.

This essay opens a series. The posts that follow cover domain-driven design (DDD), ontologies, and why "customer" means different things in different teams. Here I show how those pieces join to the part most teams want next: AI that helps people decide.

What a pipeline gives you

A good pipeline gives you tables that are fresh, tested and complete. That is hard work, and it is the right place to start. Without it, nothing above it can be trusted.

But a table does not say what its columns mean. It does not say who agreed on that meaning, or which source wins when two sources disagree. A person can ask a colleague. A dashboard cannot. An AI workflow cannot either, and it will fill the gap with a guess.

What DDD adds: one meaning per context

DDD gives each part of the business its own language and its own boundary. In billing, a customer is the party that pays. In support, a customer is the person who writes in. Both are right inside their own boundary.

For a data team, this means you stop forcing one global definition. You name the contexts, write down what each term means inside each one, and mark where the contexts meet. Those meeting points are where most reporting arguments start.

What an ontology adds: meaning a machine can read

DDD gives you shared language for people. An ontology writes that language down in a form software can use. It lists the things the business cares about, how they relate, and which rules always hold.

You do not need a large formal model. A short, checked list of terms and relations covers most of the value:

• the terms your key decisions depend on
• the source of record for each term
• the relations between terms (an invoice belongs to a customer; a customer has an owner)
• the rules that must never break

Keep it small. Add a term only when a real decision needs it.

Where AI fits

Once the data is reliable and the meaning is explicit, an AI workflow has something firm to work with. It can read a question, find the right tables through the shared terms, run the query, and show the evidence behind its answer. It can flag when two sources disagree instead of silently picking one.

Without the meaning layer, the same workflow looks impressive in a demo and fails on real questions. The model is not the weak part. The missing definitions are.

Evidence and approval

Two habits turn a clever answer into something a business can use.

First, every answer carries its evidence: the tables, the rows, the rule that applied. A reader can check it in a minute.

Second, any consequential action waits for a human approval. The workflow can draft the change, the payment match or the message. A person decides whether it goes out. I do not build AI workflows that act on their own for actions that matter.

This is why I treat the data platform and the AI workflow as one job. The rigour of the platform is what makes the workflow trustworthy.

A path you can follow

1. Fix the pipelines and tests so the tables can be trusted.
2. Name the contexts and write down the terms each decision depends on.
3. Record the source of record and the key relations for those terms.
4. Let an AI workflow use that record, and make it show its evidence.
5. Put a human approval in front of every consequential action.

You can check your own position on this path for free. The Data Platform Teardown covers the platform side. The AI Workflow Teardown covers the workflow side.

Who should not hire me

If you need a large team, a round-the-clock on-call rotation, or an AI agent that acts with no human approval, I am the wrong fit. I work alone, and I build workflows where a person approves what matters.

If your pipelines already run well and your terms are already agreed, you may only need the last two steps. Start with the teardown that matches your gap, and decide from there.