Summary

  • In a snapshot returned on 12 September 2026, AFRINIC’s statistics homepage showed 122 new members, 2,609 members in total and an “Increase” of 4%. It did not identify the baseline, comparison period, formula, rounding rule or data timestamp behind that percentage.
  • Four other cards used the same three-part presentation: Route(6) 6,330 and 127,513 with 4%; IPv4 /24 614 and 438,182 with 0%; IPv6 /32 73 and 11,372 with 0%; ASN 121 and 2,787 with 4%.
  • Each displayed integer is arithmetically compatible with taking the year-to-date count as a share of the displayed current total and discarding the decimal part. That is a useful observation, not proof of AFRINIC’s code, intended denominator or definition of “Increase.”
  • The complete IPv6 and ASN downloads reproduce the corresponding current and 2026 counts. AFRINIC already exposes useful drill-downs and raw data; adding a small versioned metric receipt would turn its headline percentages from plausible labels into auditable public statistics.

Five tidy cards, one unresolved word

The most consequential word on AFRINIC’s statistics homepage is not “Member,” “IPv6” or “ASN.” It is “Increase.” The word appears beside a percentage, so the eye supplies a story before the page has supplied a definition. A reader sees 122 new members, a current total of 2,609 and 4%, and naturally understands a measure of growth. Yet growth is not a raw property of either count. It is the output of a comparison rule.

At the frozen response time, the homepage presented five cards. Membership showed 122 for “This Year,” 2,609 as “Current Total” and 4% as “Increase.” Route(6) showed 6,330, 127,513 and 4%. IPv4, expressed in /24 equivalents, showed 614, 438,182 and 0%. IPv6, expressed in /32 equivalents, showed 73, 11,372 and 0%. ASN showed 121, 2,787 and 4%. Those are five different measurement universes. Members are organisations admitted to a registry. Route(6) is a routing-related series. IPv4 /24 and IPv6 /32 are normalized resource quantities. ASNs are number resources.

Their proximity on a dashboard does not make them additive, comparable measures of demand or interchangeable indicators of institutional performance.

What the cards share is a publication grammar: a year-to-date figure, a current total and a whole-number percentage labelled Increase. That grammar creates an expectation of reproducibility. It does not require the portal to reveal its source code. It requires enough information for a careful reader to know what the numerator and denominator mean, where their time boundaries sit, and how the displayed integer was produced.

The public page does not provide that information next to the cards. In the complete captured homepage, there was no reader-visible “data as of” line, baseline date, denominator definition, formula, rounding note, snapshot identifier or revision notice. The HTTP response carried a Date header. That header records when a server returned a response; it is not evidence that every underlying series was refreshed at that instant. Treating transport time as data time would create precisely the provenance error that a public statistics portal should help readers avoid.

A compatible calculation is not a disclosed method

There is an obvious calculation to test. Divide each “This Year” count by the displayed “Current Total,” multiply by 100 and take the integer below the result. The five cards are compatible with that operation.

For membership, 122 divided by 2,609 is about 4.68%. For Route(6), 6,330 divided by 127,513 is about 4.96%. For IPv4, 614 divided by 438,182 is about 0.14%. For IPv6, 73 divided by 11,372 is about 0.64%. For ASN, 121 divided by 2,787 is about 4.34%. Discarding the fractional part gives, respectively, 4%, 4%, 0%, 0% and 4%: exactly the five displayed labels.

That match narrows the possibilities. It does not settle them. The page might use that formula, or a computationally equivalent one. It might use a stored percentage prepared elsewhere. It might apply a business rule before the figures reach the page. It might refresh the numerator and current total on different schedules. Nothing in the rendered page allows an observer to distinguish those cases. Arithmetic compatibility must not be promoted into a claim about implementation.

