The ninety day assessment, read before the renewal.

A Red Hat subscription assessment built over ninety days is a sequence of three four week windows. The first window builds the contract baseline. The second window reconciles the fleet against that baseline. The third window writes the findings ledger and the renewal posture. The cadence is not arbitrary, and it is not flexible without cost.1

Ninety days is short enough that the fleet does not drift in a material way between scope and ledger. Longer windows allow OpenShift core counts and Ansible managed node lists to move faster than the assessment can track, and the reconciliation closes against a fleet that no longer exists. Ninety days is also long enough to read each Red Hat order form in detail and to walk every product line through its counting mechanic without compression. Twenty days produces a checklist and a spreadsheet. Two hundred days produces a moving target.

The trigger is normally a renewal inside the next four quarters. The second trigger is an acquisition or divestiture that has brought a new Red Hat estate inside the perimeter, with inherited entitlement records that the prior owner kept separately. The third trigger is a soft compliance inquiry: an email from the Red Hat account team that asks about deployment counts in language that is not a formal audit notice but is also not casual. In each case, the ninety day cadence sets up the buyer's posture before Red Hat sets up its own.

This note describes the work that runs through the three windows and the artefacts that come out of each. For the broader scope of the engagement see the subscription assessment hub. For the way the assessment posture moves into the renewal negotiation, see the renewal negotiation hub. For the work that runs if the soft inquiry escalates, see the audit defense hub.

The first four weeks build the contract baseline. The work is paper, not telemetry, and the buyer's procurement function is the first interview. Every Red Hat order form, every renewal addendum, every product schedule, every co terminating amendment is read. The aim is a single ledger that lists each entitled subscription, the quantity, the counting unit, the term, the renewal date, and the order form clause that governs how it is counted.

Three artefacts come out of week four. The first is the entitlement ledger itself, with each line traceable back to a specific order form. The second is the counting unit map: socket pair, virtual datacenter, unlimited virtual, named user, managed node, core, and so on, with a notation for each product line on which counting rule applies. The third is the addendum register: every clause that modifies the default counting rule, every special pricing arrangement, every grandfathered tier that the current Red Hat order template no longer offers.

The baseline frequently surfaces its first findings without ever touching the fleet. Smart Management add ons paid for and not used. Subscriptions still active on systems that were retired in the prior twelve months. Order forms that contain a Red Hat Insights tier that the buyer never enabled. These are the easiest findings of the engagement and the most often missed in faster assessments, because the first instinct is to look at telemetry rather than at contract. Telemetry reads what is deployed. The contract reads what is owed. The gap between the two is where the assessment lives.2

Weeks five through eight read the fleet. The reconciliation runs across three surfaces in parallel: RHEL, OpenShift, and Ansible Automation Platform with the middleware estate attached. Each surface is read by an analyst who tracks that specific counting rule across the practice's engagement record, and the three reads are stitched together at the end of week eight rather than along the way.

RHEL reconciliation reads system inventory against the entitlement ledger. The operative comparisons are subscription count against host count, socket pair count against physical host configuration, and virtual datacenter coverage against hypervisor topology. Red Hat Insights inventory, Red Hat Satellite content host registration, the buyer's own configuration management database, and a representative sample of host telemetry are read in parallel. No single source is trusted on its own. For the counting mechanics in detail see the RHEL practice hub.

OpenShift reconciliation is the surface most likely to surface exposure rather than excess. Core counts on virtualized hosts change between renewals as cluster topology evolves. Control plane node treatment varies by contract template. The OpenShift Plus bundle introduces a parallel set of entitlements that overlap with stand alone Red Hat product subscriptions, and reading the overlap correctly is the difference between an exposure and a duplicate spend. For the mechanics in mixed environments see the OpenShift practice hub.3

Ansible Automation Platform reconciliation reads managed node lists against entitlement. Managed node drift between renewals is the most common quiet exposure in the practice. Lightspeed entitlements and additional execution environments compound it. JBoss subscriptions in transition between EAP versions sit on a parallel ledger, with the same reconciliation method but a different counting unit. For the managed node counting rules see the Ansible Automation Platform practice hub.

The last four weeks build the findings ledger and the renewal posture. The ledger has two columns. The left column is recoverable excess: entitlement paid for and not used, add ons that earn no keep, subscriptions on retired hosts. The right column is exposure: deployment that exceeds entitlement and would become a finding if Red Hat surfaced it first. Both columns are read together. Neither is read alone.

A normal twelve week engagement closes with a recoverable excess band in the low double digit percent of prior annual Red Hat subscription spend on RHEL, and an exposure on OpenShift that, if surfaced through an audit, would land in the same range. The two cancel arithmetically in a way that the renewal quote does not anticipate; the assessment posture brings them into one negotiation rather than leaving them on two timelines. Across the trailing twelve months, the practice has not seen an engagement where the two columns balanced to zero. One side is always heavier.

The renewal posture itself is a one page document. It states the entitlement the buyer intends to carry forward, the entitlement the buyer intends to release, and the exposure the buyer intends to address through reshape rather than through purchase. It is internal. Nothing in it is filed with Red Hat. Nothing in it is shared with the account team before the buyer chooses to. The posture is the starting point for the renewal negotiation, not the closing point.4

The deliverable closes the engagement. The next engagement is the renewal itself, or, if the assessment surfaced a soft inquiry that has since become formal, audit defense. The two are sequenced, not parallel.

The ninety day assessment is not an audit. Nothing is filed with Red Hat. Nothing is volunteered to the account team. The work is done by the buyer, for the buyer, on a timeline the buyer sets. If a soft inquiry from Red Hat has triggered the work, the inquiry remains a soft inquiry; the assessment exists to set the posture if the inquiry escalates, not to convert the inquiry into an audit by responding to it as one.

The assessment is also not a procurement exercise in disguise. It does not recommend buying more. It does not recommend a Red Hat enterprise agreement as a default. It reads the ledger as it stands and reports what the ledger says. If the ledger justifies expansion, expansion is recommended; if the ledger justifies release, release is recommended. The recommendation follows the reconciliation, not the other way round.5

The assessment is not a substitute for a contract review by counsel. It reads contract clauses for counting mechanics; it does not give legal advice on enforceability, indemnity, or jurisdiction. Where the assessment touches a clause that has legal weight, the recommendation is to bring counsel in for that clause specifically. The boundary is the difference between a buyer side assessment and a legal opinion.

Finally, the assessment is not a one off exercise. The ledger goes stale within a renewal cycle. The cadence repeats at twelve to eighteen months for buyers under continuous Red Hat exposure, and shorter than that for buyers in active acquisition cycles. The first assessment is the heaviest. Subsequent assessments work against an existing baseline and close faster.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.