Ask a data team whether their data is governed and the answer is usually yes. There is a catalogue. Access is controlled through roles. Sensitive columns are masked. Someone ran a classification exercise last year and labelled the personal information.
Then ask a different question: if another team builds something important on this table tomorrow, what can they rely on? What does each column mean? When will today's data be ready? What happens if the definition changes? Who do they call when the numbers look wrong at 07:00 on a Monday?
The honest answer is often a name, a guess and a hope. The table is governed. It is not something anyone has promised to keep fit for use.
That gap used to be survivable. A few analysts knew which tables to trust and which to treat carefully, and they carried that knowledge in their heads. AI removes that safety net. An assistant that answers questions from your data does not know which table the analysts quietly avoid. It reads whatever retrieval or a query reaches first, and it answers with the same confidence either way.
This series is about closing that gap. The CloudNala view is simple: governance controls who can touch data; a data product tells everyone what they can rely on. Organisations preparing for AI need both, and most have invested far more in the first than the second.
Gariep Grain Co-operative is fictional, and its systems and figures are illustrative. It is a Free State grain co-operative with about 2,800 member farmers and 31 silo sites. Every load that arrives at a silo crosses a weighbridge, gets sampled and graded, and becomes the basis for two payments to the member: an advance on delivery and a final payment once the season's grain has been sold. In 2026 Gariep piloted a member assistant on WhatsApp that answered questions such as "how much have I delivered this season?" Within three weeks it had told two members with identical deliveries two different tonnages.
What a governed table actually promises
Gariep's deliveries data lived in a table called deliveries_daily, loaded every night from the weighbridge software at each silo and joined to grading results from the laboratory system. It was governed in every conventional sense. It sat in the warehouse, it was in the catalogue, access was role-based, and member identity numbers were masked for most users.
What governance did not provide was any statement about fitness for use. Nobody had written down whether "mass" meant the weighbridge reading or the figure after moisture deduction. Nobody had committed to a time by which the previous day's loads would be present. Nobody was told when the silo at Wesselsbron upgraded its weighbridge software and started exporting mass in kilograms instead of tonnes. The payments team caught that one, because their numbers were suddenly a thousand times too large. The member assistant would not have.
This is the pattern in most organisations. Governance work answers questions about control: who may see this, how is it classified, where is it stored, how long is it retained. Those questions matter, and POPIA makes several of them obligations. They are just not the questions a consumer asks before building on the data.
What a data product adds
The term "data product" comes from the data mesh literature, where it describes data treated with the same care as a software product: built for consumers, owned by a team, and maintained over time. You do not need to adopt data mesh as an organisational model to use the idea. The useful part is the list of things a product carries that a table does not.
A named owner. Not the person who built the pipeline, and not the platform team that runs the database. The owner is someone on the business side who can decide what the data means and what quality is acceptable, and who accepts the risk when it is wrong. At Gariep that became the Head of Grain Operations, because grain operations creates the deliveries and understands what a ticket represents.
A contract. A written, versioned statement of the schema, the meaning of each field, the units, the grain of the data (one row per what?), the known limitations and the change policy. Open standards exist for this. The Open Data Contract Standard, maintained by the Bitol project under the Linux Foundation, defines a YAML format for exactly these elements, and its v3.1 release added relationships and stricter validation. A contract does not need a standard to be useful, but using one makes it readable by tools as well as people.
Quality checks that run on every load. Tests for schema, volume, freshness, valid ranges and referential integrity, executed before the data is published rather than discovered by a consumer afterwards. Part 6 covers where these checks should sit.
A service level. When the data will be ready, how fresh it is, and what happens when the promise is missed. During harvest, Gariep's payments run starts at 07:00, so the deliveries product commits to being complete for the previous day by 06:00.
Metadata and lineage. Where the data comes from, what transformations it went through, and what depends on it. Lineage is what lets an owner tell consumers about a problem before they find it themselves.
A defined access interface. A view, an API or a file export that consumers use, so the underlying tables can change without breaking everyone. A consumer that queries internal staging tables directly has no protection when the producer reorganises them.
Known consumers. A list of who relies on the product, so that changes can be communicated and impact can be assessed.
None of these is technically difficult. Most organisations already have tools that could support all of them. What is missing is the decision to treat a dataset as something with obligations, and the accountability that goes with it.
Why AI makes the gap expensive
Before the member assistant, Gariep's deliveries data had four main consumers: the silo managers' intake reports, the payments team, the pool accountants and the BI dashboards. Each team had learnt, over years, which table and which column to use. The knowledge was informal but it worked, because each consumer was a person who could notice when something looked odd.
The assistant was a fifth consumer with none of that knowledge. It was built in the usual way: the team pointed retrieval at the available documentation and gave it read access to a set of warehouse views. When a member asked how much they had delivered, the assistant's answer depended on which view it queried. One view reported gross mass from the weighbridge. Another reported net mass after moisture deduction. The model did nothing wrong; the data offered it two honest answers to the same question and nothing to say which one a member should hear.
This is why the series sits under the broader CloudNala argument that AI depends on information architecture. An AI system is the least forgiving consumer your data will ever have. It is fast, it is literal and it does not ask. A table that people use safely through accumulated folklore will be used unsafely by an assistant, because the folklore is not in the data.
There is also a scale effect. A person who misreads a column produces one wrong report. An assistant that misreads a column produces wrong answers for every member who asks, until someone notices. The cost of an unclear definition goes up sharply when the consumer is automated.
A worked example: turning the deliveries table into a product
Gariep's data team was four people. They did not have the capacity to turn every table into a product, and they did not try. They started with the one dataset that the payments run, the member assistant and the board report all depended on.
The sequence was:
- Name the owner. The Head of Grain Operations agreed to own the deliveries product, with a data steward in her team who handled day-to-day questions and kept the issue log.
- Decide the meaning. The owner decided that "delivered" in member-facing answers meant graded net mass, and that any answer given before grading was complete would say so explicitly. This is the decision Part 2 examines in more detail.
- Write the contract. Fields, units, the grain (one row per weighbridge ticket), the relationship to the member registry and the grading results, and a change policy: breaking changes with four weeks' notice and a new version, never in harvest.
- Add checks before publish. Schema and volume checks at landing, a moisture range check, a check that every ticket references a registered member, and a freshness check against the 06:00 commitment.
- Publish an interface. Two views: one for internal operational use with full detail, and one for member-facing use that exposes only graded net mass with a status field.
- Register the consumers. Payments, pool accounting, BI and the assistant, with a contact for each.
The member assistant was then pointed only at the member-facing view. The two-tonnage problem disappeared, not because the model improved but because the data now offered one answer with a clear status.
The trade-off: products cost more than tables
Treating data as a product has a real cost, and it is mostly people's time rather than technology. An owner has to make decisions and answer questions. A steward has to maintain the contract. The producing team has to run checks, handle failures and communicate changes. A table nobody owns is cheaper to keep, right up until something important depends on it.
That is the practical test for where to start. Not every dataset should be a product. A staging table, an analyst's working set or a once-off extract does not need a contract and a service level. The candidates are datasets that meet two conditions: several teams depend on them, and a wrong answer would cost money, damage trust or create a compliance problem. At Gariep, perhaps eight datasets met that test. They did the first one properly before starting the second.
The other trade-off is speed of change. A producer who can alter a table at will moves faster than one who must version changes and notify consumers. That friction is deliberate. It moves the cost of change from the consumers, who used to discover it, to the producer, who causes it.
What this series covers
The remaining parts follow the same running example:
- Part 2 looks at ownership itself, and why AI projects expose its absence faster than any audit.
- Part 3 separates retrieval, fine-tuning and knowledge graphs, which solve different problems and are often confused.
- Part 4 goes deeper on knowledge-graph search for relationship-heavy questions, including its limits.
- Part 5 turns all of this into a portfolio of ten data engineering projects that prove real capability.
- Part 6 treats data quality and observability as operational disciplines with incidents, owners and service levels.
For the retrieval side of the same problem, the RAG That Survives Production series covers how retrieval behaves once real documents and real users arrive. This series stays on the data underneath.
The decision for this month
If you are preparing data for an AI use case, do not start with the model or the vector database. Pick the one dataset the use case cannot work without, and ask the six product questions about it: who owns it, what is the contract, what checks run before publish, what is the service level, what is the interface, and who else depends on it. Where the answer is "nobody" or "we would have to ask", you have found the work that will decide whether the AI system can be trusted.
Next: Part 2, AI projects expose weak data ownership. All parts are on the series page.
How CloudNala can help
We help organisations identify the handful of datasets that their AI and reporting plans actually depend on, and turn those into owned data products with written contracts, checks and service levels. The work is usually a short readiness review followed by hands-on support for the first one or two products, so your team has a working pattern to repeat rather than a framework document.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Data Readiness Review or write to us at consult@cloudnala.co.za