The change question — who, what, why, when, where, and how

Every audit asks the same five questions about a deployment: who did it, what was deployed, why was it deployed, when did it happen, and where is it running. The questions look simple. The answer is not, because each has a trap: the obvious answer is often wrong, and the correct answer often lives in a system the team did not think to consult.

The five questions

flowchart LR
    Q["Deployment event"]
    Q --> W1["Who: trigger identity"]
    Q --> W2["What: artefact identity"]
    Q --> W3["Why: rationale"]
    Q --> W4["When: timestamp"]
    Q --> W5["Where: environment identity"]
    W3 -.->|"lives in"| PR["Pull request"]
    W1 -.->|"lives in"| CI["CI system"]
    W2 -.->|"lives in"| REG["Artefact registry"]
    W4 -.->|"lives in"| LOG["Controller log"]
    W5 -.->|"lives in"| CL["Cluster metadata"]

• Who. Two answers. Trigger identity - the system or person who pressed the button. Decision identity - the human or process that decided the change should happen.
• What. The artefact identity. A container image digest, a Terraform plan checksum, a manifest set. The only part of the change with stable identity.
• Why. The rationale. The hardest to record; it lives in the PR description, the design document, the linked ticket.
• When. The timestamp. Two: when the artefact was built, and when it was applied.
• Where. The environment identity. Cluster, namespace, account, region.

A record that answers all five is audit-grade. The two questions most often left unanswered are who (the team did not distinguish trigger from decision) and why (the PR was closed without a description).

Why “why” is the hardest

The why is human context. It lives in the head of the engineer who wrote the change, in the conversation that produced the design, in the ticket that motivated the work. The deployment record cannot contain the why because the why is not known to the pipeline.

The why is captured, when captured at all, in:

• The pull request description. The most reliable place, because it is part of the same commit the artefact is built from.
• The linked ticket. A Jira or Linear ticket that describes the problem, the alternatives, the chosen solution.
• The design document. A long-form explanation linked from the PR.

The audit test: given a deployment, can you read the why from the linked PR without leaving the Git repository? If the PR description is empty, the why is lost.

The change question, applied to a Kubernetes deployment

NS=payments
APP=checkout
kubectl get deployment "$APP" -n "$NS" \
  -o jsonpath='{.items[*].metadata.annotations}'
# who (decision): pull request - look in the Git repo
# who (trigger): deploy pipeline - look in CI
# what: image digest in the container spec
# when: Argo CD sync timestamp / kubectl rollout history
# where: namespace and cluster - the kubectl context

A Deployment with no annotations cannot answer who, what, when, or where without leaving the cluster. A Deployment with annotations recording the source URL, the digest, and the deploy timestamp can answer all four; the why still requires the PR.

Production discipline

1. Distinguish trigger identity from decision identity in the record. The pipeline run is not the approver; the approver is the approver. Both must be recorded, separately.
2. Treat the PR description as the canonical “why”. A PR with an empty description is a PR with no audit-grade rationale.
3. Stamp the “where” at apply time, not at record time. A controller that records the cluster name when the resource is created is correct.

Cross-course references

• Linux for Production Sysadmins - Parts XXXIII (ChangeMgmt) cover the change-management process from the operating-system side, the analogue of the decision-identity field.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) covers the Ansible run log, which records the trigger identity and the inventory but not the decision identity.

Quiz