There is also another entirely ordinary denominator. If the year-to-date number represents a net addition contained within the current stock, a reader may compare that addition with the implied opening stock: current total minus this year’s number. Under that interpretation, Route(6) is 6,330 divided by 121,183, or about 5.22%, rather than 6,330 divided by 127,513, or about 4.96%. The displayed 4% does not tell the reader which denominator the publisher intends, because integer presentation has removed the evidence that might discriminate between them.

Membership illustrates the same issue at a smaller scale. The two simple ratios are about 4.68% against the current total and 4.91% against an implied opening stock of 2,487. ASN gives about 4.34% against the current total and 4.54% against an implied opening stock of 2,666. IPv6 gives about 0.64% and 0.65%. IPv4 gives about 0.140% under either simple denominator. These alternative calculations are not proposed corrections. An implied opening stock may be invalid if the year-to-date count is gross rather than net, if closures or returns are handled separately, or if late registrations revise earlier periods.

The point is narrower: an integer percentage cannot carry the missing semantic choices by itself.

Even the word “increase” permits several legitimate constructions. It can mean gross additions during the calendar year divided by the latest total. It can mean net change from an opening snapshot divided by that opening snapshot. It can mean the movement of a normalized resource quantity, including returns and corrections. It can be an annualized rate, a rolling-period comparison or a current-year-to-date share. Each answers a different question. None is self-authenticating.

Zero is especially easy to misread

The two 0% cards show why whole-number publication is not harmless decoration. A 0% label can be read as “nothing changed.” Yet the IPv4 card pairs it with 614 /24 equivalents this year, and the IPv6 card pairs it with 73 /32 equivalents. The label evidently does not mean a zero numerator. Under the compatible current-total calculation, it means a positive rate below one percentage point after the decimal detail is removed.

That distinction matters in public communication. A small positive movement may be immaterial for one decision and meaningful for another. A network planner, member applicant, policy participant and researcher do not share one threshold of significance. Showing one decimal place would reduce the ambiguity—0.1% for IPv4 and 0.6% for IPv6 under the tested calculation—but decimals alone would not disclose the denominator or the data date. Precision is not provenance.

Nor should the five labels be arranged into a league table. A 4% membership label and a 4% ASN label do not establish a common growth rate in any operational sense. The member series counts institutional records; the ASN series counts resources. Route(6), IPv4 /24 and IPv6 /32 introduce still other units and life cycles. The dashboard may be designed as a compact doorway into separate statistical domains, not as a comparative scorecard. A defensible reading therefore keeps every card inside its own metric universe.

The same caution rules out a more tempting claim: the page does not prove adoption, utilization or deployment. An IPv6 /32 quantity in registry data does not by itself show routed deployment, traffic, customer availability or useful production use. An ASN registration does not show that the number is visible in BGP. A member count does not measure service quality. These figures can describe administrative or resource states without measuring outcomes further downstream.

The drill-downs show that auditability is close

AFRINIC has not published a black box. The homepage links into dedicated statistical views for membership, IRR, IPv4, IPv6 and ASN. Those pages expose filters, charts or tables and, importantly, download paths. The institutional choice to make data available is the reason the missing metric definition is so conspicuous: much of the evidentiary infrastructure already exists.

The membership view exposes a country and year-oriented exploration of the registry’s member population and offers a CSV download. Its raw-data schema includes organisation name and registration date fields. In this review, the captured member download was capped before the full declared response length, so it supports the existence and structure of the download but not an independent reconstruction of the homepage’s 2,609 total or its 122 year-to-date figure. A partial capture must not be passed off as a complete census.

The IPv4 view similarly provides historical and geographic exploration and a raw download. That capture was also capped before the declared response length. It is evidence for the available schema and delivery route, not a basis for claiming that every one of the homepage’s 438,182 /24 equivalents or 614 year-to-date equivalents was independently recomputed here.

The IPv6 download was complete. Summing its normalized slash_32 values reproduces 11,372, and selecting records assigned in 2026 reproduces 73. The ASN download was also complete: it contained 2,787 data rows, of which 121 carried a 2026 registration year; the latest registration date visible in the frozen file was 11 September 2026. These are strong and useful joins between two headline cards and their underlying records.

