Baseline, scope, and revision boundaries

This is the GCP edition of the handbook. Its implementation source is commit cbbc807c0c150e106affa89fbb1b9e8349005749, resolved from the preserved final-gcp-commit tag. The documentation review date is 2026-10-04. Those two dates answer different questions: the commit identifies what was inspected; the review date identifies when this explanation was checked.

The reviewed current-main revision is 28c00d0d8b1fc6c00918a18faef5969bc0ef950a. Its executable infrastructure, release workflows, workload chart, and admission policies implement Azure. The restored root README describes GCP material. This website leaves that README and both cloud histories intact and identifies the edition explicitly so that readers do not mistake a historical explanation for current-main deployment instructions.

Why source links are pinned

A link to main changes meaning as the repository changes. A source link containing the full GCP commit continues to identify the same workflow, policy, or Terraform definition. That matters when explaining an exact certificate subject or comparing CI conditions with admission conditions: a later Azure edit must not silently change the evidence supporting a GCP statement.

Implementation links are separate from documentation-edit links. Editing this page changes the explanation. It does not change the historical policy. The baseline can be inspected with read-only Git commands without moving the current branch:

git rev-parse 'final-gcp-commit^{}'
git show cbbc807c0c150e106affa89fbb1b9e8349005749:.github/workflows/deploy.yml
git show cbbc807c0c150e106affa89fbb1b9e8349005749:policy/kyverno/block-unsigned-images.yaml

These commands reveal stored source, not remote GitHub settings or live cluster state.

Evidence has its own revision boundary

The owner validation record says its captures were taken on 2026-08-23. That date is attributed to the record; this website did not recapture the cloud environment. Older files under docs/evidence/ are retained upstream material and are not substituted for the owner’s validation.

The stored Helm selection is sha256:32a90d832fdf76794fa5477e42e1fdcec28c9eb6e0deee48ad466d1f7d9fc563. The source audit says that artifact was produced by the e369771… source run and selected by a later 9bf574c… Helm change. The evidence README associates successful CI with 9bf574c; this is useful corroboration but does not establish that the deployed artifact was built from that promotion commit. Treat the artifact build and desired-state selection as separate events.

There is a later, stricter CI verification record for source 27a94b0…, run 32638968765, and digest sha256:a0073f8f1d73f62ab0a15634a48387e78f6f837cff80f27a5c6e3b0a5c1eb16a. The historical status document explicitly keeps Helm on the earlier digest pending reviewed promotion. A newer verified artifact is therefore not evidence of a newer deployed workload.

The final source snapshot contains CI hardening added after the earlier artifact’s build. Its presence explains final configuration; it does not retroactively prove that an older run executed those newer checks. Recorded source references, artifact digests, capture dates, and content review dates remain distinct throughout the site.

Historical reproduction requires deliberate rebinding

Checking out this tag does not make its workflows runnable in a fork. The federation root trusts the canonical repository, certificate subjects name its signing workflow at refs/heads/main, policies match its historical registry, and Argo CD follows canonical main. Today’s main no longer contains that GCP chart.

An owned reproduction must intentionally align repository/ref identity, federation, registry scope, metadata location, policy expectations, and GitOps source. The reproduction guide explains that boundary. This task provisions no cloud resources and makes no source changes to satisfy historical claims.

Continue with how to interpret evidence when assessing what was configured, what was recorded, and what remains unverified.