Summary

  • AFRINIC’s transfer files produced from 10 to 13 September 2026 each contain the same 128 transfer objects after JSON member order is normalised. The wrapper’s production time and coverage end advance each day.
  • The maximum transfer_date in all four files is 18 June 2026. That does not prove a later transfer is absent or delayed; it proves that file currency and event currency are different claims.
  • A compact snapshot-coverage receipt could state whether the publisher checked through a source-system watermark, accepted no new event, applied a correction or ingested a late record.

The most recent date in a file is not always the date of the most recent thing described by the file. AFRINIC’s public transfer archive makes that distinction unusually visible.

The archive contains separate cumulative JSON snapshots for 10, 11, 12 and 13 September 2026. Each identifies AFRINIC as producer, uses transfer-statistics version 4.0 and reports UTC offset 2. Each advances production_date. Each also advances records_interval.end_date to the time at which that daily file was produced, while retaining 1 January 2018 as the interval’s start.

Inside the wrapper, the record set does not move. Each snapshot contains 128 transfer objects: 101 marked MERGER_ACQUISITION and 27 marked RESOURCE_TRANSFER. Recursively normalise the order of JSON object members and compare the transfer array as a multiset, and all four sets are identical. The raw files still have different hashes, because their wrapper timestamps and serialized member order differ. Byte change is therefore not evidence of business-event change.

The newest transfer_date is 2026-06-18T15:48:49Z. The object is an AFRINIC-to-AFRINIC merger-and-acquisition record from Global Internet Company to Hormuud Telecom Somalia INC, both carrying the country code SO. It includes AS37326, one IPv4 range and one IPv6 range. The named parties matter here only because the object fixes the maximum public event time. The record supplies no basis to infer delay, dispute or defect in that transaction.

The strongest reading is routine publication

A cumulative register should not invent an event merely to keep its last event date close to its file date. A period with no new publicly recorded transfers may be entirely real. A daily production job can also be useful even when its business rows do not change: it gives downstream users a fresh artifact, a current schema wrapper and a chance to detect whether the service still runs.

AFRINIC’s schema supports part of that reading. It defines production_date as the date and time the file was produced. It defines records_interval as the period from which the file’s records are covered. Those are not definitions of transfer_date, which is separately defined as the date of the transfer. The design therefore recognises more than one clock.

The gap is narrower. The public schema does not say what procedure stands behind the moving interval end. Does it certify that every authorised source was checked through that instant? Is it simply copied from the generation clock? Does a zero-change file mean that the ingestion watermark advanced but no record was accepted, or only that the generator rewrote yesterday’s cumulative set? How would a correction or a late-arriving transfer be distinguished from a newly executed transfer?

None of those unanswered questions proves a missing row. They identify the limit of the public evidence.

Fresh wrapper, stable event set

The distinction matters because automated consumers tend to reward whatever time field is easiest to compare. A monitor may see a 13 September interval end and label the dataset “current”. That label can be defensible for the snapshot as an artifact. It becomes misleading if it is silently carried over to the event population, suggesting that the last event also occurred on or near 13 September.

The reverse inference is just as weak. Seeing 18 June as the maximum event date does not establish that transfers stopped, that requests accumulated or that the new transfer policy failed to move. The file describes published events; it does not reveal the private request queue, rejected or withdrawn cases, internal approvals awaiting completion, or events outside the public definition. AFRINIC’s own remarks also say that the report is not intended to supply all information related to a transfer.

Counts need similar discipline. The 128 objects are not necessarily 128 contracts, counterparties or commercial deals. One object can carry an ASN, an IPv4 set and an IPv6 set. The annual distribution—13 objects in 2018, 19 in 2019, 20 in 2020, 22 in 2021, 28 in 2022, eight in 2023, five in 2024, nine in 2025 and four in 2026—is a description of objects in this schema, not a market-volume series.

AFRINIC’s transfer guide says executed transfers will be published with transferor, originally held resource, recipient, date and type. That commitment makes the cumulative log operationally valuable. It also makes temporal provenance worth stating precisely, because an operator, broker, researcher or counterparty may use the file as evidence that a registry change has entered the public record.

Add a receipt, not a case dossier

A privacy-safe snapshot-coverage receipt would be small. It would bind the schema version, production time and claimed coverage end to the maximum included event time, object count and a canonical digest of the transfer set. It would link the previous snapshot digest and state how many objects were added, corrected, withdrawn from the public representation or ingested late.

The crucial field is the source-system watermark: the point through which the authorised publishing inputs were checked. If the watermark advances and no object is accepted, the receipt can say so. If a past transfer is later corrected, the receipt can classify the delta as a correction rather than make consumers infer a new transaction from a changed file. Private applications, contracts, correspondence and due-diligence evidence need not be disclosed.

The four September files are internally coherent. They do not show a contradictory transfer date or a changing business count. Their lesson is more modest: a current file and a current event are different evidence objects. AFRINIC already publishes both clocks. One short join would tell readers what the advancing clock actually certifies.

Sources