Tianjin new cloud network technology co., LTD leaves a cloud-network name without live BGP proof

Summary

• AS59004 is a valid autonomous-system registration. Its RDAP record names the resource TNCNT, assigns it to China, records registration on 4 April 2016 and records its last change on 16 June 2021. The corresponding RIPE overview expands the holder to Tianjin new cloud network technology co., LTD.
• At the 11 July 2026 observation point, RIPE reported zero announced IPv4 prefixes, zero announced IPv6 prefixes, no visible address space, no first-seen or last-seen routing entry, zero visibility among 327 IPv4 and 322 IPv6 full-table peers, and zero observed neighbours for AS59004.
• CAIDA independently marked AS59004 seen=false. It reported a prefix cone of zero, an address cone of zero and no provider, peer or customer degree. The one ASN counted in its AS cone is AS59004 itself, not a downstream network.
• Those results establish that the registered ASN does not currently provide an observable public BGP edge. They do not prove that the company has dissolved, that it owns no equipment, or that it could not resell or operate services inside another provider's network.
• Any credible cloud-service claim would require evidence beyond the name and number: an orderable service, reachable endpoints, facility and hardware boundaries, licensed operating scope, transit and power dependencies, support coverage, backup tests, billing continuity and a workable customer exit path. None is established by the reviewed public evidence.

The name describes an ambition; the route table describes a condition

“New cloud network technology” is unusually dense with infrastructure meaning. Cloud suggests pooled compute, storage, software control and metering. Network suggests reachable endpoints, address space and paths through other autonomous systems. Technology suggests an operating capability rather than a paper reservation. Yet none of those implications can safely be inferred from a corporate name.

The observable fact is smaller. The RDAP response for AS59004 identifies one autonomous-system number, gives it the name TNCNT and country code CN, and places its registration event on 4 April 2016. RIPE's AS overview renders the holder as TNCNT - Tianjin new cloud network technology co., LTD, places the number in the APNIC-assigned 58368-59391 block and marks it unannounced at the research cut-off.

That is meaningful evidence. An ASN is not a decorative company identifier. It is a number used in interdomain routing so that a network can express routing policy and appear in the paths that carry reachability across the internet. APNIC's guide to autonomous system numbers explains the role of an ASN in identifying a group of IP networks with a single, clearly defined external routing policy. The registration therefore shows that an internet-number authority assigned a network identity associated with this company.

It does not show that the identity is active. Nor does it state that the company runs a public cloud, hosts customer machines, owns a data centre, leases a rack, holds a current IDC licence, has customers, employs support staff or can restore a failed workload. These are different propositions with different evidence requirements. The distinction is especially important here because every current routing measure attached to the ASN is empty.

The company name should therefore be read as a label, not a service catalogue. A buyer cannot derive virtual-machine sizes, storage durability, bandwidth, data location or operational status from it. The public number record supplies a starting point for due diligence, and the lack of a route determines the first question: what, if anything, is operating behind the name today?

AS59004 is administratively real

The administrative identity has a coherent chain. The IANA autonomous-system registry assigns the containing 16-bit block to APNIC. The RDAP result states that its information comes from APNIC, and the RIPE WHOIS rendering reproduces the APNIC record with aut-num 59004, as-name TNCNT, the company description, country CN, named administrative and technical contacts, a CNNIC maintainer and the last-modified timestamp of 16 June 2021.

The dates matter, but only for what they actually date. The 2016 event is the registration of the number record. The 2021 event is the last recorded change to that resource information. Neither is a launch date for cloud service, a commissioning certificate for a rack, a customer contract date or proof that operations continued without interruption. A registration can remain durable while the technical and commercial system around it changes completely.

The contact address in the public record is at Songshan Road in Tianjin's Nankai District. That establishes a location stated for administration of the resource. It should not be promoted into a server location. An office can receive correspondence and coordinate a network while all equipment sits in a third-party facility. A registered address may also outlive the operating arrangement it once represented. No public evidence reviewed here identifies a data hall, room, cage, rack, power allocation, cross-connect or carrier entrance at that address.

