Data Governance, Catalogues and Lineage
Learn to govern the data that matters most, from choosing priorities to settling who owns a definition. No coding: you work on the data of Raket Parts, a fictional maker of rocket parts.
You will be able to
- choose governance priorities from real decisions and incidents
- tell access from approval
- record who owns data and what is unresolved
- write a definition anyone can reproduce
Govern what matters first
Select governance priorities from recorded decision risks and unresolved incidents.
Who owns this data?
Distinguish access from approval and document unresolved data ownership.
How many customers do we have?
Document reproducible customer definitions and identify reports that do not follow them.
Where does this figure come from?
Trace a reported figure back hop by hop, mark each hop verified, unverified or contradicted with its evidence, and find where two figures part.
What would this change break?
Trace a field forward to every asset that uses it, including ones no report lists, and state each owner, effect and notice.
Ruling on a standard and its exceptions
Decide what a standard requires and when an exception is allowed.
Decision rights and dispute routes
Set who decides what, and where disputes go.
Resolving a dispute between functions
Settle a governance disagreement with evidence.
Integration: a governance pack for a second area
Apply the whole method to another part of the business.
Final assessment
A governance pack on an unseen case.
Data Governance / Module 1
Govern what matters first
Data governance begins with decisions and failures that matter. Follow actual incidents, name the important data, and make a small, defensible first scope.
Sections
Data Governance / Module 1 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Data Governance / Module 2
Who owns this data?
A data asset may have many users but needs clear decision authority. Learn to separate the accountable owner, everyday steward and system custodian, then record and route gaps.
This module builds on module 1. If you are new to this, start with module 1.
Sections
Data Governance / Module 2 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Data Governance / Module 3
How many customers do we have?
Different teams can report different customer totals without either being wrong. Define the exact population and period, record approval, and test whether each report uses the agreed meaning.
This module builds on module 2. If you are new to this, start with module 2.
Sections
Data Governance / Module 3 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Data Governance / Module 4
Where does this figure come from?
Teun and Bram have different October revenue totals. Follow every step of the figure, compare records with the proposed catalogue diagram, and record what remains unresolved.
This module builds on module 3. If you are new to this, start with module 3.
Sections
Data Governance / Module 4 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Data Governance / Module 5
What would this change break?
Bram proposes splitting the UNIVERSITY segment into universities and research groups. Jelmer traces the field beyond the reports on Bram’s list before anyone approves a change.
This module builds on module 4. If you are new to this, start with module 4.
Sections
Data Governance / Module 5 / Free practice
Try it on your own question
Run it in the practice editor
The practice editors have the Raket Parts tables loaded. Type a query or a formula, run it and change it as often as you like. Nothing is marked.
Data Governance / Module 1 / 1.1
1.1 Governance helps decisions
Section 1.1 complete
Next: 1.2 Follow the incidents
Data Governance / Module 1 / 1.2
1.2 Follow the incidents
Section 1.2 complete
Next: 1.3 Rank what could hurt
Data Governance / Module 1 / 1.3
1.3 Rank what could hurt
Section 1.3 complete
Next: 1.4 Leave low-risk work for later
Data Governance / Module 1 / 1.4
1.4 Leave low-risk work for later
Section 1.4 complete
Next: Module 1 check
Continue to the module check Recap this section Back to module 1
Data Governance / Module 1 / Check
Module 1 check
Module 1 complete
Next: Module 2, Who owns this data?
Continue to module 2 Try it on your own question Recap module 1 Back to module 1
Data Governance / Module 2 / 2.1
2.1 Owner, steward, custodian
Section 2.1 complete
Next: 2.2 Write access is not ownership
Data Governance / Module 2 / 2.2
2.2 Write access is not ownership
Section 2.2 complete
Next: 2.3 Check the recorded authority
Data Governance / Module 2 / 2.3
2.3 Check the recorded authority
Section 2.3 complete
Next: 2.4 Resolve competing claims
Data Governance / Module 2 / 2.4
2.4 Resolve competing claims
Section 2.4 complete
Next: Module 2 check
Continue to the module check Recap this section Back to module 2
Data Governance / Module 2 / Check
Module 2 check
Module 2 complete
Next: Module 3, How many customers do we have?
Continue to module 3 Try it on your own question Recap module 2 Back to module 2
Data Governance / Module 3 / 3.1
3.1 Three counts, three meanings
Section 3.1 complete
Next: 3.2 Write a complete definition
Data Governance / Module 3 / 3.2
3.2 Write a complete definition
Section 3.2 complete
Next: 3.3 Agree or keep separate
Data Governance / Module 3 / 3.3
3.3 Agree or keep separate
Section 3.3 complete
Next: 3.4 Check report conformity
Data Governance / Module 3 / 3.4
3.4 Check report conformity
Section 3.4 complete
Next: Module 3 check
Continue to the module check Recap this section Back to module 3
Data Governance / Module 3 / Check
Module 3 check
Module 3 complete
Next: Module 4, Where does this figure come from?
Continue to module 4 Try it on your own question Recap module 3 Back to module 3
Data Governance / Module 4 / 4.2
4.2 One hop at a time
Section 4.2 complete
Next: 4.3 Verified, unverified or contradicted
Data Governance / Module 4 / 4.3
4.3 Verified, unverified or contradicted
Section 4.3 complete
Next: 4.4 Where the two figures part
Data Governance / Module 4 / 4.4
4.4 Where the two figures part
Section 4.4 complete
Next: Module 4 check
Continue to the module check Recap this section Back to module 4
Data Governance / Module 4 / Check
Module 4 check
Module 4 complete
Next: Module 5, What would this change break?
Continue to module 5 Try it on your own question Recap module 4 Back to module 4
Data Governance / Module 5 / 5.1
5.1 More than the reports you know
Section 5.1 complete
Next: 5.2 Follow the field forward
Data Governance / Module 5 / 5.2
5.2 Follow the field forward
Section 5.2 complete
Next: 5.3 Where following the links stops
Data Governance / Module 5 / 5.4
5.4 Effects and notice
Section 5.4 complete
Next: Module 5 check
Continue to the module check Recap this section Back to module 5
Data Governance / Module 5 / Check
Module 5 check
Module 5 complete
Next: Module 6, coming later
Back to the Path Try it on your own question Recap module 5 Back to module 5
Data Governance / Module 1 / Recap
Recap card
1.1 Governance helps decisions
Governance helps decisions
- Define the figure before adopting its label.
- Keep the owner, origin and rule together.
Common mistake
The trap. A system list is not an approved set of business definitions.
Data Governance / Module 1 / Recap
Recap card
1.2 Follow the incidents
Follow the incidents
- Start with failures affecting decisions.
- Keep disputed and inconclusive states explicit.
Common mistake
The trap. A full framework feels comprehensive but may miss the urgent data risks.
Data Governance / Module 1 / Recap
Recap card
1.3 Rank what could hurt
Rank what could hurt
- Rank by the harm if a decision is wrong.
- Use recorded incidents and invoice exceptions as evidence.
Common mistake
The trap. A busy data field is not automatically the most important.
Data Governance / Module 1 / Recap
Recap card
1.4 Leave low-risk work for later
Leave low-risk work for later
- Keep the initial register small and evidenced.
- Mark unresolved questions openly.
Common mistake
The trap. Deferring low-evidence work does not mean calling known risks resolved.
Data Governance / Module 1 / Recap
Recap card
Module 1: Govern what matters first
Governance helps decisions
- Define the figure before adopting its label.
- Keep the owner, origin and rule together.
Common mistake
The trap. A system list is not an approved set of business definitions.
Follow the incidents
- Start with failures affecting decisions.
- Keep disputed and inconclusive states explicit.
Common mistake
The trap. A full framework feels comprehensive but may miss the urgent data risks.
Rank what could hurt
- Rank by the harm if a decision is wrong.
- Use recorded incidents and invoice exceptions as evidence.
Common mistake
The trap. A busy data field is not automatically the most important.
Leave low-risk work for later
- Keep the initial register small and evidenced.
- Mark unresolved questions openly.
Common mistake
The trap. Deferring low-evidence work does not mean calling known risks resolved.
Data Governance / Module 2 / Recap
Recap card
2.1 Owner, steward, custodian
Owner, steward, custodian
- Distinguish the owner, steward and custodian.
- An existing record is not evidence of approval.
Common mistake
The trap. Assigning everything to IT hides the business decision maker.
Data Governance / Module 2 / Recap
Recap card
2.2 Write access is not ownership
Write access is not ownership
- Count access carefully, including its status.
- Keep permissions apart from accountable business decisions.
Common mistake
The trap. A write permission is not an ownership decision.
Data Governance / Module 2 / Recap
Recap card
2.3 Check the recorded authority
Check the recorded authority
- Use the exact decision kind and its applicable dates.
- Treat missing evidence as an open question, not proof of approval.
Common mistake
The trap. Approval of a payment is not approval of payment terms.
Data Governance / Module 2 / Recap
Recap card
2.4 Resolve competing claims
Resolve competing claims
- Keep consultation separate from accountability.
- Give unresolved ownership a trackable decision route.
Common mistake
The trap. Listing both claimants as final owners hides the unsettled decision.
Data Governance / Module 2 / Recap
Recap card
Module 2: Who owns this data?
Owner, steward, custodian
- Distinguish the owner, steward and custodian.
- An existing record is not evidence of approval.
Common mistake
The trap. Assigning everything to IT hides the business decision maker.
Write access is not ownership
- Count access carefully, including its status.
- Keep permissions apart from accountable business decisions.
Common mistake
The trap. A write permission is not an ownership decision.
Check the recorded authority
- Use the exact decision kind and its applicable dates.
- Treat missing evidence as an open question, not proof of approval.
Common mistake
The trap. Approval of a payment is not approval of payment terms.
Resolve competing claims
- Keep consultation separate from accountability.
- Give unresolved ownership a trackable decision route.
Common mistake
The trap. Listing both claimants as final owners hides the unsettled decision.
Data Governance / Module 3 / Recap
Recap card
3.1 Three counts, three meanings
Three counts, three meanings
- Define the counted population first.
- A time window is part of the meaning.
Common mistake
The trap. Competing report numbers are not necessarily contradictory.
Data Governance / Module 3 / Recap
Recap card
3.2 Write a complete definition
Write a complete definition
- Say which rows, entity and date are counted.
- Keep proposed definitions separate from approved ones.
Common mistake
The trap. “Active customer” without a defined period cannot be reliably reused.
Data Governance / Module 3 / Recap
Recap card
3.3 Agree or keep separate
Agree or keep separate
- Use separate names for different populations.
- Use one definition when the population and decision match.
Common mistake
The trap. Identical report numbers are not evidence of consistent meaning.
Data Governance / Module 3 / Recap
Recap card
3.4 Check report conformity
Check report conformity
- Audit the report against the actual definition.
- Identify the exact population or date clause that differs.
Common mistake
The trap. The same data source can still produce a non-conforming measure.
Data Governance / Module 3 / Recap
Recap card
Module 3: How many customers do we have?
Three counts, three meanings
- Define the counted population first.
- A time window is part of the meaning.
Common mistake
The trap. Competing report numbers are not necessarily contradictory.
Write a complete definition
- Say which rows, entity and date are counted.
- Keep proposed definitions separate from approved ones.
Common mistake
The trap. “Active customer” without a defined period cannot be reliably reused.
Agree or keep separate
- Use separate names for different populations.
- Use one definition when the population and decision match.
Common mistake
The trap. Identical report numbers are not evidence of consistent meaning.
Check report conformity
- Audit the report against the actual definition.
- Identify the exact population or date clause that differs.
Common mistake
The trap. The same data source can still produce a non-conforming measure.
Data Governance / Module 4 / Recap
Recap card
4.1 The diagram is not the proof
The diagram is not the proof
- A catalogue diagram claims a route; records test it.
- October 2025: extract €7,579,469.48, ledger €7,634,486.83.
Common mistake
The mistake. Do not approve a diagram because it is neat.
Data Governance / Module 4 / Recap
Recap card
4.2 One hop at a time
One hop at a time
- A hop record holds input, change, what is left out, what one row stands for and evidence.
- September: 1,145 invoices become 82 daily ledger lines with the same total.
Common mistake
The mistake. A matching grand total does not mean rows match one to one.
Data Governance / Module 4 / Recap
Recap card
4.3 Verified, unverified or contradicted
Verified, unverified or contradicted
- Mark each hop verified, unverified or contradicted, with its evidence.
- A batch log shows arrival, not which orders.
- A manual hop uses substitute evidence and a stated confidence.
Common mistake
The mistake. Do not call an undocumented transfer verified.
Data Governance / Module 4 / Recap
Recap card
4.4 Where the two figures part
Where the two figures part
- List the gap gross: €62,279.15 ledger-only revenue, €7,261.80 credit notes.
- A day and amount match locates the gap; the cause stays open.
Common mistake
The mistake. A matching amount does not prove why an invoice is missing.
Data Governance / Module 4 / Recap
Recap card
Module 4: Where does this figure come from?
The diagram is not the proof
- A catalogue diagram claims a route; records test it.
- October 2025: extract €7,579,469.48, ledger €7,634,486.83.
Common mistake
The mistake. Do not approve a diagram because it is neat.
One hop at a time
- A hop record holds input, change, what is left out, what one row stands for and evidence.
- September: 1,145 invoices become 82 daily ledger lines with the same total.
Common mistake
The mistake. A matching grand total does not mean rows match one to one.
Verified, unverified or contradicted
- Mark each hop verified, unverified or contradicted, with its evidence.
- A batch log shows arrival, not which orders.
- A manual hop uses substitute evidence and a stated confidence.
Common mistake
The mistake. Do not call an undocumented transfer verified.
Where the two figures part
- List the gap gross: €62,279.15 ledger-only revenue, €7,261.80 credit notes.
- A day and amount match locates the gap; the cause stays open.
Common mistake
The mistake. A matching amount does not prove why an invoice is missing.
Data Governance / Module 5 / Recap
Recap card
5.1 More than the reports you know
More than the reports you know
- Start from the field: segment reaches 313 customers, 5,733 extract rows and 842 contacts.
- A request's consumer list is where the search starts, not ends.
Common mistake
The mistake. A request’s consumer list is not a complete inventory.
Data Governance / Module 5 / Recap
Recap card
5.2 Follow the field forward
Follow the field forward
- Follow customer_ref to copies and labels.
- Each entry: asset, owner, effect, notice.
Common mistake
The mistake. A source key cannot find every use of a field.
Data Governance / Module 5 / Recap
Recap card
5.3 Where following the links stops
Where following the links stops
- 77 contacts have no customer link, yet use the code.
- Audiences match by contact, not just by count; the rule stays inferred.
Common mistake
The mistake. Treating an equal count as proof of a written selection rule.
Data Governance / Module 5 / Recap
Recap card
5.4 Effects and notice
Effects and notice
- Effects: breaks, changes meaning or none.
- No recorded owner: a tracked issue.
Common mistake
The mistake. Do not assume unrecorded owners or proposed dates are approved.
Data Governance / Module 5 / Recap
Recap card
Module 5: What would this change break?
More than the reports you know
- Start from the field: segment reaches 313 customers, 5,733 extract rows and 842 contacts.
- A request's consumer list is where the search starts, not ends.
Common mistake
The mistake. A request’s consumer list is not a complete inventory.
Follow the field forward
- Follow customer_ref to copies and labels.
- Each entry: asset, owner, effect, notice.
Common mistake
The mistake. A source key cannot find every use of a field.
Where following the links stops
- 77 contacts have no customer link, yet use the code.
- Audiences match by contact, not just by count; the rule stays inferred.
Common mistake
The mistake. Treating an equal count as proof of a written selection rule.
Effects and notice
- Effects: breaks, changes meaning or none.
- No recorded owner: a tracked issue.
Common mistake
The mistake. Do not assume unrecorded owners or proposed dates are approved.