Summary

  • The Estonian commercial register page for company number 14476114 displayed the name Puzl Cloud OÜ and listed GPU Computing OÜ under the heading "Invalid names" when read on 18 October 2026.
  • The RIPE organisation object that carries the same registration number, 14476114, still read GPU Computing OU, with a last-modified timestamp of 13 May 2026.
  • Autonomous system AS57063 announced the same two prefixes on 18 October 2026 as it had two weeks earlier: 213.5.72.0/24 and 2001:67c:f74::/48.

One number, two names, no contradiction

The entry on the Estonian commercial register for company number 14476114 does not read as a company profile. As retrieved on 18 October 2026, the Estonian commercial register page for company number 14476114 leads with a name, Puzl Cloud OÜ, followed by the number in brackets, and further down carries a line that matters more than its length suggests: under "Invalid names", the register lists GPU Computing OÜ. Read plainly, that is a register telling a reader which of the names in circulation for this legal person are historical, and which one it no longer treats as valid.

That is a specific, checkable statement about a name. It is also the only thing the retrieved passage establishes. Fields that a full commercial-register extract would normally display — whether the entry is active, what activity code the company files under, who its officers are — were not present in the retained text, so they are not asserted here. What matters for the argument is narrower and harder to dispute: the register, asked about 14476114, answers with Puzl Cloud OÜ, and flags the other name.

The RIPE database answers the same question differently. Queried for AS57063 on the same day, the record returns four objects, and one of them is the organisation object ORG-GCO2-RIPE. Its org-name attribute still reads GPU Computing OU. Its country is EE, its reg-nr is 14476114, and its address is a Tallinn block at Tartu mnt 83-701. Its last-modified timestamp is 13 May 2026, roughly five months before the register page was read and more than five years after the object was created on 9 December 2020. The full response is the RIPE database record for AS57063.

The two documents describe the same legal person — the registration number is identical — and give it different current names. Neither is obviously wrong. A registry object is a record of an assignment, not a live corporate feed; the Estonian register is a record of a legal person, not a routing register. They are allowed to disagree, and on this date they did.

The routing record was never keyed to the name

The part of the record that did not drift is the part that carries traffic. The aut-num object for AS57063 has an as-name of PUZL-AS. It was created on 2 November 2021 and last modified on 8 November 2024. So the operator's routing identity has been a puzl-derived string for as long as the object has existed, in a record that predates the most recent touch on the organisation object by two and a half years and postdates it by nothing at all in name terms.

The role object tells the same story from an earlier date. GCO8-RIPE is named GPU Computing OU, shares the Tartu mnt address, and carries an abuse mailbox on the puzl.ee domain — the domain, not the company name, is what the contact layer runs on. Its created and last-modified timestamps are identical: 9 December 2020, one second after the organisation object was created, which is what a single registration session producing several objects looks like. The year 2020 is worth holding in mind. Whatever the corporate history since, the domain-based contact path was in place before the AS number was assigned.

And the AS number itself has not changed hands in any visible sense. On 18 October 2026 the RIPEstat as-overview endpoint returned holder "PUZL-AS GPU Computing OU" and announced true — a string that reads exactly like the as-name and the org-name joined by a space, which is what it looks like when a summary service concatenates two fields it holds rather than resolving a current legal name. The endpoint's own status was ok, the response was not cached, and the query window was 18 October 2026 at 16:00 UTC: RIPEstat as-overview for AS57063.

A reader scanning only that surface would learn the AS number, two names at once, and no disagreement at all. The contradiction is only visible one layer down, in the two source documents that hold the two names.

Two prefixes, one stated blind spot

The operating footprint on the same date was small, stable and identical to the fortnight before. The announced-prefixes endpoint returned exactly two prefixes for AS57063: the IPv4 prefix 213.5.72.0/24 and the IPv6 prefix 2001:67c:f74::/48. Both carry a single continuous timeline from 4 October 2026 to 18 October 2026, and the response's latest_time is 18 October 2026 at 16:00 UTC. The detail is in the RIPEstat announced-prefixes response.

Two prefixes is a real observation and a bounded one, and the bound is stated by the service itself. The response includes an informational message noting that results exclude routes with very low visibility — specifically, routes seen by fewer than ten RIS full-feed peers. That sentence does a lot of work. It means the two-prefix result is what a well-connected observation point sees, not a complete inventory of everything a network might originate into a thinner path. Anyone treating two prefixes as the operator's total address space is reading past the caveat in the same document.

What the role of those prefixes actually is — whether 213.5.72.0/24 carries customer traffic, internal infrastructure, or a service edge — is not established by an announcement. A prefix in the global table is a statement that an origin is reachable, and nothing more.

The one question the documents cannot answer

Origin authorisation is the natural next question, and it is the one that failed. The RIPEstat RPKI validation endpoint for AS57063 returned no usable response body on 18 October 2026; the retained response records a failed retrieval with a null excerpt and carries no verdict of any kind: RIPEstat RPKI validation response.

This is worth being precise about, because it is easy to collapse two different things. A validation service that reports no result has told you nothing about whether the prefixes are signed. It has told you that you could not read the answer. Treating an unread endpoint as an unsigned prefix, or as a clean one, is inventing a fact in whichever direction the reader prefers. The honest statement is that origin authorisation for AS57063 remained unread on 18 October 2026, and that the document which would settle it — a validation result naming the covering resource certificates for 213.5.72.0/24 and 2001:67c:f74::/48 — was not obtained.

One further thread hangs loose. The aut-num carries a sponsoring-org attribute pointing at ORG-SDNS7-RIPE, an organisation object that was not read for this article. A sponsoring organisation on an assignment is a structural fact about how the resource was obtained, and it is the kind of thing that explains an assignment more fully than a name field ever will. Its presence is documented; its identity is not.

What the divergence actually costs

The tempting conclusion is that somebody has been negligent. The documents do not support that, and there is a duller explanation that fits them better. A registry object is edited when an operator has a reason to edit it: a new maintainer, a changed address, a resource request. A company rename is a reason to file with a commercial register, which is a legal obligation with a filing fee and a deadline. Nothing in that obligation creates a duty to touch an RIR object whose org-name field nobody is currently reading. Neglect of the name field is the default state, not a decision.

What that default state costs is not borne by the operator. It is borne by everyone downstream who treats a name as a key. A supplier register that lists a GPU-sounding company and looks it up under that name will not find the register entry, because the register answers to a different name. A counterparty screening a contracting entity by its trading name will not match the RIPE organisation object, because the number is there and the name is not. A competitor map built from company names will carry two entries or none.

The cheap correction is unglamorous and does not depend on any of the unread documents. Key the record on the registration number and the AS number, which both survived the rename, and store the name as a dated observation rather than an identifier: this entity was named X when checked on date Y. The number is stable, the code is stable, the two prefixes held for at least the fortnight observed. The name is the field that moves, and it should be treated as the least authoritative column in the row — including in this publication's own directory entry for the operator, the BTW directory entry for AS GPU Computing OU, which inherits the pre-rename name exactly as the registry object carries it.