The same restraint applies to the country code. CN is appropriate for the resource registration and for the company's public identity. It is not a measurement of where packets terminate, where customer data rests or which cities can order service. Internet-number country fields are administrative attributes, not precision geolocation. Even if AS59004 announced a prefix, network engineering could still place hosts elsewhere, use remote transit, tunnel traffic or front an origin through a separate delivery network.

The ASN is thus strong evidence of a historic administrative decision: someone obtained and maintained a public routing identity for TNCNT. It is weak evidence of current production capacity. Treating those as equivalent would confuse permission and identity with operation, which is precisely the error the live BGP results prevent.

Three empty measurements define the current edge

The current routing result is not a single blank chart. It is a set of mutually reinforcing zeroes across prefix origination, collector visibility and autonomous-system adjacency.

First, RIPE's announced-prefixes response returns an empty prefix list. There is no IPv4 block and no IPv6 block currently attributed to AS59004 as origin. That means the number is not supplying a publicly observed origin route for customer addresses, management endpoints, storage gateways or any other internet-reachable address space under its own routing policy.

Second, the routing-status response reports zero announced IPv4 prefixes and zero IPv4 addresses, as well as zero IPv6 prefixes and zero IPv6 /48 equivalents. None of 327 IPv4 full-table RIS peers and none of 322 IPv6 full-table RIS peers sees the resource. The fields that would identify when it was first or last observed are empty. RIPE's documentation for that response defines visibility as the number of full-table RIS peers seeing the resource compared with the total, and describes announced space as the address space currently announced by the ASN. On those definitions, AS59004 has no visible public footprint at the cut-off.

Third, the ASN-neighbours result reports zero left-side, right-side, unique and uncertain neighbours. No adjacent autonomous system is observed carrying a path that contains AS59004. The aligned routing-consistency response also contains no prefixes, imports or exports. Unlike an inactive route object or an old policy statement, there is not even a registered relationship in that response to mistake for a live session.

CAIDA supplies an independent structural reading. Its AS Rank result for AS59004 identifies TNCNT in China but marks it not seen. Provider, peer and customer degree are all zero. The cone contains zero prefixes and zero addresses. Its count of one ASN in the AS cone is only the queried ASN itself, so it cannot be read as a customer or affiliate network.

Together, those measurements support a firm present-tense conclusion: AS59004 is not an observable public BGP edge. They do not merely say that traffic is low. A lightly used ASN can still announce a prefix and appear to collectors. Here the address origination, peer visibility and path adjacency needed to define a public network are all absent.

An observation boundary is not a claim of corporate extinction

Negative evidence needs exact language. RIPE RIS learns routes through a distributed set of BGP peers and collectors. Its route-collector documentation explains that some collectors sit on internet-exchange peering networks while multi-hop collectors receive data from peers in many locations. This gives broad visibility, but not omniscience. Private BGP sessions, internal routes, isolated enterprise networks and sufficiently narrow announcements may not enter the public view.

RIPE also applies a default minimum-visibility threshold to the routing-status result. A route seen by fewer than the default number of full-table peers can be excluded. That caveat matters when making an absolute historical statement. It does not make a hidden public cloud edge likely; it simply sets the boundary of the measurement. The correct formulation is that no current route is visible at the documented threshold and observation point.

The RIPE routing-history result for AS59004 returns no origin entries for the requested period at its default minimum of ten full-feed peers. That does not prove the ASN has never appeared anywhere. It shows that this historical view does not establish a broadly visible route. A brief, private, leaked, narrowly propagated or otherwise unobserved announcement could escape that result.

More importantly, a company can conduct digital business without originating an ASN. It could buy virtual machines from another provider, colocate behind provider-assigned addresses, resell a third party's cloud, deliver software, manage private networks or retain only dormant corporate functions. In each case, customer traffic would appear under somebody else's ASN, if it appeared publicly at all. The empty route therefore cannot prove that Tianjin new cloud network technology co., LTD has ceased every activity.

It does establish a burden of proof for any claim tied to AS59004. No current public endpoint, prefix, upstream or service can be attributed to that ASN. Anyone asserting live TNCNT network capacity needs evidence from another layer: a current contract, endpoint, facility statement, customer route, status record or independently repeatable service test. The registered number alone cannot carry that claim.

