Run your data warehouse end-to-end.
Best-practice guides organized by role. Each one teaches the practice first, then shows how Kirimana operationalizes it. Pick your role to see the track built for you.
The catalogue is open; reading a guide requires a (free) account. Sign in or request access .
12 guides in this track · updated with every release
Data products & domains
- Define a data product worth owning 🔒
Treat a dataset as a product with a named consumer, a published interface, and service levels an owner is accountable for, not as another table nobody agreed to.
- Make the contract your stakeholder agreement 🔒
Move the producer-consumer agreement out of a drifting wiki page and into a versioned contract the platform enforces, so the promise on paper always matches the promise in production.
- Draw domain boundaries that hold 🔒
Give each domain real autonomy under a central platform, and make every cross-domain dependency an explicit, consented interface instead of an accidental join nobody signed off on.
- Run the data product lifecycle from draft to deprecated 🔒
Move a data product through an explicit state machine, gate every promotion on review and capability, and retire products with notice instead of a silent delete that breaks consumers.
Data governance
- Run a catalog review non-technical stakeholders can join 🔒
Move every attribute through a review-state machine that business reviewers can drive without touching code, so the people who know what the data means are the ones who approve it.
- Set an approval policy that scales with your domain 🔒
Match the number of approvers to the sensitivity of the change, and mirror real data ownership into review routing, so routine work flows and sensitive work gets scrutiny without a universal bottleneck.
- Publish across domains without breaking trust 🔒
Treat cross-domain consumption as an explicit, consented interface, and catch new cross-domain dependencies at review time instead of after an outage.
Data management
- Onboard a consumer to your data product 🔒
Give consumers a contract to subscribe to, not a table to reverse-engineer, so their expectations are explicit and you always know who breaks when you change.
- Change a data product without breaking consumers 🔒
Evolve additively, give breaking changes a deprecation window, and communicate every change through the contract instead of an email nobody reads.
DataOps
- Set and defend service level agreements on a data product 🔒
Turn freshness and completeness into measurable promises in the contract, then treat a breach as an incident that routes itself, not an email you hope someone reads.
- Keep a data product healthy in production 🔒
Treat health as a ranked punch-list you act on, run it automatically on a schedule, and let drift open and close a tracked issue instead of rotting on a dashboard.
- Measure whether your data product is actually used 🔒
Use lineage to see who consumes what, retire the datasets nobody depends on, and invest in the ones that carry real weight, before maintenance cost quietly outgrows value.