Production Engineering Capstone: Mission, Rules & Definition of Done
Understand the capstone mission, reference system, evidence standard and graduation criteria.
Understand the capstone mission, reference system, evidence standard and graduation criteria.
Capstone phase
Phase 0 — Capstone Setup
Why this milestone matters
Treat production engineering as an evidence-based operating discipline rather than a collection of tools.
The capstone uses one production-like checkout platform throughout the track. The exact cloud or programming language can vary, but the engineering evidence must be equivalent. A typical reference stack is Kubernetes, a checkout/API service, PostgreSQL, Redis, Kafka/worker processing, an external payment dependency, GitHub Actions, GitOps/Argo CD, Prometheus/Grafana, searchable logs, IaC and a load-testing tool such as k6.
Choose individual or team execution mode and assign accountable owners.
Create one repository/folder for architecture, IaC, app config, dashboards, tests, runbooks, incidents and evidence.
Define what counts as proof: commands, graphs, logs, screenshots, Git history, test output and incident timelines.
Set a rule that every change must be reproducible and every recovery must be verifiable.
Required deliverable
Create a capstone charter containing scope, team roles, environments, evidence repository and Definition of Done.
A deliverable is not complete because a configuration file exists. It is complete when another engineer can inspect the source, reproduce the behavior and see evidence that the intended property actually holds.
Evidence required
A version-controlled capstone charter.
A checklist of mandatory deliverables.
A folder structure for evidence.
A written definition of successful graduation.
For every screenshot, graph or command output, record the time window, environment, version/revision and the question that the evidence answers. Prefer source-controlled configuration and machine-readable exports where practical.
Failure / review scenario
Production review questions
What user-facing outcome does this milestone protect?
What assumption are you making that still needs a test?
What is the blast radius if this design is wrong?
Which metric, log, trace, command or business check proves success?
What is the rollback, abort or recovery path?
Which later capstone experiment will validate this milestone under failure?
Definition of done
The artifact is version controlled or otherwise reproducible.
Ownership and decision rationale are visible.
A known-good baseline exists.
At least one negative/failure case has been considered or tested.
The user or business outcome is verified, not only infrastructure state.