Finance data engineering
Ledgers, receivables, payables and the close. These Recipes share a tie-out habit: every balance is reconciled to a source of record, and every number can be reproduced as of a date in the past.
7 Recipes
Collections
A Collection is a way of finding Recipes, not a thing you run. It holds no Recipe of its own: the title, the acceptance conditions and the readiness you see inside one are the Recipe’s own, which is why the same Recipe can sit in several Collections without any of them disagreeing about what it is.
By domain
The domain whose data you are working on today. You are still the data engineer in every one of these.
People data engineering
Headcount, tenure, payroll and pay bands. The recurring difficulty here is effective-dated records and a population that has to reconcile on both a balance and a movement.
4 Recipes
Revenue operations data engineering
Pipeline, bookings, commission and attribution. These Recipes all depend on capturing state as it was, not as the CRM currently reports it.
4 Recipes
Supply-chain and operations data engineering
Inventory, delivery performance and procurement spend. Each one reconciles a physical fact against a system record, and the interesting engineering is in the breaks.
3 Recipes
Larger outcomes
Recognisable pieces of work that take more than one Recipe, assembled rather than merged.
Customer 360
Customer 360 is not one Recipe. It is too broad to have a single acceptance contract, so it is assembled: standardise, resolve identity, then add the measures the view is actually for. Adopt the ones you need and add your own source, privacy and survivorship requirements on top — the Recipes below stay exactly what they are in the rest of the Cookbook.
8 Recipes
Finance close and reconciliation
What a close actually needs from the data side: the tie-outs, the as-of-date discipline, and the two shared dimensions — rates and fiscal periods — that every one of them silently depends on.
8 Recipes
Data reliability
Recipes whose deliverable is confidence rather than a table: freshness that fails before downstream work runs, gating on readiness instead of on a clock, and proof that a change is safe.
4 Recipes
Legacy data-stack re-engineering
Everything you own that still works and nobody wants to touch: stored procedures, views, notebooks, scalar functions and managed connectors. Each one is rebuilt with parity proved rather than assumed.
9 Recipes
dbt performance and maintainability
The project you already have, running faster and reading better, without the output moving. Incremental behaviour, bounded backfills, and the safety proof that lets you land any of it.
5 Recipes
Procure-to-pay data engineering
From the purchase order to the payment: spend under contract, invoices that should not be paid twice, and the supplier identity and currency work both of those rest on.
5 Recipes
Logistics operations
One operating view of physical movement: what the fleet did, whether the lane ran on time, and whether the order arrived complete. Three grains, three separate contracts, read together.
3 Recipes
By industry
Vertical Recipes together with the horizontal ones that vertical reaches for most.
Retail
Store and SKU grain, and a calendar that is never the Gregorian one. Sell-through and stockout risk sit here beside the customer and product Recipes retail leans on.
24 Recipes
Consumer goods
Trade promotion, product hierarchies and the baseline problem: measuring a lift means agreeing what would have happened anyway.
5 Recipes
Banking
Delinquency, vintages and monitoring features at account-day grain, with the identity and consent Recipes a regulated customer view depends on.
13 Recipes
Insurance
Accident and development periods, and the reporting conventions that make a claims triangle reproducible rather than merely plausible.
5 Recipes
Healthcare
Claims, remittances and cohorts with explicit exclusions, alongside the identity and consent work a patient view cannot be built without.
10 Recipes
Life sciences
Trial enrolment and site performance, where the grain is a subject at a visit and the study protocol is the specification.
6 Recipes
Manufacturing
Equipment effectiveness, downtime reasons and the material master, plus the procurement and currency Recipes a plant estate needs around them.
21 Recipes
Utilities
Meter reads, billing periods and unbilled energy — a reconciliation between a physical quantity and an invoice that almost never ties on the first pass.
6 Recipes
Telecom
Call-detail batches at a volume where completeness has to be proved rather than assumed, with the horizontal retention and consent Recipes beside them.
13 Recipes
SaaS
Recurring revenue, retention and product usage. The recurring engineering problem is state over time: what a subscription was on a date, not what it is now.
14 Recipes
Hospitality
Occupancy, rate and revenue per available room at property-day grain, with the currency and calendar Recipes a multi-property estate needs.
4 Recipes
Public sector
Grant funds from award through drawdown, where the audit trail is the deliverable and every movement has to be attributable.
7 Recipes
Logistics
Fleet and lane performance built from trip events, where the rules about what counts as on time are the hard part rather than the arithmetic.
5 Recipes
By platform
Where the work can actually run. A Recipe declares its exact execution targets; these three are how you browse them.
Microsoft Fabric
Every Recipe that runs on a Fabric Lakehouse, a Fabric Warehouse, or both. Which of the two a Recipe needs is stated on the Recipe, because it decides whether the work can run where you are.
78 Recipes · Lakehouse and Warehouse inside
MotherDuck
Recipes that execute against MotherDuck, including the ones built locally on DuckDB first and run there afterwards.
73 Recipes
DuckDB
Recipes you can run on a local DuckDB file, at no cost and in no queue. The shortest way to see what the work feels like before it touches a shared platform.
73 Recipes