Chongqing Cloud Computing Investment&Operation Co.,Ltd leaves its

Summary

AS59002 is registered in China under the name CQLJNET and the description Chongqing Cloud Computing Investment&Operation Co.,Ltd. Its RDAP record carries a registration event dated 4 April 2016 and an autonomous-system record change dated 28 November 2023.
The current public routing evidence is negative: RIPEstat reported zero announced prefixes, zero IPv4 and IPv6 address space, visibility from zero collectors, and no observed neighbours. CAIDA's AS Rank record also marked AS59002 as unseen, with a prefix cone of zero and network degree of zero.
Those zeros show that AS59002 was not presenting a public BGP origin in the observed global table. They do not prove that the company is inactive, owns no servers, or serves no customers, because a cloud product could use provider-assigned addresses, reverse proxies, a parent network or another ASN.
A live infrastructure claim would require a mapped chain of evidence: current service endpoints and IP addresses, their route origins, named production and recovery sites, facility and transit contracts, power and hardware capacity, operational support, recent restore results and a tested data-export path.
The public network evidence grade is Negative for a current AS59002 operating footprint, not for the company's legal existence or every possible service delivered under its name.

The missing route is the central fact

The word cloud invites a picture of elastic capacity detached from place. The network record for Chongqing Cloud Computing Investment&Operation Co.,Ltd invites the opposite discipline. It gives the company a precise number, AS59002, but the number currently leads to no announced prefix. A customer trying to use the global routing table to locate this cloud would arrive at an empty edge.

That is a meaningful result. An autonomous system becomes publicly useful when it originates address space or exchanges routes in a way that collectors can observe. The RIPEstat announced-prefixes view returned no current prefix for AS59002. The corresponding routing-status view showed zero IPv4 prefixes and addresses, zero IPv6 prefixes and /48 equivalents, and no visibility from the hundreds of IPv4 and IPv6 RIS peers reported in that response. The neighbour view returned no observed adjacent network.

These are not small values that need interpretation as a modest footprint. They are zeros across the principal public indicators of a currently originated autonomous-system edge. There was no prefix on which to test route-origin authorization, no visible path from which to identify an upstream, and no advertised address pool to associate with customer endpoints.

The narrow conclusion is therefore strong: on the observation date, AS59002 did not provide publicly visible BGP evidence of a live cloud network. The broader conclusion must remain open. Cloud services can sit behind another network's ASN, addresses and transit. A company can also retain an ASN after migrating a service, outsourcing delivery, changing products or pausing operation. BGP can identify a live origin; its absence alone cannot identify which of those explanations is correct.

AS59002 proves identity, not operation

The RDAP autonomous-system record connects AS59002 to CQLJNET, China and the company name used here. It records a registration event on 4 April 2016 and a last-changed event for the autonomous-system entity on 28 November 2023. The RIPEstat Whois representation shows the same CQLJNET name, the same company description, country code CN, APNIC as the source authority and maintenance through CNNIC.

That is valuable identity evidence. It shows that the name is not merely a phrase copied from an unverified business listing. It also locates the number resource in the APNIC/CNNIC registration system. The registration date, however, is not a launch date, and the 2023 change is not proof that routers or cloud servers were active then. Registry maintenance can concern contacts or records without producing any traffic.

An ASN is an administrative identifier for routing policy. It is not a business licence, a data-centre certificate, a server inventory or a customer contract. It says that a number was associated with an organisation in the resource registry. It does not say which products the organisation now sells, whether it uses the number, or whether a service advertised under the company's name runs on infrastructure it owns.

This distinction protects against two opposite mistakes. The first is to treat a registered number as evidence of current cloud capacity. The second is to treat a silent number as evidence that no company or service can exist. The right reading is more exact: AS59002 establishes a durable identity clue, while its current lack of routes removes one potential proof of operation. Anyone asserting a live service must bridge that gap with other current evidence.

Three independent views point to zero

