Content collections, outside the meter.

A content collection in Ansible 2.x is the packaging unit for one or more roles, modules, plugins, and supporting documentation, shipped under a namespace and a name with a semantic version. Red Hat publishes collections, hardware and software vendors publish collections, the upstream community publishes collections, and individual practitioners publish collections. The platform runtime pulls the collection into the execution environment image, or into the local Ansible content path, when a playbook references content inside it.1 The mechanism is technical; the commercial reading sits one layer up.

Red Hat divides the published content in commercial circulation into three categories. The first is certified content, which Red Hat or its certified partners author and to which Red Hat extends commercial support inside the platform subscription. The second is validated content, which Red Hat authors as a reference architecture or a tested pattern and to which Red Hat extends limited or no commercial support. The third is community content, which the upstream community authors and to which Red Hat extends no commercial support.

The buyer side reading is that none of these three categories is a metered metric. The platform meter is the managed node count, and the count is set at the far end of the connection regardless of whether the content that drove the connection is certified, validated, or community. For the meter itself, see the managed node counting article.

The certified category carries Red Hat commercial support inside the existing platform subscription. A buyer that operates a platform agreement and uses a certified content collection inside a playbook can open a Red Hat support case on the behavior of that collection. The case sits inside the platform support entitlement; there is no separate per collection charge. The certified mark is the indicator on the catalog entry; the support is the substance behind the mark.2

The validated category sits in a softer support shape. Red Hat ships validated patterns as reference architectures, often with a working playbook bundle, and represents them as tested against named platform releases. The commercial position is that validated content is supported as a pattern rather than as a piece of software per se. In practice the support response on a validated pattern is a triage and an engineering recommendation rather than a fix to the collection itself, because Red Hat is not typically the author. The buyer side reading is that validated content carries less support depth than certified content, and the buyer that depends on a validated pattern for a critical workload should plan for that gap before signature.

The community category carries no Red Hat support. A buyer that pulls a community collection from Ansible Galaxy and uses it in a playbook is operating outside the platform support entitlement on the behavior of that collection. The platform itself remains supported. The collection does not. The buyer side reading is that this is a perfectly defensible position in many estates, provided the operational risk profile of the workload allows for it. For mission critical workloads, the practice has typically advised clients to prefer certified content where available, validated content where it is the only option, and community content only where the support gap is consciously accepted.

Two renewal traps recur on the content conversation. The first is the upsell to certified parity, where the proposal frames the platform subscription as inadequate unless every collection in use is certified. This is not how the support entitlement works. The platform subscription supports the platform itself and the certified content the buyer chooses to use. It does not require every collection in the runtime to be certified. The buyer that runs a mix of certified, validated, and community collections inside a single platform subscription is operating exactly as the platform is designed to be operated.

The second trap is the private automation hub upsell, where the proposal frames a managed catalog inside the buyer's network as a distinct entitlement layer. The private automation hub is a useful operational tool for buyers who want curated control over the supply chain of certified content and execution environment images. It is a RHEL line on the host that runs it, not a separate metered metric on the platform agreement.3 For the controller and executor architecture, see the controller versus executor article.

Where the practice has seen recoverable corrections on the content line in 2026 renewals, the corrections have typically run through one of these two traps. The discipline is to read the content support boundary on its own terms and the platform meter on its own terms, and to refuse to bundle them where the seller side proposal sheet has tried to.

The audit posture on the content line is straightforward where the platform meter is read correctly. The certified collections in use are inside the support entitlement. The validated patterns in use are inside the pattern level support. The community collections in use sit outside Red Hat's support but inside the platform deployment, which means the playbooks that reference them still drove managed node activity that counts under the platform tier. None of this changes the audit posture on the meter. The meter is the managed node count.4

The audit complication arises only where the seller side finding cites the content mix as evidence of platform under licensing. The structural response is that content mix is not the meter. The defensible content posture is a documented internal policy on which categories of content are approved for which classes of workload, with the documented support gaps for the lower categories acknowledged in the buyer's own operational record. The practice has worked with clients to produce that documentation as part of pre audit hygiene; the document is short, the document is in the buyer's own voice, and the document carries weight in the response.

For the audit defense engagement that runs this work under a live inquiry, see audit defense. For the pre audit reconciliation, see the ninety day subscription assessment.

The buyer side reading of the content question at renewal proceeds in four steps. First, inventory the collections actually in use across the playbooks the platform is running, with the category of each: certified, validated, community, customer authored. Second, map each category to its Red Hat support boundary, with the gaps documented. Third, refuse to allow the support boundary conversation to become a meter conversation, because the meter sits at the managed node and not at the collection. Fourth, sign the platform tier at the managed node count, with the support tier set at the depth the buyer's content mix actually requires.5

Across recent practice engagements, this discipline has produced a recoverable correction on renewal proposals that bundled a certified parity upsell or a private automation hub mandate as if they were structural to the platform tier. They are not. The platform tier is the managed node count. The content posture is a separate operational decision. The order form should reflect both, but not by stacking them.

For the wider Ansible Automation Platform practice, see the Ansible Automation Platform practice hub; for the renewal engagement, see renewal negotiation; for direct contact, see the contact page.

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.