“Cloud” requires a system, not a suffix

Cloud service is sometimes spoken of as if it floats free of physical constraints. The standard definition is more demanding. NIST's definition of cloud computing describes on-demand network access to a shared pool of configurable resources and identifies on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service as essential characteristics.

Each characteristic implies operating evidence. On-demand provisioning requires an ordering and control path. Broad network access requires reachable endpoints. Resource pooling requires compute, memory, storage and network capacity assigned among users. Elasticity requires spare capacity or an upstream arrangement that can supply it. Measured service requires monitoring and billing records. An ASN registration supplies none of those things by itself.

China's official description of internet data centre business makes the physical and contractual chain explicit. It describes facilities used to place customer servers and other network equipment, outsourced maintenance, system configuration and management, leased servers and storage, and the agency leasing of communications lines and internet bandwidth. This is a useful test for the company name because it identifies the assets and obligations that must exist somewhere even when the customer sees only a web console.

No reviewed evidence shows that Tianjin new cloud network technology co., LTD currently offers any of those services. There is no verified product page, price, service description, control endpoint, customer guide, status page, support commitment or location list. There is no evidence of a licence scope, although absence from the reviewed material is not evidence that no licence exists. The MIIT notice on IDC and ISP market access confirms that operating permissions and application materials are part of the market-access framework; it does not identify this company as licensed or unlicensed.

The conservative conclusion is not that the company falsely used the word cloud. It is that the word cannot answer an operational question. A cloud name without public service evidence is a lead for verification, not proof of a platform.

No verified rack sits behind the number

Every cloud workload eventually reaches a finite machine. Even a reseller depends on someone else's servers, storage, switches, electricity, cooling and repair staff. For AS59004, the location and ownership of every such asset remain unverified.

The public address in Tianjin is not enough. It could be an office, a historic contact point or a site that once coordinated network resources. The record does not call it a data centre. It provides no facility operator, building specification, security boundary, utility feed, generator, battery system, cooling arrangement, fire-suppression design, floor loading, flood exposure or access procedure. Converting the address into a picture of an operating machine room would add facts that the evidence does not contain.

The ownership boundary is equally open. The company could, in principle, own servers and lease rack space; lease servers from a hosting company; resell virtual capacity; manage customer-owned equipment; or provide non-hosting technical services. Each arrangement allocates risk differently. A server owner bears inventory and replacement risk. A rack tenant depends on the landlord for power, cooling, physical access and often carrier cross-connects. A reseller adds another contract between customer and hardware operator. A managed-service supplier may control software while having no right to enter the facility.

Those distinctions determine who can repair an outage. If a disk fails, can TNCNT replace it directly, or must it open a remote-hands ticket? If a power feed trips, does the company receive facility telemetry? If a transit port is suspended, who holds the carrier contract? If customer data must be exported, does TNCNT control the storage layer or merely the account above it? The ASN record answers none of these questions.

The Chinese national standard entry for GB/T 44463-2024 identifies technical requirements for internet data centres. Its existence helps define the category of facility evidence a buyer should seek, but it cannot be used as proof that a particular company operates a compliant site. A standard and an operating asset are different layers, just as an ASN assignment and a live route are different layers.

Until a facility, contract or endpoint is verified, the physical asset behind this profile is not a known rack. It is an unanswered dependency.

A route needs both policy and machinery

BGP is the mechanism by which autonomous systems exchange reachability. RFC 4271 defines that exchange and the path information used to select routes. A working public origin for AS59004 would therefore require more than possession of the number. It would require address space, routers, configured sessions, accepted announcements and propagation through one or more other networks.

The current record exposes none of that operating chain. There is no announced prefix to originate. There is no observed neighbour to carry it. There is no visible import or export relationship in RIPE's consistency response. The PeeringDB search for AS59004 does not provide a verified facility, exchange or interconnection profile, and the network API returns no entity. PeeringDB is voluntary, so that absence cannot prove the lack of private transit. It does mean that a buyer cannot use that directory to confirm exchange presence, public peering policy, traffic levels or facility locations.