Public routing research is strongest when different systems agree, because any one collector or aggregator can be incomplete. Here the direction is consistent. RIPEstat found no announced space, no collector visibility and no neighbours. The CAIDA AS Rank record labelled AS59002 seen: false; its cone contained zero prefixes and zero addresses, while its total, provider, peer and customer degrees were all zero. IPinfo's AS59002 page classified the network as inactive and listed zero IPv4 addresses, zero IPv6 addresses, zero hosted domains and no peers.

Other public reference points make the same question inspectable. Cloudflare Radar's routing page, BGP.tools, the Hurricane Electric BGP Toolkit and BGPView provide independent places to look for prefixes, path data and connectivity. Their usefulness is not that each carries equal authority. It is that a claimed live origin should normally leave more than one observable trace.

Agreement among these public systems does not turn absence into universal proof. Route collectors do not see private BGP sessions, internal networks or services hidden behind an upstream's address space. Aggregators can refresh at different times. A very short announcement might be missed by some views. Yet those caveats do not produce a positive route. They merely define the boundary of the negative finding.

The burden of proof should therefore move to the live service claim. If a product is operating, its provider can identify an endpoint, demonstrate which ASN originates the address, explain why AS59002 is not used, and show the production path. Until that mapping exists, the cloud label and the BGP identity remain disconnected.

A cloud can exist without its own ASN

There are several ordinary ways for a real hosted service to leave no current route under its own autonomous-system number. A provider may announce customer endpoints from an upstream carrier's ASN. It may rent virtual machines or bare metal from a larger cloud and use addresses assigned by that supplier. It may publish applications behind a content-delivery network, reverse proxy or distributed denial-of-service protection service. It may operate an internal private cloud whose users reach it over dedicated links, virtual private networks or an enterprise WAN rather than the public internet.

Each architecture is possible for Chongqing Cloud Computing Investment&Operation Co.,Ltd, but none is proven by the registered ASN. They also produce different dependencies. A provider-originated route makes the company directly visible in BGP and gives it some control over routing policy. An upstream-originated service transfers more control to the carrier. A hyperscale or CDN front end may add reach and protection while concentrating identity, billing and incident response in another supplier. A private service can be operationally important even when the public table sees nothing.

This is why the first verification request should not be, "Is AS59002 active?" It should be, "Which exact endpoints deliver the service now?" Those endpoints can then be resolved to IP addresses, prefixes and origin ASNs. A customer can compare the result with RIPEstat's AS overview, APNIC's Whois search and the operator's architecture statement.

If another ASN carries the service, the provider should name the network, state whether the arrangement is transit, hosting, resale or managed infrastructure, and explain which party can change routes during an incident. That would be positive evidence of a live delivery model. It would not reactivate AS59002, but it would explain why the company's cloud role is invisible under that number.

The name does not locate a data centre

The registry's country code is CN, and its public contact material points to Chongqing. Those facts support a geographic association for the number-resource record. They do not locate a production rack, a recovery copy or a customer dataset. A company name containing Chongqing can still use facilities elsewhere; a Chinese ASN can carry traffic to infrastructure in several jurisdictions; and a service can place compute, backups, logs and support systems in different locations.

For this company, no facility footprint is established by AS59002's current BGP record. The PeeringDB API endpoint did not yield a usable network profile on 11 July 2026, so there is no operator-maintained facility or exchange list to evaluate from that source. The PeeringDB search remains a useful place to watch for a later profile, but a search result would still be self-reported interconnection data rather than proof that customer workloads occupy a named site.

Location must be proven as a chain. The provider should identify the legal contracting entity, production facility, recovery facility, backup location and support-access locations. It should disclose whether the space is owned, leased wholesale, colocated by rack or consumed as a service from another cloud. It should then map which datasets exist in each place and which supplier can access them.

This chain matters for data sovereignty and for recovery. A customer cannot assess local storage, cross-border movement, government access, deletion or export merely from CN in an ASN record. Nor can it estimate outage risk from the city in the corporate name. The useful evidence is the actual placement schedule and the contracts that bind each facility and supplier.

Ownership and operation may be split

Cloud infrastructure often has several owners at once. The provider may own server hardware but rent rack space. The building operator may control power and physical entry. A carrier may own the fibre. Another company may provide remote hands. A software vendor may control the virtualisation platform, while a backup supplier stores recovery copies. The customer sees one service, but restoration depends on every boundary.

