Defined metrics in an OpenPass enterprise agreement.

Most audit findings do not begin with a count. They begin with a definition. When the contract leaves a metric vague, the vendor supplies the meaning at audit time, and it supplies the meaning that produces the larger number. An OpenPass agreement is the place to take that power back by defining every metric that applies to your estate.

A licensing metric is the unit you are charged against: a named user, a concurrent user, a core, an event per second, a document volume. The metric is only as reliable as its definition. If the agreement says you are licensed for a number of named users but never defines what makes someone a named user, the definition becomes whatever the auditor decides during the review. That is not a drafting oversight. It is the mechanism through which the opening finding inflates.

This is why metric definition, not price, is often the most consequential part of an OpenPass negotiation. A price you overpay is a known, bounded cost. A metric you leave undefined is an open ended liability that compounds with every audit across the term. The buyer who spends the negotiation arguing about discount percentages while leaving the definitions blank has optimised the smaller number and conceded the larger one.

Why vague metrics favour the vendor

An undefined metric is an open question, and at audit time the vendor answers it. A named user count can swell to include service accounts, dormant logins, and integration identities. A consumer count can stretch to cover anyone with read access rather than active users. A capacity metric can be read against peak rather than sustained load. Each interpretation is defensible only because nothing in the contract rules it out. The general pattern of reinterpretation is described in how to challenge OpenPass metric definitions, and the way it plays out across the Micro Focus estate is in our ALA and entitlement review track.

Who should own the metric definitions

Metric definitions sit at the intersection of legal, procurement, and technical knowledge, which is why they are so often left to none of them. Legal drafts the contract but rarely knows how a named user is counted in practice. Procurement negotiates the price but treats the metric as a given. The technical team understands the systems but does not see the contract. The definitions fall into the gap between the three, and the vendor fills that gap at audit time. A defended estate assigns clear ownership of the metric language to someone who can see all three perspectives at once.

That ownership matters because a metric definition is only as good as the reality it describes. A definition of named user that excludes service accounts is worthless if no one can produce the list of service accounts when the audit arrives. The definition and the evidence have to be designed together, so that the contract language and the records that support it agree. This is why metric work is done alongside the reconstruction of the license position rather than after it. The definition states the rule, and the reconstruction proves you meet it. To get both right before they are tested, open a case and we will align the definitions with the evidence your estate can actually produce.

What a defined metric looks like

A defined metric in an OpenPass agreement states the unit, the population it counts, the exclusions that apply, and the method of measurement. For a named user, that means specifying that service accounts, system accounts, and dormant identities are excluded, and that a named user is a distinct human with active access. For a capacity metric, it means stating whether the figure is sustained or peak, over what averaging window, and excluding non production and lab environments. The more precisely each metric is written, the less room remains for an audit to expand it. The reverse engineering of a defensible baseline that supports these definitions is covered in building an OpenPass target baseline before negotiation.

Precision also means anticipating the edge cases the vendor will probe. A definition of named user that excludes service accounts should say what a service account is, so the exclusion cannot be argued away. A definition of capacity that uses a sustained measure should state the averaging period, so a short spike cannot be reclassified as the norm. Good metric language reads like it was written by someone who has seen exactly how the count gets inflated, because that is precisely the perspective it should come from.

The metrics that most need defining

Across an OpenText and Micro Focus estate, the metrics that most reward precise definition are user metrics, where the boundary between active and inactive identities is contested, and capacity metrics, where the gap between peak and sustained is large. Output and volume metrics, common in customer communications and archiving, reward definition of what counts as a chargeable unit. Each of these is a place where a single sentence of contract language can prevent a seven figure dispute.

The relationship between these definitions and the order form that records your entitlements is worth understanding, because the two must agree. An order form that lists a quantity against a metric the contract never defines is an invitation to a future argument. Where the estate includes Micro Focus products, the definitions also interact with the Additional License Authorizations, which is why metric work and authorization review are usually done together rather than in isolation.

Defining metrics at conversion

The natural moment to define metrics is when a finding converts into an OpenPass agreement. At conversion the corrected counts are already on the table, and writing the definitions that produced those corrected counts into the contract makes them permanent. A finding that was reduced by disqualifying service accounts should produce an agreement that defines named users to exclude service accounts. That way the reduction is not a one time concession but a standing rule. The conversion sequence is in how OpenPass converts a post audit finding forward, and the protections that accompany the definitions are in audit protections to negotiate into an OpenPass agreement.

An example of definition over discount

In a recent technology engagement, a Fortify developer seat finding settled at a fraction of the opening number once actual scan submitters were separated from everyone with repository access. The lasting value was not the discount. It was the metric definition that followed it into the forward agreement, fixing a developer seat as an active scan submitter rather than anyone who could reach the repository. The same definition that won the audit now governs every count after it. That is why defined metrics matter more than a single settlement figure, and it is the core of our OpenPass enterprise agreement negotiation work.

Define it now, or argue it later

Every metric left undefined in an OpenPass agreement is a future argument the vendor starts ahead in. Every metric defined in your favour is an argument that never happens. The work of defining metrics is unglamorous and decisive, and it is far cheaper than the finding a vague metric produces. If you are negotiating or renewing an OpenPass agreement, open a case and we will identify the metric definitions that most need fixing before they cost you.