Even a future appearance of two upstream ASNs would not automatically prove resilience. Logical diversity can share a physical failure point: one router, one line card, one rack power strip, one cross-connect tray, one building entrance or one wholesale backbone. Two BGP sessions can also be purchased through the same reseller and suspended under the same contract. Real diversity requires separate paths whose common dependencies are understood.

RFC 7454 on BGP operations and security describes filtering, session protection, maximum-prefix handling and other controls that make routing safer. These practices become relevant only after the basic path exists. Route-origin authorisation has a similarly bounded role. RFC 6811 explains prefix-origin validation, but an authorisation cannot power a router, create a prefix announcement or restore a failed fibre.

For TNCNT, the immediate redundancy question is therefore not “how many carriers?” but “is there a live carrier path at all?” The next questions concern where it terminates, who contracts for it, whether it is physically independent and how failover is tested. Public evidence currently stops before the first answer.

Installed capacity would still not equal usable capacity

Suppose a future document showed a room of servers in Tianjin. That would improve the physical evidence but would not settle the service question. Capacity moves through several states, and only the last ones matter to customers.

Design capacity is what a proposed site could support under stated assumptions. Built capacity is floor, power and cooling that has been constructed. Commissioned capacity has passed defined readiness tests. Installed capacity includes equipment placed in racks. Available capacity deducts failed units, maintenance reserves and committed inventory. Sellable capacity adds software, licensing, network access and a commercial offer. Usable capacity is what a customer can provision and rely on now. Recoverable capacity is what remains, or can be restored, after a meaningful failure.

An ASN contains no information about any rung on that ladder. Prefix count would not be a capacity measure either. A single IPv4 prefix can front a large service, and a large IPv6 allocation can remain empty. Routing establishes reachability, not processor count, storage durability, port speed or spare inventory. Yet zero routing under the company's own ASN removes even that first observable link to a public customer plane.

Hosting economics sharpen the distinction. Servers depreciate whether busy or idle. Spare disks, memory modules, power supplies and switches tie up cash. Rack leases and minimum transit commitments can continue while utilisation falls. Support coverage costs money even when no ticket arrives. A small supplier can reduce fixed cost by relying on a wholesaler, but then its margins and recovery speed depend on that contract. None of these economics can be calculated for TNCNT because there is no verified inventory, price, customer count, facility agreement or upstream commitment.

The national context does not fill the gap. The technical requirements and market-access rules for Chinese IDC operations describe a serious infrastructure category, but they do not show that a named company has commissioned or sold capacity. Likewise, an image of equipment, if one emerged, would need a date, location, ownership explanation and evidence that customers could actually reach and provision it.

A defensible capacity claim for this company would need specific numbers with specific meanings: installed hosts, available cores, usable storage after replication, contracted transit, oversubscription policy, occupied versus free rack power, hardware replacement stock and the date of measurement. At present, the only precise capacity number linked to AS59004 is zero announced address space.

Tianjin is a registration location, not a proved service region

Tianjin matters because it appears in the company name, description and contact address. It is reasonable to describe the resource holder as Tianjin-associated and the ASN as registered in China. It is not reasonable to infer a Tianjin data centre or nationwide Chinese coverage from those fields.

Cloud service areas are defined by operational facts: where workloads execute, where data is stored and backed up, where network traffic enters, what latency users experience, which legal entity signs the contract, which currency and tax rules apply, and when support is available. A company can sell nationally from one facility, sell locally from several facilities, or resell a remote platform without owning any local machine. None of these patterns is established here.

The routing absence makes geographical inference even harder. With an active prefix, latency measurements, reverse DNS, interconnection records and path observations can sometimes narrow a likely operating region, though none is conclusive alone. AS59004 supplies no prefix to test and no neighbour path to trace. There is no public endpoint that can be responsibly designated as a TNCNT cloud service and measured from multiple cities.

The region value CN should therefore remain an administrative and market-context label. It tells readers which internet-number system and regulatory environment are relevant. It does not promise mainland hosting, Tianjin latency, Chinese-language support, domestic payment, local data residence or access from every Chinese carrier.

For customers, this boundary is practical. A procurement requirement for “China-hosted” infrastructure should be translated into named facilities, contract clauses, backup locations and network tests. Accepting a company address or ASN country code as a substitute would leave the actual location of workload and data unresolved.