Nothing in the AS59002 record resolves those boundaries. The RIPEstat routing-consistency response showed no prefixes, imports or exports to compare. The RADb query can be used to look for routing-policy entities, but an Internet Routing Registry entry, if one appears, is a policy artifact rather than a facility contract. The empty public routing surface therefore offers no basis for assigning physical or commercial responsibility.

A credible operating description would name the layer and owner together. For example: who owns the edge routers; who holds the transit contracts; who controls the racks; who supplies power; who stocks servers and optics; who administers storage; who receives alerts; and who is authorised to approve an emergency change. It should also identify which service obligations are passed through from suppliers and which are promised directly by the company.

The split matters most during failure. If the provider can diagnose a power fault but cannot enter the data hall, recovery depends on the facility's queue. If it can restore a virtual machine but cannot increase upstream capacity, a network incident remains outside its control. An uptime figure that does not disclose these operating boundaries says little about the path from alarm to repair.

Installed capacity is not usable capacity

Even positive evidence of servers, ports or rack space would not settle the capacity question. Installed capacity counts what has been purchased or placed. Usable capacity counts what can serve customers under ordinary constraints. Recoverable capacity counts what remains, or can be restored, after the tested failure. Those numbers diverge once maintenance, power limits, storage replication, network oversubscription and spare inventory are included.

AS59002 currently contributes no public measure of installed network capacity because it announces no address space. It contributes even less information about compute and storage. A photograph of racks, a procurement announcement or a stated design capacity would still need to be tied to powered hardware, available ports, deployed software and current customer allocation.

For a cloud provider, the meaningful capacity schedule should cover compute cores and memory, storage tiers and replica count, backup throughput, edge and aggregation bandwidth, transit commits, cross-connect capacity, power draw, cooling margin and support staffing. It should distinguish gross inventory from capacity reserved for failure. It should also state whether the recovery site can carry the whole service or only a priority subset.

Customers need numbers under stress. What utilization remains after one power train, router, upstream or storage node is removed? How many machines can be rebuilt from local spares? How quickly can backup data be read when many tenants restore at once? Can the surviving transit path carry the peak hour without severe loss? Those answers would prove usable infrastructure far more clearly than the continued existence of an autonomous-system registration.

Transit diversity starts with a visible origin

The current ASN-neighbours response contains no neighbours for AS59002. That is exactly what one would expect when there are no visible announcements: without a route path, collectors have no adjacent AS to identify. It means there is no public basis for claiming even one current BGP upstream under this ASN, let alone diverse upstreams.

If the company activates AS59002, the first positive evidence would be one or more prefixes seen by independent collectors. A path should then show which networks carry the announcement. Over time, stable observations could identify whether more than one upstream is present. The operator could strengthen that evidence with current looking-glass output, router configurations with sensitive fields removed, circuit references and invoices or letters from the carriers.

Logical diversity would still be only the first test. Two BGP sessions can terminate on the same router, use the same cross-connect corridor, leave a building through the same duct or depend on one metro fibre. Two carriers can also share a wholesale path. Physical route diagrams, meet-me-room locations, diverse building entrances and tested failover results are needed to show that a single cut or facility event will not remove both paths.

Capacity matters too. A backup circuit that accepts routes but cannot carry the production load is not a recovery path. The provider should demonstrate failover during a representative busy period, measure loss and latency, and state which traffic is shed if the remaining capacity is limited public evidence. The empty AS59002 route table makes these requests more urgent because none of the claimed diversity, if any exists, can currently be corroborated from BGP.

Routing security cannot be scored without a route

Route-origin validation asks whether an ASN is authorised to originate a particular prefix. With no current AS59002 prefix, there is no active origin pair to validate. That is not the same as an invalid route; it is an absence of a route. It would be misleading to award or deduct routing-security credit as if a live prefix had failed validation.

If AS59002 begins announcing space, a customer should identify each prefix and test its Route Origin Authorisation. APNIC's resource certification material explains the regional system, while RFC 6811 describes BGP prefix-origin validation. A valid result would show that the registered address holder authorised AS59002 to originate the prefix within the permitted maximum length.

