Module 8 of 16

Freshness, Contracts, and Documentation

Make data understandable, current, and safe to change.

95 minutes1 exercisesFree

Start here

Learning objectives

  • Explain source freshness and data SLAs
  • Document models and columns clearly
  • Understand model contracts and ownership
Freshness, Contracts, and Documentation Follow the arrows. Each box is one idea you will practice in this module. Freshness step 1 Contract step 2 Docs step 3 Owner step 4 SLA step 5 Production analytics engineering turns raw records into governed, trusted business meaning.

The Mental Model

A trusted model needs more than correct SQL. Users need to know what it means, who owns it, how fresh it is, and what changes are allowed.

Documentation is the instruction label on the data. Freshness is the expiration date. A contract is the promise that the shape will not change silently.

Tiny Example

We will use a small ecommerce dataset throughout the course. Think of these as the only tables in your first warehouse:

TableGrainExample columns
raw_ordersone row per order eventorder_id, customer_id, amount, status, created_at
raw_order_itemsone row per item inside an orderorder_id, product_id, quantity, item_price
raw_customersone row per customercustomer_id, email, country, created_at

Interactive Check

Question: A payments source stops updating at midnight but tests still pass. What kind of check is missing?

Reveal the answer

A freshness check is missing. The data can be structurally valid but stale.

Inline Practice Lab

This lab is intentionally small. You can solve it by reading the table, writing the SQL/YAML mentally, or pasting the snippet into any SQL scratchpad later.

-- Example starter table
select
  order_id,
  customer_id,
  amount,
  status,
  created_at
from raw_orders;

The goal is not tooling setup. The goal is learning the production habit: state the grain, clean one thing, test one assumption, and explain the downstream impact.

Self-Check Quiz

  1. What is the grain of the table you are building?
  2. Which downstream metric or dashboard would be wrong if this model broke?
  3. What test would catch the most likely beginner mistake here?

Real world

Where this shows up

  • Reliable executive dashboards that do not disagree across teams
  • AI analytics agents that query governed metrics instead of guessing SQL
  • Auditable metric changes where owners can see downstream impact before merge

Production notes

Keep these close

  • A model without an owner has no one accountable when it breaks. Ownership is part of the data product.

Common mistakes

What usually breaks

  • Writing descriptions that repeat the column name
  • Ignoring freshness until executives report stale dashboards
  • Changing column meaning without updating docs

Think like an engineer

Questions to answer before shipping

  • Can you explain the grain of this model in one sentence?
  • What breaks downstream if this field becomes null tomorrow?
  • Where should this logic live so it is reused instead of copied?

Key terms

Vocabulary used in this module

Freshness

How recently a source or model has received expected data.

Contract

A declared promise about model columns, types, and shape.

Exercises

Practice inside the lesson

30-45 minutesBeginner to Intermediate

Write the Model Contract Card

Document one model with grain, owner, freshness expectation, and important columns.

  1. Write the model description starting with "One row per..."
  2. Add owner and domain
  3. Add a freshness expectation for the source
  4. Mark columns that should not change type without review

Recap

Key takeaways

  • Freshness is a quality dimension
  • Documentation prevents repeated tribal explanations
  • Contracts make downstream breakage less likely

Related resources

Keep learning across CodersSecret