Data locality cannot be inferred when the data path is unknown

The controlled topic of data sovereignty is supported here by uncertainty, not by a claim of compliance or violation. A cloud buyer needs to know where data is collected, processed, stored, replicated, backed up and accessed. None of those locations can be derived from AS59004.

China's Personal Information Protection Law governs personal-information processing and includes a dedicated chapter on cross-border provision. The law's cross-border provisions include information, consent and protection obligations when personal information is provided outside China. These rules make the location and identity of processors important, but they do not show that TNCNT processes personal information or moves it across a border.

The correct diligence questions begin with a data-flow map. Which entity receives customer data? Does it act as a processor, controller or infrastructure subcontractor? What facility stores the primary copy? Where are snapshots and disaster-recovery copies? Can support personnel outside the primary jurisdiction access them? Does the service use a foreign control plane, telemetry platform or ticketing system? What happens to residual copies after termination?

Those questions cannot be answered by saying that the ASN is Chinese. Traffic could run entirely inside another Chinese operator, through a foreign-owned platform operating under a local arrangement, or through a service hosted outside the country. Data could also remain private and never touch AS59004. Conversely, a future active TNCNT route would not prove data residence, because routing origin and storage location are not the same thing.

The MIIT notice on IDC customer-data security underscores that data-centre operators hold large volumes of customer data and have security responsibilities. It supplies useful sector context, not company-specific assurance. No reviewed material provides TNCNT retention terms, encryption controls, subprocessor list, deletion procedure, incident history or audit report.

Data-sovereignty confidence therefore remains low for a simple reason: the operating and contracting surface is unknown. The absence of a live ASN route is not itself a data-protection failure, but it prevents the network identity from helping resolve where a claimed service actually runs.

The failure path begins before packets move

A customer-facing cloud service can fail at several layers that are often collapsed into the word “outage.” For TNCNT, the public evidence does not establish that these layers are active, but mapping them shows what any operating claim would have to withstand.

The first layer is commercial. A facility lease can expire, a carrier account can be suspended, an equipment supplier can stop extending credit or a billing system can fail to recognise payment. A reseller can lose access to the wholesale account on which every customer instance depends. These failures can remove service even when every server remains technically healthy. Evidence of legal identity and an ASN does not reveal the contracts or their termination rights.

The second layer is facility infrastructure. Utility loss, battery exhaustion, generator failure, cooling loss, water ingress, fire response or denied physical access can take a rack offline. A claim of dual power is incomplete unless the paths are independent from utility entrance through transfer switch, UPS, distribution and server power supplies. A claimed second site is not a recovery site unless it has current data, enough capacity and a network path customers can use.

The third layer is hardware. Drives fail, memory corrupts, power supplies age, fans stop and replacement stock runs out. A small operation may have only one spare host or rely on a supplier's delivery window. Hardware can be installed yet unusable because firmware, licence keys or orchestration state are missing. An inventory sheet must therefore distinguish installed, healthy, reserved and actually available equipment.

The fourth layer is network reachability. A router can lose power, a cross-connect can be unplugged, a transit port can be filtered or a route can be rejected. A prefix can be announced but poorly propagated. DNS can remain live while the service behind it disappears. AS59004 currently sits before this layer in public observation: there is no announced route to test for performance or failover.

The fifth layer is software and storage consistency. A control plane can fail while virtual machines keep running, or running instances can vanish while a portal still accepts commands. Replication can silently lag. Backups can exist but fail restoration because credentials, encryption keys or application dependencies are missing. A recovery claim is meaningful only after a dated restore has produced a working service.

The final layer is human response. Someone must receive an alert, diagnose the responsible party, authorise access, replace equipment, communicate with customers and keep billing from worsening the incident. A phone number in a resource registration is not a support commitment. No public evidence specifies TNCNT coverage hours, escalation tiers, response targets or the person responsible for customer restoration.

Who would be affected remains unknown

No public customer list, service endpoint or product inventory supports a count of affected users. That uncertainty must remain visible. It would be wrong to invent a customer population simply because an ASN exists or a company name includes cloud.