That control matters, but its scope is narrow. RPKI origin validation does not prove the route follows a physically diverse path, that traffic reaches healthy servers, or that the company can recover customer data. It does not prevent every route leak or bad traffic-engineering decision. It also does not establish ownership of the cloud service carried over the route.

The same caution applies to Internet Routing Registry material. Policy entities can help networks build filters, and RFC 7454 describes good BGP operational practices. Yet a well-formed policy entity without observed announcements is not a live network. The strongest future picture would combine current routes, valid origin authorisations, maintained routing-policy records, diverse paths and demonstrated operations.

Racks, power and cooling are still the cloud

Suppose the company demonstrates live endpoints on another ASN. The investigation then moves from the route to the room. Every virtual machine ultimately occupies processors and memory powered in a facility. Every storage promise depends on drives, controllers, network fabrics, replication and operators. Every control panel depends on identity systems, databases and management connectivity that can fail separately from customer workloads.

The physical proof should begin with named facilities and the provider's exact occupancy model. Does it control a whole data hall, cages, individual racks or only virtual capacity purchased from another operator? Which power feeds reach each rack? Are the feeds genuinely independent upstream of the power distribution unit? What generator runtime and fuel arrangements apply? Which cooling failure can isolate the same equipment served by supposedly diverse power?

Answers should distinguish design from operation. A facility may be designed for redundant power while a particular rack uses one feed. A provider may own dual-power servers while a network switch or storage shelf remains single-corded. Generators may exist while fuel replenishment, maintenance or switchgear creates a common failure. Public BGP cannot reveal any of this, and the silent AS59002 record should not be used to imply either strength or weakness at the facility layer.

The evidence that would settle the question is practical: recent power-path test reports, rack-level diagrams, capacity readings, maintenance records, incident summaries and a list of single points accepted by design. A provider does not need to publish sensitive schematics to the world. It does need to give affected customers enough verified information to understand what their service survives.

Hardware stock turns failure into a repair time

Cloud capacity can appear elastic while hardware replacement is stubbornly physical. A failed disk, power supply, top-of-rack switch, optical module or motherboard needs a compatible spare and someone authorised to install it. If the part is not on site, lead time becomes part of the outage. If replacement depends on a vendor contract, entitlement and logistics become infrastructure dependencies.

For Chongqing Cloud Computing Investment&Operation Co.,Ltd, the public number-resource record says nothing about server models, storage architecture or spare stock. A service could be modern and well maintained, or dependent on hardware that is difficult to replace. Neither conclusion can be drawn from AS59002. The company can resolve the uncertainty with an anonymised inventory policy, lifecycle schedule and evidence of local spares for critical components.

Customers should ask how the provider handles correlated failure. One spare drive is useful for one drive failure; it may be inadequate during a batch fault or storage rebuild. A spare switch does not help if configuration recovery is slow or the optics are missing. A replacement host does not restore service if the virtualisation licence, firmware or management credentials are unavailable.

The more revealing metric is time to restored customer capacity, not time to replace a component. That interval includes detection, diagnosis, authorisation, facility entry, physical work, configuration, data reconstruction, validation and return to service. A provider that can show measured times from recent exercises has live operating evidence. A cloud name and dormant ASN do not provide that assurance.

Support labour is part of the asset

Infrastructure fails at the speed of its escalation path. A technically redundant service can remain unavailable when alerts go to the wrong team, a support desk cannot reach a network engineer, or a supplier refuses a request from an unauthorised contact. Labour, permissions and communications are therefore part of usable capacity.

The public records for AS59002 include administrative and technical contact information, but a registry contact is not a round-the-clock operations centre. It does not disclose staffing levels, language coverage, escalation authority, on-site access or the relationship between customer support and engineering. The 2023 autonomous-system record change also cannot establish that the operational contact chain is current for a cloud product.

A serious service description should specify how customers report severity-one incidents, how quickly a qualified owner responds, who can alter routing, who can enter each facility, and how the company communicates when its normal portal or email is impaired. It should identify supplier escalation channels and the conditions under which a customer can contact a senior incident manager.

