gunnertwin · Oct 2, 2026
@@ -317,6 +317,9 @@ SOGs
 sonarcloud
 sonarlint
 sonarqube
+SRE
+statefulsets
+productionisation
 spective
 spellcheck
 springboot
@@ -423,4 +426,12 @@ validforhours
 DSF
 mpd
 wif
-templatise
+templatise
+ams
+BAU
+PlatOps
+courtlistpublishing
+listingcourtscheduler
+rfc
+RFCs
+HPAs
@@ -48,6 +48,11 @@ CRITICAL_PAGES = %w[
   cjs-common-platform/new-component/repository-and-build.html
   cjs-common-platform/new-component/infrastructure-and-connectivity.html
   cjs-common-platform/path-to-live/index.html
+  cjs-common-platform/path-to-live/productionisation.html
+  cjs-common-platform/path-to-live/operational-acceptance.html
+  cjs-common-platform/path-to-live/shutter.html
+  cjs-common-platform/path-to-live/monitoring-and-health.html
+  cjs-common-platform/path-to-live/alerting.html
   cjs-common-platform/live-service/index.html
   cjs-common-platform/live-service/egress.html
   cjs-common-platform/live-service/auto-shutdown.html

@@ -1,13 +1,13 @@
 ---
 title: Application charts
-last_reviewed_on: 2026-09-18
+last_reviewed_on: 2026-10-09
 review_in: 6 months
 weight: 1
 ---
 
 # <%= current_page.data.title %>
 
-CPP services deploy through a small set of shared application charts in [cpp-helm-chart](https://github.com/hmcts/cpp-helm-chart/tree/main). You do not write a chart for your service — you pick the chart that matches your service's shape and supply its values, either in [cpp-aks-deploy](https://github.com/hmcts/cpp-aks-deploy/tree/main) (Helmsman) or in a [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main) HelmRelease (Flux). See [Using and customising charts](using-and-customising.html) for how those values reach the chart.
+CPP services deploy through shared application charts in [cpp-helm-chart](https://github.com/hmcts/cpp-helm-chart/tree/main). Helmsman-managed services supply values in [cpp-aks-deploy](https://github.com/hmcts/cpp-aks-deploy/tree/main); Flux-managed services supply HelmRelease values in [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main). Both controllers deploy CCM applications. See [Using and customising charts](using-and-customising.html) for how those values reach the chart and [deployment ownership](../tools-and-configuration/index.html) for the environment and stack checks.
 
 | Chart | Purpose |
 |---|---|
@@ -129,7 +129,7 @@ Operational job charts, deployed when the corresponding task needs running rathe
 
 ## Real examples
 
-- **Flux**: every file under [`apps/base/services/`](https://github.com/hmcts/cpp-flux-config/tree/main/apps/base/services) in cpp-flux-config is a HelmRelease consuming one of these charts — `idam-integration-service` (springboot-app) is a good first read.
+- **Flux**: the service `helmrelease.yaml` files under [`apps/base/services/`](https://github.com/hmcts/cpp-flux-config/tree/main/apps/base/services) select these charts — `idam-integration-service` (springboot-app) is a good first read. Follow the environment and stack kustomizations to establish where a service is deployed.
 - **Helmsman**: the `[apps]` entries in [helmsman.toml](https://github.com/hmcts/cpp-aks-deploy/blob/main/helmsman.toml) in cpp-aks-deploy show every Helmsman-managed release, with values layered from `ansible/group_vars`.
 
 ## Related documentation

@@ -1,6 +1,6 @@
 ---
 title: Helm charts
-last_reviewed_on: 2026-09-30
+last_reviewed_on: 2026-10-09
 review_in: 6 months
 weight: 7
 ---
@@ -20,7 +20,7 @@ This section is the catalogue of those charts: what exists, what each one is for
 CPP has its own chart set alongside the Cloud Native Platform's, and the two follow different models:
 
 - **CNP**: every service repository contains its own small application chart, which depends on a centrally-maintained base chart such as `chart-java` — see the [CNP Helm charts section](/cloud-native-platform/standards/pipeline-libraries/helm-charts/index.html).
-- **CPP**: services do not have a chart of their own. A small set of shared [application charts](application-charts.html) (`springboot-app`, `wildfly-app`, and friends) is maintained centrally in `cpp-helm-chart`, and each service supplies only its **values** — from `cpp-aks-deploy` when deployed by Helmsman, or from a `cpp-flux-config` HelmRelease when deployed by Flux.
+- **CPP**: services do not have a chart of their own. A small set of shared [application charts](application-charts.html) (`springboot-app`, `wildfly-app`, and friends) is maintained centrally in `cpp-helm-chart`, and each CCM service supplies its **values** through `cpp-aks-deploy` and is deployed by Helmsman.
 
 The intent is the same in both models — services describe configuration, not Kubernetes YAML — but on CPP the chart templates themselves are shared, so a template improvement lands in `cpp-helm-chart` once and every consuming service picks it up on its next chart version bump.
 
@@ -35,12 +35,13 @@ Consumers always pin an exact chart version, so publishing a new version changes
 
 ## How charts are deployed
 
-Both deployment routes consume the same published charts:
+CCM applications consume the published charts through two controllers:
 
 - **Helmsman** — the established route for CCM services. [cpp-aks-deploy](https://github.com/hmcts/cpp-aks-deploy/tree/main) declares each release in its `helmsman.toml` files and renders per-environment values with Ansible.
-- **Flux** — the newer GitOps route, adopted recently for CCM applications. [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main) declares a `HelmRelease` per service and Flux reconciles merged changes into the clusters.
 
-[Using and customising charts](using-and-customising.html) covers both routes in detail, and [Tools and configuration](/cjs-common-platform/tools-and-configuration/index.html) explains which route a given service uses and which pipelines drive them.
+- **Flux** — [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main) defines HelmReleases for selected CCM services, including `idam-integration-service`. Environment and stack overlays determine where each service is deployed. Check [deployment ownership and the Helmsman guard](../tools-and-configuration/index.html) before selecting a route.
+
+[Using and customising charts](using-and-customising.html) covers both routes in detail, and [Tools and configuration](/cjs-common-platform/tools-and-configuration/index.html) documents the CCM deployment pipeline.
 
 ## Related documentation
 

@@ -1,6 +1,6 @@
 ---
 title: Using and customising charts
-last_reviewed_on: 2026-10-07
+last_reviewed_on: 2026-10-09
 review_in: 6 months
 weight: 3
 ---
@@ -33,11 +33,11 @@ The pieces that matter:
 - **Chart versions are variables**, resolved per environment, so environments can move to a new chart version independently.
 - Most charts are consumed straight from the OCI registry; the shared application charts are pulled and unpacked locally first by [helm_chart_pull.sh](https://github.com/hmcts/cpp-aks-deploy/blob/main/scripts/helm_chart_pull.sh) (so the pipeline can stamp the release's `appVersion`), which is why some entries reference `install/springboot-app` rather than an `oci://` URL.
 
-The deployment itself is run by the `CPP-AKS-DEPLOY` Azure DevOps pipeline — see [Tools and configuration](/cjs-common-platform/tools-and-configuration/index.html#deploying-applications-to-crime-aks) for the pipeline, its environments and its approval gates.
+The deployment itself is run by the `cpp-aks-deploy` Azure DevOps pipeline — see [Tools and configuration](/cjs-common-platform/tools-and-configuration/index.html#deploying-applications-to-crime-aks) for the pipeline, its environments and its approval gates.
 
 ## Consuming a chart with Flux
 
-The newer GitOps route. A service in [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main) is a `HelmRelease` that names a chart and exact version from the shared OCI `HelmRepository`, with the service's values inline:
+A Flux-managed CCM service definition in [cpp-flux-config](https://github.com/hmcts/cpp-flux-config/tree/main) is a `HelmRelease` that names a chart and exact version from the shared OCI `HelmRepository`, with the service's values inline:
 
 ```yaml
 apiVersion: helm.toolkit.fluxcd.io/v2
@@ -60,7 +60,7 @@ spec:
       tag: "${my_service_image_tag}"
 ```
 
-A reviewed merge to `cpp-flux-config` is all a deployment takes — Flux reconciles the change into the clusters; there is no deploy pipeline to run. Which environments and stacks a service reaches is controlled by the repository's overlay structure. That repository's own docs are the reference for this route:
+Flux reconciles merged configuration into the clusters selected by the environment and stack overlays; it does not use `cpp-aks-deploy` to apply the HelmRelease. PRP, PRX and PRD each require a separate approved [Halo RFC](../path-to-live/index.html#raise-an-rfc-for-each-environment). Merge a release change only in its approved window, then verify reconciliation and application health. The repository's runbooks describe validation, review and promotion:
 
 - [onboard-a-service.md](https://github.com/hmcts/cpp-flux-config/blob/main/docs/runbooks/onboard-a-service.md) — adding a service, including an automated Issue Form route for non-production
 - [deploy-images-across-environments.md](https://github.com/hmcts/cpp-flux-config/blob/main/docs/runbooks/deploy-images-across-environments.md) — promoting image versions