If the company operates no current customer service, withdrawal of AS59004 may affect nobody outside the resource holder. If it resells capacity inside another network, customers could be active while the ASN remains absent. Their failure exposure would then follow the upstream platform, account and support arrangement rather than AS59004. If it runs private enterprise systems, affected users might be employees or contracted clients whose traffic is never visible globally.

Different customers would also experience the same technical break differently. A static website might tolerate several hours if DNS can move quickly. A stateful service with local writes cannot be restored safely from an old snapshot without accepting data loss. A regulated workload may be unable to fail over across a border. A customer that holds current backups and automation can migrate; one whose only copy sits in a provider-controlled volume may be trapped by an inaccessible control plane.

This is why customer impact cannot be inferred from route metrics alone. Zero visibility says that AS59004 is not currently a public path. It says nothing about how many workloads may depend on contracts or systems under other ASNs. Conversely, a future visible prefix would not reveal tenant count or workload criticality.

The useful conclusion is procedural for a buyer but factual about the company: exposure cannot be sized from public evidence. Any prospective customer should demand a named service boundary and identify every upstream on which it relies. Any current customer should test whether it can retrieve data and rebuild elsewhere without the supplier's portal. Those tests matter more than the reassuring sound of the company name.

Recovery requires proof across routes, machines and contracts

Resilience is not a list of components; it is the demonstrated ability to recover a service within an agreed time and data-loss limit. For a small or opaque cloud supplier, four demonstrations are especially important.

First is route recovery. The provider should show the prefixes used for customer service, the originating ASN, the contracted upstreams and a dated failover result. The test should distinguish a BGP session changing state from users actually regaining reachability. It should also identify shared fibre, router, facility and account dependencies. AS59004 cannot currently supply such evidence because it has no visible prefix or neighbour.

Second is compute and storage recovery. A customer should see a workload restored onto a different healthy host, with disks, network identity, secrets and monitoring intact. A backup report is not enough; the restored application must start and its data must pass a consistency check. The result should state recovery time and the age of the restored data.

Third is site recovery. A second site must be geographically and operationally separate enough to survive the relevant hazard. It needs reserved capacity, replicated data, independent access and a way to receive traffic. Two racks in one room are not multi-site resilience. Two facilities on one carrier contract or one power corridor may still share a decisive failure point. No public statement identifies even one TNCNT site, so no multi-site claim can be evaluated.

Fourth is commercial recovery. Customers need contacts who can act during a billing dispute, ownership change, facility lockout or supplier failure. Contracts should address data retrieval, termination assistance, export format, deletion timing and access to backups. A technical copy is not portable if it depends on proprietary images, unavailable keys or a closed virtual-network design.

The strongest recovery evidence would join all four layers in one exercise: withdraw a path or isolate a site, restore the workload elsewhere, re-establish customer reachability, verify data integrity and record who authorised each step. Until such evidence exists, redundancy remains an architectural possibility rather than an operating fact.

Portability is the customer's last redundancy layer

When provider capacity and support are uncertain, the customer's ability to leave becomes part of system reliability. Portability does not eliminate an outage, but it can prevent the outage from becoming indefinite.

A credible exit path includes current exports of data, machine definitions, network policy, encryption keys under customer control, dependency inventories and instructions for rebuilding on another platform. Backups should be stored outside the same failure and account boundary. The customer should know how long a full export takes, what egress costs apply, what formats are used and whether a suspended account blocks retrieval.

Network portability is also limited. Provider-assigned addresses usually cannot move with a workload. DNS changes have caching delays, certificates and allowlists may bind services to old endpoints, and counterparties may permit only known source ranges. A customer using its own portable address space still needs a new provider willing and able to announce it. None of these arrangements can be inferred for TNCNT because no customer prefix or service network is visible.

Data locality can constrain the exit. A workload subject to Chinese rules or contractually required to remain in a named region may not be transferable to the first available foreign platform. The destination needs suitable legal, security and operational terms. The customer must also know whether backup copies or support access cross a jurisdictional boundary during migration.

The practical test is a rehearsal. Export a representative workload, import it into an independent environment, start it without the original control plane, redirect a test hostname and compare application data. Record the time, manual steps and missing dependencies. If that cannot be done while service is healthy, it will be much harder during a contract or infrastructure failure.