Support capacity should be tested during compound failure. A fibre cut may arrive during maintenance. A storage rebuild may coincide with a surge in customer tickets. A billing or identity fault may lock users out while engineers work on the underlying service. The provider's ability to triage these events without exhausting the same small group of people is a form of redundancy that no public routing table can display.

Billing and control-plane failure can look like an outage

A cloud service can remain physically healthy while becoming unusable through administrative failure. An account suspension, expired contract, failed payment, broken licence, inaccessible management console or lost privileged credential can prevent a customer from operating. These failures sit outside BGP, but they can be as final as a route withdrawal.

The absence of AS59002 announcements makes it particularly important to know which supplier controls the actual service edge. If another carrier or cloud platform supplies addresses, then account standing with that provider may determine reachability. A contract dispute or billing error at either layer could interrupt service even when servers and circuits are intact. Customers need to know whether their agreement gives them notice and remedy before an upstream dependency is terminated.

Control-plane independence should also be demonstrated. Can the provider reach routers, hypervisors and storage when the customer-facing network is down? Is the status page outside the affected estate? Are emergency credentials stored and tested? Can the company communicate through a separate channel if its domain, email or ticketing system is unavailable?

These questions are not peripheral to cloud economics. The customer pays the provider to absorb complexity, but the provider may in turn concentrate that complexity in credentials, contracts and consoles. Evidence of separate management paths, dual authorisation, account monitoring and tested emergency access would show an operating system around the infrastructure. AS59002's registry record alone cannot.

Data locality needs a map of every copy

Data sovereignty is relevant here precisely because the public evidence is too thin to establish locality. CN in the ASN record describes the resource's country association. It does not prove where primary customer data, replicas, backups, logs, support tickets, keys or monitoring records are stored. Nor does it show where administrators connect from or which subcontractors can access those systems.

A customer should require a data-location matrix for each service component. The matrix should identify the production location, synchronous and asynchronous replicas, backup sites, logging systems, disaster-recovery environment and support tooling. It should distinguish durable copies from transient caches and state how long each is retained. It should also state which legal entity and supplier controls each location.

This is not only a compliance concern. Placement determines recovery latency and correlated risk. Two copies in the same facility may survive a disk failure but not a building outage. Two regions dependent on the same management account may fail together administratively. A backup held far away may be durable but too slow to restore within the customer's business deadline.

The company could establish locality with contractual schedules, facility attestations, architecture diagrams and a demonstration that the service actually resolves to the declared infrastructure. Until then, the place name in the corporate identity and the country code in the number registry should not be converted into a claim about customer data.

Migration is the test of whether the dependency is reversible

Cloud economics exchange capital expenditure for a continuing supplier relationship. That can reduce cost and improve operations, but it also creates an exit problem. If the provider's network, facility, support or commercial position deteriorates, the customer needs data and configuration in a form another system can use. A backup that only the original platform can restore is not a complete exit path.

The silent AS59002 footprint sharpens this issue. If the service is delivered through another ASN or supplier, a customer may need cooperation from more than one party to migrate addresses, data, DNS, certificates and access controls. Provider-assigned IP addresses may not move. Firewalls and partner allowlists may embed them. Large datasets may take days to export over the available path, especially during an incident.

A practical portability test should export a representative workload, including files, databases, metadata, logs, identities and configuration. The customer should rebuild it in an independent environment and measure elapsed time, data loss and manual steps. It should test this while the primary service remains healthy and define a degraded-service procedure for the moment when the normal control panel is unavailable.

Contract terms should cover export formats, assistance, cost, bandwidth limits, retention after termination and the treatment of encryption keys. They should also state what happens if the provider ceases a product or loses its own upstream contract. This evidence would turn data portability from a promise into a recovery mechanism.

How the main failure paths propagate

A rack failure would affect the servers, storage or network devices concentrated there. If customer workloads span independent racks and failure domains, orchestration may restart them elsewhere. If storage, switching or management is shared, the apparent redundancy can collapse. Proof requires placement rules and a real evacuation or failover exercise.

