A certification count is only as strong as the evidence behind it. Server inventories, tool output, and a written methodology are what let you show how every certified number was reached, and they are the defense when an audit questions the count in the years after you exit.
It is tempting to treat the certified number as the finish line. It is not. The number is a claim, and a claim without evidence is fragile. Audit risk rises in the first two years after certification, and when it does, the question is never simply how many processors you declared. It is how you arrived at that figure and whether you can show your working. The evidence file is what turns a defensible count into a defended one. This article explains what belongs in it and why it matters as much as the number itself.
A complete evidence file has four parts. The first is server inventories, a record of every machine in scope with its cores, processor type, and the products and options running on it. The second is discovery and tool output, the raw data from whatever tooling you used to measure deployment, captured and dated. The third is a written counting methodology that explains the rules you applied, the core factors you used, and how you treated edge cases. The fourth is contract references, linking each line of the count back to the clause that makes it countable. Together these let anyone, including an auditor, retrace exactly how each certified number was reached.
Notice that the evidence does more than support the total. It supports every line. An audit rarely challenges a count in aggregate. It challenges specific environments, specific servers, specific options. Evidence organised line by line answers those challenges directly, while a single summary spreadsheet does not.
Server inventories describe what you measured. Tool output is the raw proof of what was running. The written methodology explains how the raw data became a count. Contract references tie each line to the right to count it. A number with all four behind it is defensible. A number missing any of them is a claim waiting to be questioned.
Certification ends the unlimited right and fixes your entitlement. It does not end Oracle's audit rights. In the two years that follow, audit attention is at its highest, and the certified counts are the baseline an audit measures against. If the audit finds deployment that looks inconsistent with the declaration, the evidence file is what reconciles the two. With it, you show that what you certified was complete and correctly measured, and that any later growth is exactly that, later growth to be licensed deliberately. Without it, you are reconstructing a count from memory under pressure, which is the weakest position to defend from.
This is why the evidence is built during the count, not after a letter arrives. Data captured at certification time, dated and organised, carries weight. Data reassembled two years later does not, because the estate has moved on and the original state can no longer be observed directly.
Consider an indicative case. An insurer certifies a substantial processor count, capturing production, test, disaster recovery, and several in scope options. Eighteen months later an audit letter arrives. Because every line of the original count was supported by dated discovery output, a server inventory, and a written methodology, the response is a matter of presenting the file rather than rebuilding it. The audit closes without a penalty. The outcome turns on the evidence having existed from the start, and the figures here are indicative.
The practical approach is to treat evidence as a product of the count rather than a separate task. As each environment is measured, capture the raw output, record the server details, and note the contract basis for counting it. Date everything. Where a judgement was made, for example on how a virtualized cluster was treated under Oracle's partitioning stance, write down the reasoning at the time. By the time the count is complete, the evidence file is complete too, because it was assembled alongside the number rather than chased afterward.
The same discipline protects the maximization you worked for. Capturing test, disaster recovery, eligible cloud, and properly handled virtualized clusters lifts the count, often to 1.5 to 2.5 times a first pass, but only if each of those additions can be evidenced. An uplift you cannot prove is not a gain, it is exposure. The figure is indicative and depends on the estate and the contract.
Good evidence is contemporaneous, complete, and organised to the line. Contemporaneous means captured at the time of counting, not reconstructed. Complete means every environment in the declaration has support behind it, with nothing certified on assertion alone. Organised to the line means an auditor can pick any server in the count and find the inventory, the tool output, and the contract basis for it without a hunt. A file with those three qualities answers most audit questions before they are asked.
Evidence supports the count built in counting Oracle deployments for certification and the layer described in counting options and management packs. To turn your evidence into a clear, repeatable record, read documenting the counting methodology. For the full exit, see our Oracle ULA certification guide.
Server inventories, discovery and tool output, a written counting methodology, and contract references for each line. Together they let you show how every certified number was reached, which is the defense if an audit questions the count later.
Audit risk rises in the first two years after certification. The evidence file behind the certified counts is what answers an audit letter cleanly. Without it, a defensible number becomes hard to defend simply because it cannot be reconstructed.
We assemble the evidence as we count, so the number you certify is one you can stand behind for years.