For this company, portability evidence would be more informative than another administrative record. It would show that an actual service exists, that customer assets can be identified and that the operating boundary is understood. No such public evidence is available.

Commercial indexes are signals, not substitutes

Several public routing indexes expose a page for AS59004. Cloudflare Radar identifies the ASN and holder in its routing surface. Hurricane Electric's BGP view, BGPView and IPinfo offer third-party or commercial views that can be useful for a quick cross-check. None reveals a current prefix or relationship that overturns the RIPE and CAIDA result.

These pages should be treated cautiously. They can refresh on different schedules, draw from overlapping collectors, classify networks differently or show a holder name even when no route exists. An empty section can mean no data, no current route or a temporary rendering issue. Their value here is corroborative: the wider public indexes do not expose a live footprint that the primary measurements missed.

The same caution applies to the missing PeeringDB network entity. PeeringDB participation is voluntary, and private transit customers often have no public profile. Absence cannot prove that a carrier contract, cross-connect or facility relationship does not exist. It simply leaves those details unverified.

Unofficial signals would become more useful if they pointed to a testable asset: a dated service page, a customer hostname, a facility listing or a route observed by a collector. A stale company listing, copied WHOIS text or search result that repeats TNCNT adds no operating evidence because it derives from the same registration layer.

The hierarchy of evidence is therefore clear. The APNIC-derived registration establishes identity. RIPE and CAIDA establish the present lack of public routing observation. Commercial indexes can corroborate that reading. Only direct service, facility, route and customer evidence could establish an operating cloud platform.

What would change the conclusion

The finding is falsifiable. It does not depend on interpreting every absence as permanent. Several concrete developments would materially strengthen the case for current operation.

The first would be a stable prefix originated by AS59004 and visible to a meaningful set of independent collectors. The announcement should persist long enough to distinguish production from a leak or test. Observed neighbours, route-origin authorisation and consistent registry policy would add confidence. A reachable service endpoint on that prefix would connect the network layer to a customer-facing function.

The second would be a current company-controlled service description with orderable products, prices or a sales path, contractual identity, support terms and named service locations. A licence reference could clarify the authorised operating scope, but would still need to be connected to the exact legal entity and current service. A permit can enable activity without proving utilisation.

The third would be facility evidence: a named operator, site address, rack or cage boundary, power allocation, carrier handoffs and a clear statement of which assets the company owns or leases. Dated photographs can support this only when provenance and location are credible; generic server images do not.

The fourth would be operational proof: a status history, latency or looking-glass endpoint, documented incident response, restore-test result, support escalation and a customer export procedure. These materials would reveal whether installed equipment has become usable and recoverable service.

The fifth would be independent customer evidence detailed enough to identify a service without exposing confidential information. A public endpoint, case study, tender, procurement award or verifiable route could show that somebody relies on the platform. Reviews and copied listings alone would remain weak because they can persist after service changes.

Any of these could move the profile beyond the present negative network grade. Until then, the burden does not shift to the reader to imagine hidden capacity. It remains with the claimant to show what is running, where it runs and how it survives failure.

The operational verdict is negative, not absolute

AS59004 is a valid and specific piece of internet infrastructure administration. It ties TNCNT and Tianjin new cloud network technology co., LTD to a Chinese autonomous-system number, with a registration event in 2016 and a last recorded change in 2021. That identity should not be dismissed.

But the current operating evidence is negative. RIPE finds no announced prefix, no IPv4 or IPv6 visibility, no address space, no neighbour and no registered routing relationships in its consistency view. CAIDA marks the ASN unseen and gives it no prefix cone, address cone or external degree. Voluntary and commercial indexes reveal no contrary live footprint.

The absence has a precise meaning: the company cannot presently be verified as operating a public network through AS59004. It leaves open private activity, resale, hosting inside another provider and corporate survival. It also leaves open the possibility that a route could appear later.

For a cloud buyer, however, those possibilities are not service assurance. The missing evidence spans the entire delivery chain: no verified rack or site, no active route, no hardware inventory, no transit diversity, no power design, no support commitment, no restore result, no billing continuity and no data-portability path. The company name points toward cloud and network capability. The observable network does not yet prove either one.