An upstream failure has a different signature. If AS59002 were actively multihomed, public paths could help show route withdrawal and convergence. Today there is no AS59002 path to watch. If service uses another origin, the provider must identify it before customers can monitor transit resilience. The customer also needs to know whether backup bandwidth can carry production load.

A hardware-stock failure extends repair from minutes to procurement time. It can become acute when ageing equipment, import lead times or a batch defect affects several hosts. Local spares, compatible configurations and supplier entitlements determine whether capacity returns quickly. A general statement of redundancy does not reveal those limits.

A support failure multiplies every other problem. Alerts may be noticed but not owned; customers may receive no precise status; facility or carrier requests may wait for authorisation. A billing failure can suspend a service whose physical components remain sound. A migration failure can trap the customer after the original incident has already shown that recovery is uncertain.

These paths can combine. A power event may damage hardware, exhaust spares, flood support and force a migration through reduced network capacity. A useful resilience claim should therefore describe the worst credible compound event, not only isolated component redundancy. The present network evidence offers no basis for judging that claim either way.

Who is affected when the service fails

The first affected party may be a tenant running virtual machines, a business storing backups, a developer using hosted infrastructure or an organisation consuming a managed application. The visible symptom could be unreachable addresses, slow storage, a failed login, an unavailable control panel or an inability to retrieve data. The underlying cause may sit several suppliers away from the customer.

Downstream impact depends on what the customer concentrated in the service. A public website may go dark; internal systems may stop authenticating; remote staff may lose applications; scheduled data processing may miss deadlines; backups may fail silently; monitoring may disappear with the system it observes. Resellers can transmit the incident to customers who have never heard of the infrastructure provider.

Geography changes the impact but is not established by the company name. A service used within Chongqing might have local latency and support implications. A service reached nationally or internationally would depend on broader carrier paths. Without endpoint and customer evidence, the service area should remain CN as a registry association, not a claim that a particular network footprint covers all of China.

Customers should map critical business processes to the provider's components and define which can tolerate interruption. That map determines whether the needed recovery objective is minutes, hours or days. It also identifies which evidence matters most: route failover for a public endpoint, storage restoration for records, support escalation for managed systems or export for supplier failure.

What would prove a live infrastructure role

The cleanest proof would begin with a current service endpoint published by the company and a technical statement identifying how it is delivered. DNS and IP observations could then reveal the active prefix and origin ASN. If the origin is AS59002, the RIPEstat routing-status page should begin to show collector visibility, address space and paths. If the origin is another ASN, the company should identify the contractual and operational relationship to that network.

The next layer is interconnection. Current BGP announcements, stable observations from several collectors, named upstreams, route-origin authorisations and maintained policy records would establish a public network edge. Carrier contracts, circuit references, physical path diagrams and failover results would establish that the edge is usable and diverse rather than merely visible.

The physical layer requires named production and recovery sites, occupancy type, power design, measured headroom, rack placement, hardware inventory, spare policy and remote-hands arrangements. The service layer requires product documentation, current customer references or attestations, monitoring evidence and incident procedures. The recovery layer requires recent restore, failover and data-export results.

No single document must be public in full. Commercially sensitive material can be reviewed under confidentiality or independently attested. What matters is that the chain joins the company name to a live product, the product to endpoints, the endpoints to networks, the networks to facilities, and the facilities to tested restoration. Without that chain, an interested buyer sees an ASN identity and a cloud-flavoured name, not demonstrated current infrastructure.

A buyer's evidence request should be specific

The first request should ask the company to list current customer-facing services and the hostnames, address ranges or private connectivity methods used by each. It should ask explicitly whether any service uses AS59002. A statement that the company has an ASN is not responsive; the question concerns actual route origin and delivery today.

The second request should cover sites and suppliers. For each service, the company should name production and recovery locations, explain whether it owns or leases capacity, identify transit and facility counterparties, and state which responsibilities remain with those suppliers. It should disclose common power, fibre, management and staffing dependencies.