Those successful joins establish data traceability for the counts. They do not establish the meaning of the percentage. Reproducing 73 and 11,372 still leaves the reader to infer why their relation is called Increase, which denominator is normative, whether 2026 begins in UTC or another timezone, whether the current total and year-to-date slice share one extraction instant, and whether removed or corrected records alter the sequence.

The IRR view belongs in the same publication landscape. It offers its own exploration and a raw-data archive. This article does not use that archive to reconstruct the Route(6) card, and it does not assume that the IRR and Route(6) labels are synonymous merely because both concern routing-related material. The evidence is enough to show that AFRINIC operates several inspectable statistical surfaces; it is not enough to collapse their definitions.

What a metric receipt would contain

The remedy is not another explanatory essay. It is a compact, versioned receipt attached to each headline metric. For membership, it could say that the numerator counts a specified class of registration events effective from a stated calendar boundary through a stated extraction timestamp; that the denominator is either the current active stock or the opening stock; and that the published percentage uses a named formula and rounding convention. The same structure can be adapted to each resource series without pretending that all five series share one business rule.

A usable receipt would contain the metric name and unit; the inclusion and exclusion rules; a source or extract identifier; an as-of timestamp and timezone; the year-boundary convention; the exact numerator and denominator; the comparison period; the formula; and the display rounding rule. It would state how returns, closures, transfers, corrections, duplicate records and late-entered records affect both counts. It would identify the versions of the page and data method, link to the relevant drill-down and download, and preserve a correction lineage when a historical value changes.

That sounds elaborate only when written as prose. As structured metadata it is small. A reader might see: “2026 additions: 122; current active total: 2,609; extracted at [timestamp]; rate: additions/current active total × 100; rounded down to a whole percent; method version [identifier].” If the actual rule differs, the receipt should state the actual rule. The objective is not to impose one formula. It is to remove the need for outsiders to reverse-engineer one from five integers.

There should also be a stable snapshot reference. Live dashboards are valuable for current awareness, but they are difficult to cite after the underlying data changes. A daily or release-based extract identifier would let a journalist, researcher, member or internal reviewer return to the same observation. When a late record or correction changes a prior count, a short revision entry can say what changed and why. This would protect AFRINIC as much as its readers: legitimate revisions would no longer look like unexplained discrepancies between screenshots.

The receipt should separate record time from publication time. A resource may have an assignment or registration date; a file has an extraction time; a dashboard build has a generation time; an HTTP response has a delivery time. These are different clocks. Publishing only one—or leaving all unstated—encourages readers to substitute the clock they happen to see. A two-line temporal note would prevent that category error.

A bounded conclusion from one snapshot

This examination is deliberately bounded. It uses one frozen homepage response and the official drill-downs and download endpoints linked to the statistical service. It does not claim that the displayed values stayed unchanged before or after that response. It does not inspect private code, internal data transformations or operational databases. It does not allege that AFRINIC used an incorrect formula. It does not infer motive from missing documentation.

The two capped downloads impose another boundary. Their schemas and availability can be described; their full totals cannot be certified from the captured bytes. By contrast, the complete IPv6 and ASN files permit exact joins for their headline counts. Keeping those evidence classes separate is not pedantry. It is the difference between an auditable finding and a narrative that quietly outruns its source.

The finding that survives every limit is simple. AFRINIC publishes five whole-number increases next to year-to-date and current totals, and the public interface does not state the baseline, formula, rounding or observation time needed to reproduce the percentages as defined measures. A simple operation fits all five labels, but the fit is not proof of the method. Two raw downloads reproduce four underlying counts, but those joins are not a definition of Increase.

That is why the missing baseline matters. The portal is already useful; the counts are already unusually open; the gap is small enough to fix without redesigning the service. One versioned receipt per metric would connect the number on the card to the records beneath it and the institutional decision embedded in its label.

Official source trail