Most proofs-of-concept test whether a platform can stand up a cluster and run a demo app. That is necessary but not sufficient. For a sovereign, regulated environment, the PoC should test the properties you are actually buying.
Before you start
Agree the exit criteria in writing, and make sure at least one is a hard sovereignty test that a polished demo cannot fake. Scope it to one or two representative workloads, not your whole estate.
The tests that matter
1. The disconnected install
Install with the network physically disconnected. Mirror images to an internal registry; bring the platform up with no internet path. If it needs to reach a licence server or a vendor registry, that is a finding.
2. Fleet Day-2, offline
Do the boring operational things while disconnected:
- Upgrade the platform through your controlled pipeline.
- Rotate a certificate and a secret automatically.
- Back up and restore to storage inside the boundary.
- Provision a second cluster from the management plane.
3. A VM and a secret on the same stack
Run one existing virtual machine (KubeVirt) and one workload that consumes a rotated secret (OpenBao + External Secrets Operator) on the same platform. This proves the “one sovereign stack for VMs, containers, and secrets” claim, not just the container happy path.
4. The sovereignty checks
The ones a demo cannot fake:
- Audit the source for a component you care about.
- Watch the network — confirm there is no call-home when disconnected.
- Trace the control plane — confirm no foreign operator or jurisdiction touches it.
Turning a PoC into a decision
Score each exit criterion pass/fail, not vibes. A platform that passes the disconnected install, offline Day-2, the VM-plus-secret test, and the sovereignty checks has demonstrated the thing that matters — that you would own it.
When you’re ready to scope one against your environment, talk to an expert.