Cloud Pak audit: the container reporting requirement.

Cloud Paks are licensed in Virtual Processor Cores, and the whole premise of VPC is that you pay for the cores your software actually consumes rather than the cores in the machines underneath it. That premise only holds when you can prove the consumption. IBM grants the lower, sub-capacity count on the condition that an approved metering mechanism runs in the cluster and produces a continuous record of peak usage. That mechanism is the IBM License Service, and the record it produces is the single most important artifact in a Cloud Pak audit.

This is the container equivalent of the ILMT rule that governs PVU sub-capacity on virtual machines. The logic is identical: sub-capacity is a privilege earned by evidence, and the absence of evidence is read conservatively. On a virtual host the conservative count is the whole host. In a container cluster the conservative count is the whole cluster, every worker node, for every period the reporting cannot account for.

What the requirement actually is

The License Service must be deployed in the cluster where the Cloud Pak runs, it must collect peak VPC consumption per product continuously, and the reports it produces must be retained so that any historical period can be evidenced on demand. This mirrors the broader sub-capacity discipline: deploy the tool promptly, keep it running without gaps, and hold the reports. A snapshot pulled the week the audit letter arrives does not satisfy a requirement that is about continuous history.

• The IBM License Service runs inside the cluster and captures peak VPC use
• Collection is continuous, covering every period back through the audit window
• Reports are retained so each historical quarter can be evidenced
• A gap in the record reverts that period to all cores in the cluster

How a gap becomes a finding

The License Service is not always deployed on day one. A team stands up a cluster, gets the Cloud Pak running, and adds the metering later, or upgrades the cluster and the service stops reporting for a stretch. Each of those gaps is a period IBM cannot see, and for each one the default count is the full cluster. A platform that genuinely consumed a modest slice of VPC can produce a finding sized to every node it ever ran on, multiplied across every quarter the record is missing. The finding is not measuring usage. It is measuring the hole in the evidence.

How we defend it

We reconstruct the consumption history from whatever exists: License Service data where it ran, cluster and scheduler logs, deployment manifests, and change records that establish when the software was actually present and at what scale. From that we build a defensible peak VPC figure per product and per period. Where the reporting genuinely lapsed, we contain the exposure to the specific window rather than letting a single gap justify a cluster wide, full period count, and we separate nodes that never could have hosted the workload from the count entirely. Then we fold the corrected position into the settlement.