The third should quantify usable capacity. Buyers need normal and failover utilization, backup and restore throughput, recovery-site limits, hardware spares, support staffing and the amount of load that can move during a fault. These figures should be tied to recent measurements rather than design maxima.

The fourth should provide exercise evidence. A dated route failover, workload restart, backup restore, control-plane recovery, support escalation and customer export each tests a different promise. Reports should say what failed, how long restoration took, what data was lost, which supplier delayed recovery and what changed afterward.

Finally, the contract should reflect the architecture. It should define notice, escalation, measurement, data location, subcontractors, exit assistance, export formats and remedies. A buyer cannot eliminate dependency, but it can make the dependency observable, bounded and reversible.

Monitoring should follow the service, not only the ASN

AS59002 remains worth monitoring because any new announcement would materially change the evidence. A simple watch can record prefix count, collector visibility, neighbour changes, route-origin status and policy entities. IANA's autonomous-system registry and APNIC's ASN guidance provide the allocation context, while the live sources already cited show whether the number is being used.

But monitoring only AS59002 could miss the actual service. Once the provider identifies endpoints, customers should monitor DNS, TLS certificates, route origins, latency and reachability from multiple networks. They should separate application failure from route withdrawal, storage impairment, control-panel failure and account lockout. Each symptom belongs to a different owner and recovery path.

Monitoring also needs a decision rule. A new prefix is not automatically proof of production use; it may be a test. A brief withdrawal is not automatically an outage; it may be maintenance or traffic engineering. The operator can clarify the meaning with a change notice, looking-glass data and service telemetry. Repeated agreement between public routing observations and customer reachability would strengthen confidence over time.

The goal is not to turn every customer into a network operations centre. It is to prevent a critical dependency from being known only through a supplier's status message. Independent observation makes incident conversations faster and allows the evidence grade to improve when operation becomes visible.

The evidence grade is negative for the current ASN footprint

AS59002 receives a Negative network evidence grade for a current operating footprint. The grade follows the observed facts: zero announced prefixes, zero address space, zero RIS peer visibility, zero neighbours, CAIDA seen: false, a zero-prefix cone and zero network degree. The autonomous-system record exists, but it does not currently expose a routed edge.

This grade is deliberately narrower than a judgment about the company. It does not say Chongqing Cloud Computing Investment&Operation Co.,Ltd has ceased trading, has no servers, has no customers or cannot deliver a cloud service. Public routing data cannot support any of those statements. It says that current cloud operation cannot be proven through AS59002 and that the alternative delivery path, if one exists, has not been mapped here.

The distinction matters because negative evidence is useful only when its scope is honest. The BGP table is a strong place to test public route origin. It is a weak place to test private connectivity, provider-addressed hosting, rack inventory, staffing and contractual responsibility. A dormant-looking ASN can coexist with a service on another network; a lively ASN can coexist with fragile facilities and support.

The right response is not to fill the silence with speculation. It is to identify the evidence that can change the result. Current endpoints, route origins, interconnection, facilities, contracts, capacity and recovery exercises would do so. Until those arrive, the cloud role in the company name remains a proposition rather than a visible network fact.

What to watch next

The most decisive public change would be the appearance of an IPv4 or IPv6 prefix originated by AS59002. That would create a path to observe, an origin pair to validate and neighbours to analyse. Persistence would matter: a stable production announcement carries more evidential weight than a short test. A new PeeringDB profile, maintained routing-policy entities or a company statement mapping services to the ASN would add context.

The second change to watch is evidence that a live service uses another network. A current company website with resolvable service endpoints, product documentation naming an infrastructure partner, or customer-access material identifying provider-assigned addresses could explain the silent ASN. Such evidence should be tested against routing and supplier records rather than treated as proof by itself.

The third is physical and operational disclosure. Named facilities, recovery locations, power and network boundaries, support escalation, recent incident reporting and measured restoration would show whether a service can survive failure. Data-location and export terms would show whether customers can control their dependency.

For now, AS59002 is a clear registry identity and an equally clear absence in the current global route table. That combination is more informative than an unqualified cloud label. It tells readers exactly what is known, what is not, and what a provider would have to show before the name becomes evidence of live, recoverable infrastructure.