Step 1: Query the mart for Assel's questions
Assel needs answers. Query the mart table to produce the outputs she asked for:
- Storage utilization by bin and grain type across both elevators
- Spoilage events alongside weather conditions for those dates
- Patterns across the two facilities -- do both elevators see spoilage on the same days?
These are the queries that turn data into answers. The schema you designed serves these questions because you built it around what Assel needs, not around what the data happened to look like.
Step 2: Present to Assel
Open the chat with Assel. Share the results -- the combined data showing when spoilage occurred and what weather conditions were present.
Assel responds directly. She confirms the correlations match her intuition -- temperature drops below -15C with humidity spikes above 80% are the problem. She names specific bins she has been watching. She is satisfied with the data because it answers the question she has been asking for two years: which conditions cause spoilage?
Step 3: Manage the scope request
Assel follows up: "Can we also pull commodity prices from the exchange? If I can see grain prices alongside storage costs and weather risk, I can optimize dispatch timing."
This is a reasonable request. A second API source that adds price data alongside weather and storage would give her a complete picture for dispatch decisions. But it also adds extraction complexity, schema changes, and new verification needs.
Acknowledge the value. Note it as a future addition. The current scope is closed: storage and weather data are combined, correlations are verified, the pipeline works. Adding a second API source is the next project, not the end of this one.
This is scope management. Assel is not being difficult -- she is seeing what the data can do and wants more. Saying "not in this scope, here is why" is a professional skill.
Step 4: Write a pipeline summary
Direct Claude Code to write a brief summary of the pipeline: what it does, what data sources it uses, how the schema is structured, and what the verification confirms. This goes in the repository as documentation of what was built and why.
In future projects, orchestrators like Dagster will provide run status and pipeline lineage automatically. For now, the summary is the documentation. It tells the next person who opens this repository what they are looking at.
Step 5: Commit and push
Commit the work to Git and push to GitHub. Write commit messages that describe what each piece does and why -- not just "add files." The commit history is part of the deliverable. Someone reading it should understand the progression: load data, profile sources, design schema, extract weather, build staging, build mart, verify.
Check your understanding: Repository contains extraction script, staging SQL, mart SQL, source data, and meaningful commit history.