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 .
67 guides · updated with every release
Strategy & operating model
- Design a data governance operating model that scales 🔒
Hub-and-spoke governance where a central team sets the rails and domains own their data, enforced as platform rules rather than review meetings.
- Make governance a property of the platform, not a committee 🔒
Governance that executes at pull-request time beats policy documents nobody reads. The platform refuses violations before a reviewer ever has to catch them.
- Choose a platform strategy that survives re-orgs 🔒
Platform-agnostic contracts keep your governance and metadata portable across runtimes, so a cloud migration or a re-org does not force you to rebuild your data platform from scratch.
Architecture & design
- Design a contract-first data warehouse 🔒
Describe every dataset once, as a data contract, and generate pipelines, tests and documentation from that single description instead of scanning what already got built.
- Choose your silver modelling technique 🔒
A decision framework for flat, Data Vault 2.0, or Kimball-conformed silver — why the choice is project-wide, what each option costs, and why you should decide before the first silver table exists.
- Model bronze on the source, silver and gold on the business 🔒
Bronze mirrors the source system verbatim; silver and gold model the consumer's information needs. Keeping that boundary sharp is what stops legacy source structures from calcifying into your warehouse.
- Design a naming standard your platform enforces 🔒
Naming conventions in a wiki die; conventions compiled into the platform live. How to design catalog, schema and table names as configuration, keep environments name-identical, and freeze the standard once data exists.
- Plan a multi-domain warehouse with hub-and-spoke governance 🔒
Give domains real autonomy inside central platform standards: when to split a domain, how to make cross-domain consumption an explicit reviewed dependency, and how to federate contracts without buying a central catalog.
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
- Enforce ownership and classification from day one 🔒
Make a named owner and a data classification a structural requirement on every dataset, so governance cannot decay into 'owner: unknown'.
- 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.
- Handle personal data correctly in a contract-first warehouse 🔒
Identify personally identifiable information at the source boundary, author it fail-closed with an audited human override, and keep evidence you can hand to an auditor.
- 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.
- Set up approval workflows that scale with your team 🔒
Distinguish routine from sensitive changes, size the approver count to the risk, and keep the whole approval flow inside the pull requests engineers already work in.
- Govern AI access to your data 🔒
Replace blanket AI bans and blanket AI trust with a per-dataset policy, an explicit autonomy ladder, and an audit log of every model call with cost and caller.
- Set an AI governance posture the board can defend 🔒
Move artificial intelligence (AI) governance from a slide deck to an enforced gate: a per-dataset AI policy, an autonomy ladder with a hard ceiling, and an audit record behind every model call.
- Run governance where the work happens: in pull requests 🔒
Turn classification raises, cross-domain consumption, and access rules into pull-request status checks with a sticky comment as the audit trail, replacing after-the-fact review meetings.
- Run one governance model across every platform 🔒
Owners, classification, lineage, AI usage, and audit should follow a single contract model regardless of runtime, so the whole estate stays auditable instead of fracturing into per-platform silos.
Security & AI policy
- Put a gate on every AI call to your data 🔒
AI access is an attack surface. Route every model call through one audited gateway that classification-gates it and refuses by default, because you cannot secure what bypasses the gate.
- Classify data so protection is automatic 🔒
Make classification the control plane. When every column carries a sensitivity label, masking, AI refusal, and access follow automatically, and personal data can never silently become public.
- Control access with single sign-on and capability-based roles 🔒
Pin identity to your identity provider, scope capabilities per environment, and enforce them at pull-request time so a risky change is stopped before it merges, not after.
- Keep secrets out of code and configuration, provably 🔒
No plaintext secret in code or YAML, ever. Reference secrets by vault token, resolve them at runtime, and fail the build on any plaintext that slips through.
- Gate natural-language questions before they run 🔒
A question asked in plain language over your data is a new exfiltration path. Resolve each table to its contract and each column to its classification, and decide allowed, gated, or forbidden before the query runs.
Compliance & audit
- Generate compliance evidence instead of promising it 🔒
Produce a structured evidence document from contract metadata and the audit log over a defined control set, machine-readable for governance tooling and human-readable for reviewers, with gaps flagged rather than hidden.
- Answer an audit without a six-week investigation 🔒
When the auditor asks how a dataset became restricted, who approved it, and where it flows, the answer should be a link rather than a task force, because traceability was designed in instead of reconstructed.
- Meet your GDPR obligations in a contract-first warehouse 🔒
Turn data minimization, lawful basis, subject rights, and retention limits into contract metadata a validator enforces, instead of a policy binder nobody reads.
- Redact for the right to be forgotten without destroying the audit trail 🔒
Resolve the apparent conflict between erasure and auditability with redaction-as-event, a two-person countersignature, and a clock that starts when you acknowledge the request.
- Prepare for the EU AI Act as a data platform 🔒
Know where AI touches your data, under what policy, with what audit trail, and produce structured evidence a reviewer can attest to.
- Build a continuous evidence base for audits 🔒
Generate compliance evidence from live metadata and the audit log over a defined control set, store it where your GRC tooling can import it, and keep a history instead of scrambling before each audit.
- Meet operational-resilience expectations across regulations 🔒
Treat detection, incident handling, and evidence as one resilience practice that satisfies DORA in finance and equivalent operational-risk expectations everywhere else, alongside EU AI Act and GDPR duties.
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.
- Onboard a new data source the right way 🔒
Treat source onboarding as a governance event, not a plumbing task: introspect, classify, and contract before the first load, and capture ownership at the door.
- 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.
- Manage schema evolution without breaking consumers 🔒
Evolve schemas additively, verify impact before every change, and continuously reconcile the declared contract against what the warehouse actually does.
- Keep history: choosing a historization strategy 🔒
A decision framework for slowly changing dimension type 2 (SCD2), Data Vault satellites, and snapshots, anchored in grain and business-key stability rather than tooling defaults.
- Set retention and deletion policies you can prove 🔒
Tie retention to classification, implement erasure as an auditable workflow rather than a script, and keep evidence an auditor can verify without trusting your word.
Data engineering
- Build your medallion end-to-end: first source to first star 🔒
Ship the smallest complete value chain, one source through bronze, silver, and gold to a report, before you scale out. Vertical slices beat layer-by-layer buildout.
- Ingestion patterns: files, APIs, databases and streams 🔒
Normalise every ingestion path into one universal shape: landing zone to bronze, with idempotent loads and provenance columns on every row.
- Build silver with Data Vault 2.0 🔒
Model silver as hubs, links, and satellites with a clean raw-vault/business-vault split, and know when Data Vault is the wrong tool.
- Build gold star schemas BI can trust 🔒
Model gold as an explicit Kimball star with declared grain, conformed dimensions, and surrogate keys, generated from contracts so every BI tool computes the same number.
- Test your data: quality gates and invariants 🔒
Build a test pyramid for data, declare quality as contract metadata so tests travel with the dataset, and fail closed on breach in production paths.
- Backfill and reprocess without fear 🔒
Treat idempotence as the entry requirement, run backfills as a first-class audited flow instead of one-off scripts, and verify after every reprocess.
DevOps for data
- Put your warehouse in git: everything-as-code 🔒
Keep the entire warehouse definition in one repository, use trunk-based development with short-lived branches, and treat environments as configuration rather than branches.
- Gate every pull request 🔒
Build a continuous integration pipeline for data that validates schemas, lints governance, runs project health checks, and counts required approvals, so nothing merges unreviewed.
- Manage secrets and connections across environments 🔒
Keep every credential out of code and YAML, resolve secrets from a vault at run time, and drive multiple environments from one codebase with named targets.
- Deploy the platform: from laptop to cloud 🔒
Develop against an embedded local database with a seconds-long apply loop, then deploy the same contracts to the cloud warehouse, growing from one pip-installed binary to scheduled and containerized only when needed.
DataOps
- Monitor warehouse health continuously 🔒
Turn platform health into a ranked, fix-hinted punch-list that gates pull requests and keeps a tracking issue in sync, instead of a dashboard nobody reads.
- 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.
- Catch schema drift before your consumers do 🔒
Reconcile the live warehouse against your contracts on a schedule, treat drift as an incident to triage, and fold accepted drift back into the contract deliberately.
- 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.
- Define and track SLAs on data products 🔒
Declare freshness and completeness as measurable promises inside the contract, check them on a schedule, and route every breach to an owned incident instead of an email thread.
- 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.
- Run a data incident like a security incident 🔒
Classify severity, communicate, contain, and run a blameless postmortem with lineage as evidence, because a data-quality breach and a data exposure share one playbook.
- Run data incidents like an SRE 🔒
Classify severity, route incidents to the owning team through your ITSM tool, and run blameless postmortems where lineage shows the blast radius and every incident traces to a dataset and a change.
- Route detection events to your service desk with regulator-grade trace links 🔒
Detection is worthless if it dies in a log. Route every event to the system your responders already use, carrying the trace links a regulator will ask for, so every alert is actionable.
- Use lineage for impact analysis, not documentation 🔒
Declare lineage in the contract at design time, run what-if impact analysis before every schema change, and hand auditors a deterministic map of where personal data flows.
Value & adoption
- Prove data platform value in weeks, not quarters 🔒
Ship one source through to one trusted number before you scale out. Time-to-first-value is the metric that protects your budget when the board asks what the platform has delivered.
- Trace every metric back to its sources 🔒
When the board asks where a revenue number comes from, answer in one query rather than a six-week investigation. Goal-to-data lineage turns traceability into a trust instrument.
- Attribute data platform cost to the work that caused it 🔒
FinOps for data. Trace every unit of spend back to the dataset that generated it, so cost becomes a governance signal that tells you what to retire rather than a mystery bill.
- Measure and grow your data and AI maturity 🔒
You cannot improve what you do not measure. Baseline your maturity, invest where the gap is widest, and make every headline metric cite the sources it comes from.
Release management
- Promote changes forward-only: dev, test, prod 🔒
Keep one main branch and treat environments as cursors on its history. Promotion moves a cursor forward, never sideways or back, and production promotion sits behind approvals engineers cannot bypass.
- Release with a manifest: know exactly what runs where 🔒
Maintain one release manifest as the single truth of which version of every data contract runs in which environment, and make that truth visible to reviewers on every pull request.
- Handle hotfixes without breaking your promotion model 🔒
A hotfix travels the same forward-only path as any change, just faster. Keep the diff small, expedite the review, promote immediately, tag what you ship, and track hotfix frequency as a health signal.