Summary
- TCLOUD NETWORK can be anchored to an active California corporation and to ARIN records that share an Irvine address, a telephone number and
tcloudnetcontact domains, but the public identifiers are not perfectly uniform and should not be treated as interchangeable without qualification. - The strongest operating evidence is AS399077: RIPEstat observed it announcing more than 500 IPv4 and IPv6 prefixes on July 15, 2026, while PeeringDB lists exchange and facility presence in San Jose, Hong Kong and Singapore. Those records prove a meaningful routing surface, not a particular cloud product, customer experience or data-residency promise.
- AS40789 illustrates why registry status and route status must be separated. ARIN marks the number active under TCLOUD NETWORK, INC, yet RIPEstat observed no current announcements from it; the historical observations predate the current 2017 registration and cannot be assigned to the company.
- Buyers should judge the service boundary through current contracts, route authorisation, asset attribution, incident evidence, data maps, escalation ownership and exit rights. A US address and reachable network contacts are useful accountability signals, but they do not establish staffed local support or operating assurance on their own.
The name is the beginning of the inquiry
There is an appealing neatness to an internet company whose name includes the word network. The label seems to answer the first question before anyone has asked it. A registry search produces an organisation. A routing search produces an autonomous system. A peering directory produces exchange points. It is tempting to stack those results into a complete corporate portrait and move on.
TCLOUD NETWORK resists that shortcut. Its public evidence is not empty or merely suggestive. There is an active California corporation record, an ARIN organisation registered as TCLOUD NETWORK, INC, another ARIN organisation registered as Tcloudnet, two active autonomous-system registrations under those organisation handles, a large currently observed routing footprint, an IRR routing set and a PeeringDB entry with interconnection claims across three markets. This is more than a name floating in a directory.
What is missing is the clean join between every layer. The California company record uses one legal spelling and an Irvine address. One ARIN organisation uses the same legal spelling but a Gardena address, while its contact record points back to the Irvine address. A later ARIN organisation shortens the name to Tcloudnet and uses the Irvine address directly. The older autonomous-system registration carries the name TCLOUD. The later, operationally prominent number carries the registered name TERAEXCH.
The public website identifies itself as Tcloudnetwork, describes its subject only as internet exchange points, and forwards through an old frame to a lightly populated WordPress site.
None of that proves disorder. Network operators accumulate names and handles for ordinary reasons: a brand changes, a routing project gets its own label, a company moves, an organisation creates a new registry account, a legacy number remains registered, or public documentation simply lags operations. The problem is not that the records differ. The problem is deciding what each difference permits an outsider to conclude.
For a buyer, compliance team or network engineer, the answer should be disciplined. Legal records can establish a corporation. ARIN can establish who is registered to receive and manage number resources. BGP observations can show what an autonomous system is announcing at a moment in time. PeeringDB can show what an operator has declared about its interconnection. A website can explain products and the customer relationship. These forms of evidence overlap, but none substitutes perfectly for another.
That distinction sets the tone for TCLOUD NETWORK. The company is not a case where there is no network proof. It is a case where strong network proof sits beside a much weaker public explanation of the service sold around it. Operating assurance depends on bridging those two surfaces.
California supplies the legal anchor
The clearest public corporate lead is Tcloud Network, Inc., listed by a California business-record index as an active general corporation filed on September 12, 2014. The index gives document number 3710512, describes the business as telecommunications, and lists Xiaofei Lai as chief executive, chief financial officer, secretary and director. It places the principal address at 14252 Culver Drive, Suite A, number 128, Irvine, California 92604.
That address matters because it recurs outside the business listing. ARIN's Tcloudnet organisation record, handle TCLOU, uses the same Irvine location. The role contacts attached to that organisation also use it. The contact attached to ARIN's separately named TCLOUD NETWORK, INC organisation likewise uses that Irvine address, even though the organisation record itself shows a Gardena location. Shared address and telephone details create a credible continuity signal across the legal and network records.
They do not eliminate every identity question. The California index is a third-party presentation of state data rather than a certified filing in the evidence available here. It was updated in July 2025, while the ARIN organisation records have their own update dates and naming conventions. The California record names a natural person in corporate offices. One ARIN record uses an individual contact under a different name, while the later organisation relies on role contacts for administration, technical operations, abuse and network operations. Public records can be accurate at different dates without describing the same management structure.
The useful conclusion is therefore narrower than a corporate biography. A California company with the TCLOUD NETWORK name has existed since 2014, and the recurring Irvine address ties it strongly to the internet-number records carrying the tcloudnet identity. That is enough to establish a US legal and administrative anchor for due diligence. It is not enough to establish which products are sold, which facilities are contracted, who works a support shift, or which customer assets sit behind the routes.
The distinction has commercial force. A customer signing a contract needs the legal name and address on that contract to match an entity capable of delivering the promised service. A network engineer opening a peering session needs the ASN, routing policy and operational contacts to match the network actually exchanging traffic. An accounts team needs the invoice and payment beneficiary to match the contracting party. A security team needs abuse and incident contacts that can act on the relevant address space. The public record suggests these identities are related.
A well-run engagement should make the relationship explicit in the documents the customer receives.
Without that explicit statement, the customer carries the reconciliation work. It must decide whether TCLOUD NETWORK, INC, Tcloudnet, TERAEXCH and Tcloudnetwork are legal name, network operator, routing project and website label respectively. That is manageable, but it is real work. Identity friction is not cosmetic when an outage, abuse complaint, payment dispute or migration forces several teams to act quickly.
AS40789 shows why active can mean two things
The older autonomous-system record is the most useful warning against reading a status field too quickly. ARIN lists AS40789 with the name TCLOUD and registrant organisation TCLOUD NETWORK, INC. The registration date is July 25, 2017, five days after the corresponding organisation record was created. ARIN marks the number active. The organisation record was last changed in November 2024 and provides one contact for administrative, technical, abuse and network-operations roles.
Read alone, that looks like a current network identifier. Routing observation tells a different, but not contradictory, story. RIPEstat reported no IPv4 or IPv6 prefixes announced by AS40789 on July 15, 2026. None of its 326 IPv4 or 322 IPv6 observation peers saw the autonomous system. Its announced address count and observed neighbours were both zero.
ARIN and RIPEstat are answering different questions. ARIN's active status says that AS40789 remains a valid registration in the registry. RIPEstat's zero visibility says that the number was not seen originating routes by its collectors at the time of observation. A number can remain properly registered while sitting unused, reserved for future work, retained as a legacy asset, used only in a private context, or temporarily absent from the global table. Registry activity is not a synonym for route activity.
The historical dates make the interpretation more delicate. RIPEstat's earliest and latest route observations for AS40789 run from 2008 to 2014. Those observations precede the current ARIN registration to TCLOUD NETWORK, INC in 2017. Autonomous-system numbers can be returned and reassigned. The historical routes therefore cannot be attributed to TCLOUD NETWORK from the available record. They describe earlier use of the number, not a decade-long operating history for this company.
This is not a minor technical footnote. It demonstrates how an apparently simple metric can produce a false company history. Someone might see a first-observed date in 2008 and a California filing in 2014, then infer that the business operated a network before incorporation. The current registration date blocks that inference. The responsible chronology starts in 2017 for TCLOUD NETWORK's control of AS40789, and the current global routing evidence shows no announcements from it.
For customers, AS40789 should be treated as a registered identifier whose present production role is not publicly demonstrated. If a sales document, invoice, firewall rule or letter of authorisation invokes it, the operator should explain what it does now. If it is intentionally dormant, that is a perfectly intelligible answer. If it backs a private interconnection or disaster-recovery plan, the customer can ask for suitable evidence. What should not happen is for the word active in a registry to stand in for a live service description.
AS399077 is the stronger operating signal
The later number, AS399077, has a very different profile. ARIN registered it on December 2, 2020 under the name TERAEXCH to organisation handle TCLOU, Tcloudnet. The organisation had been created the previous month and uses the Irvine address also found in the California company listing. ARIN marks the autonomous system active and attaches distinct role contacts for administration, technical work, abuse and network operations.
Unlike AS40789, AS399077 is plainly visible in global routing. RIPEstat's July 15, 2026 snapshot showed all of its 326 IPv4 observation peers and all 322 IPv6 peers seeing it. The service counted 503 IPv4 prefixes representing 128,256 addresses, plus eight IPv6 prefixes representing 512 units measured at the /48 level. It observed 44 neighbouring autonomous systems. Its first observed route under this registration appeared in February 2021, shortly after the ARIN allocation, and the most recent observation was on the day of review.
Those numbers establish an operational fact: AS399077 was not a dormant registry entry. It was originating a large set of routes with broad collector visibility. BGP.tools produced a slightly different count, 493 IPv4 and eight IPv6 prefixes, and listed PCCW Global, NTT America, Cogent and Cloudflare among its upstreams. Different collectors, filters and update moments often produce different totals. The ten-prefix gap is a reason to timestamp the measurement, not a reason to dismiss it. Both views describe a network with hundreds of active announcements and multiple large transit relationships.
BGP.tools also showed numerous prefix descriptions carrying the names TCLOUD NETWORK, INC or Tcloudnet Inc. Some originated routes carried other descriptions, including Cloud Innovation and Root Limited. This is another place where a route table can be overread. The origin ASN tells observers which autonomous system announced a prefix. A description may reflect the resource holder, a customer, a historical label or a routing-database entry. It does not by itself prove corporate ownership of every address, nor does it describe the contract under which the route is originated.
The current record therefore supports a strong but bounded statement. Tcloudnet's AS399077 operates a broadly visible, multi-homed network and originates substantial IPv4 and IPv6 space. It appears to carry routes associated with several names, which is consistent with a provider, transit, hosting or network-services role. The record does not show how many customers use it, what those customers buy, what service levels apply, or whether every named prefix belongs to TCLOUD NETWORK itself.
ARIN adds one more useful detail. The TCLOU organisation is also the registrant for AS400104, named TERAEX, and for an active IPv6 allocation beginning at 2606:4dc0::. BGP.tools lists AS400104 as a downstream of AS399077. This supports an operator with more than one number resource and an internal or related routing structure. Even here, the right language is registration and observed connectivity. A downstream relation is not automatically a subsidiary relation, and an allocated network is not automatically fully deployed.
For due diligence, AS399077 should be the starting point for technical verification. A prospective customer can compare the ASN on a service order with observed routes, ask which prefixes are customer-assigned, verify route-origin authorisations, inspect the expected upstream set, and confirm whether the service uses the advertised exchange locations. That is considerably more useful than relying on the company name alone.
PeeringDB describes reach, with a dated signature
PeeringDB gives AS399077 its most legible public operating description. The network entry names Tcloudnet, identifies the network as content, gives AS-TCLOUD as its routing set, and declares an open peering policy. It says multiple locations are preferred and that a contract is not required for peering. The same entry claims 2,000 IPv4 prefixes, 100 IPv6 prefixes and traffic in the 300 to 500 gigabits-per-second band.
The location records are more concrete. PeeringDB lists operational interfaces at seven exchange fabrics: Equinix San Jose and BBIX US-West in California, BBIX Hong Kong and Equinix Hong Kong, plus BBIX Singapore, Equinix Singapore and SGIX. The listed port speeds range from 10 to 100 gigabits per second. Facility declarations place the network at Equinix's Silicon Valley campus, Equinix HK1, MEGA-i in Hong Kong and Equinix SG1 in Singapore.
This is meaningful service-proof material, but it carries a date. The main PeeringDB network record was last updated in October 2022. Its exchange and facility records were created or updated between 2021 and 2022. They still display as operational, yet the lack of a recent change means an outsider should verify current ports and capacity before treating them as a 2026 commitment. PeeringDB is maintained by network entities and is designed for interconnection discovery. It is not an uptime report or an independently audited inventory.
The large gap between the PeeringDB prefix claims and current route observations makes that caution visible. PeeringDB says 2,000 IPv4 and 100 IPv6 prefixes. RIPEstat saw 503 and eight; BGP.tools saw 493 and eight. The most likely lesson is not that one source is fraudulent. PeeringDB fields may be broad estimates, anticipated scale, rounded declarations or simply stale. Observational platforms may apply visibility thresholds or count only currently originated routes. A customer should use the discrepancy as a question: what is the current advertised footprint, and which number best represents capacity relevant to the contracted service?
The traffic band deserves the same treatment. A self-declared 300 to 500 gigabits per second says something about how the operator positioned the network in 2022. It does not show a utilisation curve, peak load, spare headroom, attack capacity or per-customer commitment in 2026. Seven exchange connections also do not guarantee that traffic will take the best path for a particular user. Routing policy, upstream selection, congestion, remote peering, customer location and failure state all matter.
Still, the peering record materially strengthens the case that AS399077 is a genuine network operation. It names facilities and exchange interfaces, uses both IPv4 and IPv6, and spans the western United States and two major Asian interconnection markets. Combined with current BGP visibility, that is far more persuasive than a generic cloud brand. The limitation is at the next layer: the record explains where the network can meet other networks, not what a retail or enterprise customer is promised.
The routing set is a policy entity, not an ownership chart
The AS-TCLOUD routing set helps other networks build filters for routes associated with Tcloudnet and its customers. The ARIN version describes itself as the major set for TCloud Network members and includes AS399077 alongside a long list of autonomous systems and nested sets. It was modified in June 2026. The RADB version carries a similar membership list and had also been updated in 2026.
That freshness is useful. A maintained routing set is an operational control: peers and upstreams can use it to determine which origin ASNs they expect behind a customer cone. When maintained accurately, it reduces manual configuration and helps prevent accidental propagation of unexpected routes. It is one of the places where enterprise automation becomes visible in a network business. Changes to customer connectivity can flow from an authoritative routing entity into filter generation and review.
But the word member has a specific routing meaning here. It does not make every ASN in AS-TCLOUD part of the same corporation. Some can be customers, downstreams, service partners or members reached through nested routing sets. The list includes records with their own names and jurisdictions. Treating the set as a corporate family tree would turn a technical policy relationship into an unsupported ownership claim.
The distinction matters for incident response. If an unwanted route appears from a downstream ASN, the organisation responsible for the originating address may differ from the organisation maintaining the outer routing set. The first useful questions are operational: who authorised the prefix, which registry entity describes the route, which network accepted it, and which contact can withdraw it? Those questions should precede assumptions about legal control.
The routing set also reveals a burden carried by TCLOUD NETWORK if it is the maintainer. A large customer cone requires disciplined updates. Stale members can make filters too permissive; missing members can cause legitimate routes to be rejected. Nested sets can hide changes several levels away. Automated filter generation reduces repetitive work, but only if registration, customer approval and removal are governed. The public set proves that a mechanism exists. It does not expose the internal approval process or its accuracy rate.
For a customer buying transit or routed hosting, the due-diligence request is straightforward. Ask which routing set will contain the customer's ASN, who approves additions, how quickly removals propagate, whether route-origin authorisation is required, and what evidence is retained. That turns an internet registry entity into a testable service control.
A route is not a product catalogue
TCLOUD NETWORK's public routing evidence is rich enough to create a different risk: technical overconfidence. Hundreds of prefixes, major upstreams and exchange connections look like a product. They are not. They show reachability and routing relationships. They do not say whether the operator sells transit, leased address space, virtual servers, content delivery, anti-abuse services, private connectivity or some combination.
The company website does little to close the gap. In July 2026, tcloudnet.com returned a minimal page titled Tcloudnetwork with a short reference to internet exchange points. The page used an old HTML frame to load a WordPress site over an unencrypted URL. The linked WordPress site contained two brief entries from July 2017 and no current public account of products, terms, service levels, security, privacy, support or network maintenance.
That web presentation should not be used as a proxy for the quality of the network. Infrastructure businesses sometimes serve customers through direct sales and operate networks that are much more mature than their marketing sites. BGP visibility and peering records are better evidence of network operation than visual polish. At the same time, the absence of current service documentation shifts work and risk onto the customer. The buyer must obtain privately what a fuller public service surface would normally explain.
The missing documents are ordinary rather than decorative. A customer needs to know the contracting entity, service description, included locations, delivery method, acceptable-use terms, abuse process, maintenance notice, incident reporting, support hours, escalation path, billing unit, suspension conditions, data handling, export rights and termination procedure. A network can route every packet correctly while leaving these commercial controls unclear.
This is particularly important when address resources are involved. If a customer receives an IP block, it needs to know whether the block is provider-assigned or portable, who publishes route and geofeed data, who creates route-origin authorisations, how reverse DNS is delegated, how abuse complaints are handled, and what happens to the addresses at exit. An originated prefix can remain technically reachable while ownership, authorisation or customer responsibility is disputed.
Service proof therefore requires a chain. The legal entity signs the agreement. The agreement identifies the operating brand and ASN. The delivery record identifies the prefix, location and upstream path. The registry and routing controls authorise the announcement. Monitoring records show whether delivery meets the commitment. Support records show who responded when it did not. Billing and termination records show when authority began and ended. TCLOUD NETWORK's public evidence strongly supports the middle of that chain. Buyers still need the ends.
Locality has at least four different meanings
The word US appears repeatedly in the TCLOUD NETWORK record. The corporation is in California. Both ARIN organisations are US records with California addresses. AS399077 is registered through ARIN and generally labelled as a US network. Several prefix descriptions on routing sites carry US country markers. None of those facts, alone or together, establishes that customer data stays in the United States.
Data sovereignty begins by separating four locations that are often collapsed. Legal domicile is where the contracting company is incorporated and subject to corporate law. Network registration is the jurisdiction of the number-resource holder and registry. Interconnection location is where routers meet at an exchange or facility. Data location is where customer content, logs, credentials, tickets, backups and administrative records are stored or processed. TCLOUD NETWORK's public record provides clues about the first three and almost no public detail about the fourth.
PeeringDB makes the distinction unavoidable. AS399077 lists a physical presence in San Jose, Hong Kong and Singapore, with exchange interfaces in all three markets. A packet entering the network in California may exit in Asia. A customer server in one country may be managed through an account platform in another. Traffic logs can be copied to a central operations tool. Abuse reports can contain IP addresses, timestamps, URLs and customer identifiers. Support tickets can expose configuration and incident details even when the hosted content never leaves its original facility.
Country labels attached to prefixes do not settle this. Routing databases often reflect registration, operator declarations or geolocation conventions. They are not a live map of every machine using an address. The fact that AS399077 originates prefixes described under US, Hong Kong or Singapore labels is evidence of a geographically varied address and routing surface. It is not proof that a particular customer's traffic or records reside in those places.
The PeeringDB facilities also require careful language. A declared presence at Equinix SG1 or HK1 says the network reports equipment or connectivity at that facility. It does not prove that customer application data is stored there. An operator may peer through a router while customer workloads remain elsewhere. Conversely, a workload may be delivered through a partner facility that is not visible in the operator's own PeeringDB list.
A buyer with locality requirements should ask for a service-specific data map. It should identify the delivery facility, administrative platform, monitoring systems, logging destination, ticketing provider, billing system, backup location and subprocessors. It should distinguish packet transit from stored data. It should explain remote access by operations staff and say how long operational records persist. It should also explain what can move during failover.
TCLOUD NETWORK's multi-market network could be commercially valuable. Presence in California, Hong Kong and Singapore can shorten paths and give customers routing options across the Pacific. That reach is an advantage only when the service design tells the customer how it is used. For a latency-sensitive service, the buyer may want local ingress and controlled egress. For a regulated service, it may need a regional processing commitment. For an abuse-sensitive service, it may need a clear jurisdiction and evidence-retention path.
The public record cannot answer those questions. The correct conclusion is not that TCLOUD NETWORK moves customer data across borders, nor that it keeps data in California. It is that global routing reach and US corporate identity are limited public evidence substitutes for a data-handling commitment.
Automation is only as reliable as the authority behind it
Network operations are full of automation long before a company sells a product called automation. Address allocations feed inventory. Customer orders trigger router configuration. Routing sets feed filters. Route-origin authorisations constrain accepted origins. Monitoring systems watch sessions, loss and latency. Abuse systems correlate complaints with address assignments. Billing systems decide whether a service remains authorised. Ticketing systems carry the human decisions that automation cannot safely make alone.
TCLOUD NETWORK's public record shows several inputs to such a system. ARIN identifies registrants and role contacts. AS-TCLOUD expresses expected routing relationships. PeeringDB publishes exchange addresses and policy. BGP observers show the live result. These records make an external consistency check possible. A customer can ask whether the registered organisation, announced route, routing-set member and service order agree.
The check matters because each record can drift. An ARIN contact can become stale. A PeeringDB port can remain marked operational after a change. An IRR member can survive customer termination. A prefix can be announced from the wrong origin. A support queue can know about a change that never reaches the network inventory. Automation can propagate a correct update quickly, but it can also propagate a mistaken authority quickly.
The discrepancy among public prefix counts is a harmless illustration of the broader problem. PeeringDB's older declaration is much larger than current observed counts. That may reflect scope and timing rather than an error. Yet any automated procurement or risk tool that ingests the numbers without their dates and meanings could produce a false measure of scale. The record needs provenance: who asserted the value, what it counted, when it was observed and whether it describes capacity or current state.
For TCLOUD NETWORK, a mature customer workflow would attach every change to an accountable request. Adding a prefix should require proof that the customer may use it, a route-origin check, a planned origin ASN, filter updates and a rollback path. Removing service should revoke the route and related access, update the routing set, preserve the required audit record and release billing. Changing a support contact should not silently change routing authority. A high-risk request should have a human escalation path.
The public record does not disclose whether those controls exist. It does show why they are necessary. AS399077 originates hundreds of routes and maintains a broad policy set. At that scale, manual memory is not an adequate authority system. The value of automation is not simply that it saves configuration time. It is that it can keep identity, entitlement, routing state and evidence aligned, provided the approval source is trustworthy.
Customers can test this without demanding confidential engineering detail. Ask for a sample change record with sensitive values removed. Ask how a route request is validated, how many approvals are required, how emergency withdrawal works, how stale routing-set entries are detected, and how completed changes are reconciled against observed BGP. Ask what happens when a monitoring alarm and customer report disagree. These questions measure operating discipline rather than marketing vocabulary.
Network contacts are not the same as customer support
ARIN's records give TCLOUD NETWORK a public accountability surface. The older TN-214 organisation uses one named contact for administrative, technical, abuse and network-operations roles. The later TCLOU organisation separates administration, technical work, abuse and network operations into role contacts. Both records publish a US telephone number, and the TCLOU contacts use tcloudnet.net email addresses. This is better than an anonymous network with no reachable contact trail.
Yet registry contacts have a defined purpose. They help the internet community address number-resource administration, routing, abuse and operational issues. They do not establish a customer help desk. A network-operations mailbox may be monitored by engineers but not authorised to change a contract. An abuse contact may receive complaints but not troubleshoot a virtual server. A public phone number may reach a central line without guaranteeing hours, languages or response time.
The company website does not publish the missing customer layer. There is no visible help centre, service-status page, support schedule, escalation ladder or incident archive in the public material reviewed. There is also no explanation of which contact domain is preferred: the older ARIN record uses a tcloudnet.com peering address, while the later role contacts use tcloudnet.net. Both can be legitimate, but a customer should receive a clear, current route.
This is where local support labour has to be proved rather than inferred. A California corporation and US telephone number provide legal reachability and a local administrative anchor. They do not show that engineers are staffed in California, that someone answers during US business hours, or that an incident can be escalated locally. Peering presence in Hong Kong and Singapore likewise does not prove support staff in either market.
For a network customer, support labour is not an accessory. It is the work of confirming authority, diagnosing a path, coordinating an upstream, withdrawing a bad route, interpreting an abuse complaint, restoring a session and documenting what happened. If a provider relies on a small team, that can produce excellent direct service, but it can also create key-person risk. Role contacts reduce that risk only if several people monitor them and have the authority to act.
A buyer should therefore ask operationally specific questions. Which channel is for a total outage? Which is for route leakage? Who can authorise an emergency prefix withdrawal? What response target applies outside normal hours? Can support reach the network team at every advertised location? Is there a separate process for abuse that will not suspend a customer before evidence is reviewed? Who owns the post-incident report? What happens when the original account contact leaves the customer?
Answers should be written into the service relationship. A generic promise of round-the-clock support is less useful than named severity levels, acknowledgement targets, update cadence and escalation authority. The public ARIN contacts give TCLOUD NETWORK a starting point for accountability. They do not complete the support contract.
The decisive evidence appears during failure
Most network providers look adequate when a path is up and traffic is ordinary. The meaningful distinction appears when records conflict or a control fails. TCLOUD NETWORK's public footprint suggests several realistic tests that a buyer can use to assess the operating boundary before making it critical.
Consider a route-origin error. A customer prefix expected behind AS399077 appears from another ASN, or AS399077 begins originating a block the customer did not authorise. Detection is only the first step. The provider must identify the service owner, validate the correct authority, change filters or announcements, coordinate with upstreams and preserve evidence. A routing set and route-origin authorisation can reduce risk, but a human still needs authority to resolve ambiguous ownership. The customer should know the emergency channel and expected withdrawal time.
Consider an exchange failure. PeeringDB lists interfaces in seven fabrics, but the customer's traffic may depend heavily on one path. When a port or route server fails, the network should reroute without creating congestion or an unexpected jurisdictional path. The customer needs monitoring that distinguishes reachability from acceptable performance. It also needs to know whether a failover through Hong Kong or Singapore is permitted for its workload. The number of exchange points does not answer that service-specific question.
Consider an abuse report. AS399077 originates many prefixes associated with several names. A complaint must be mapped to the correct customer and time period. If address assignments have changed, current WHOIS or route descriptions may point to the wrong party. Good records identify who controlled the address when the event occurred, what evidence was received, what action was taken and how a mistaken block can be reversed. Poor records turn a large network into a source of false attribution.
Consider account compromise. An attacker who gains access to a customer portal or convincingly impersonates an authorised contact may request a route change, reverse-DNS change or service cancellation. The provider needs stronger checks than possession of an email address. High-impact changes should have additional verification, separation of duties and a rapid rollback. Public routing evidence cannot show these controls, so the contract and onboarding process must.
Finally, consider provider exit. A customer moving to another network needs a controlled end to announcements, address use, access credentials, monitoring and billing. If addresses are provider-assigned, the customer may need renumbering time. If it brings portable space, it needs the old origin removed promptly so the new origin is not undermined. Historical tickets and incident evidence may need export or retention. An easy technical start can conceal a costly exit if these rights are not defined.
These cases reveal why operating assurance is more than uptime. It is the ability to explain and reverse change under pressure. TCLOUD NETWORK's large visible routing footprint shows that there is a real system to operate. The public record does not show how customers participate in that system when something goes wrong.
What a buyer should verify before dependency grows
TCLOUD NETWORK can be evaluated with a relatively short set of evidence requests. The first is identity: a contracting document should state the legal entity, operating name, billing identity, relevant ASN and authorised support domains. If TCLOUD NETWORK, Tcloudnet and TERAEXCH have distinct roles, the document should name those roles. The repeated Irvine address makes the relationship plausible; the agreement should make it explicit.
The second is service scope. The order should specify whether the buyer receives transit, hosting, address assignment, private connectivity, exchange access, managed routing or another service. It should name delivery locations and dependencies. A reference to AS399077 or a list of exchange points is not enough, because the customer may receive only a subset of the network's reach.
The third is resource authority. For every customer prefix, the parties should record the holder, permitted origin, routing-set entry, route-origin authorisation, reverse-DNS owner and abuse responsibility. If TCLOUD NETWORK supplies addresses, the customer should know whether they can be retained at exit. If the customer supplies them, it should know how quickly the provider will add and remove announcements.
The fourth is performance and resilience. The agreement should define what is measured, where it is measured and what happens after a miss. Availability without a measurement point can conceal regional failure. Capacity without a committed rate can conceal contention. A multi-homed ASN without a disclosed failover policy can still deliver an undesirable path. The customer should understand maintenance notice, incident update and post-incident review.
The fifth is data handling. A network service may store less customer content than a conventional cloud platform, but it still handles account, traffic, routing, abuse and support data. The provider should explain locations, retention, access, subprocessors and deletion. The three-country peering footprint makes a clear separation between packet path and stored record especially important.
The sixth is support. The buyer should test the published route before a crisis, record severity levels and escalation contacts, and verify that the people answering can reach network operations. It should not assume that an ARIN mailbox is the contracted support channel. It should also confirm the legal notice route, since operational and legal accountability solve different problems.
The final request is exit evidence. A mature provider can describe how it stops announcements, removes routing-set membership, closes access, returns customer information and confirms final billing. The customer should test that process on paper while the relationship is healthy. Exit planning is not pessimism; it is how a buyer prevents a useful network dependency from becoming an irreversible one.
These requests impose some cost on both sides. The commercial question is whether the risk reduction justifies that cost. For a low-dependency test service, a buyer may accept lighter documentation and monitor the path independently. For production transit, regulated workloads or address-dependent services, the record burden is proportionate. AS399077's scale makes formal controls more, not less, relevant.
A network business should be judged at its boundary
TCLOUD NETWORK's public record is stronger than its sparse website suggests and less complete than its route count might imply. The California filing provides a credible legal anchor. Shared addresses, contact details and naming patterns connect that company to two ARIN organisation records. AS399077 supplies compelling evidence of current network operation: hundreds of originated prefixes, broad collector visibility, multiple upstreams and declared exchange presence across San Jose, Hong Kong and Singapore. The maintained AS-TCLOUD set adds evidence of a wider routing customer or member surface.
The cautions are equally concrete. AS40789 is registered but not currently visible in global routing. Historical observations of that number predate TCLOUD NETWORK's registration and belong outside the company story. PeeringDB's scale claims are dated and differ sharply from current observations. The routing set expresses policy relationships, not ownership. Country labels and exchange locations do not establish data residence. ARIN role contacts do not establish customer-support coverage. The website does not publicly document the service that joins these pieces.
That produces a balanced verdict. TCLOUD NETWORK should not be dismissed as a name without infrastructure. AS399077 is a substantial operating signal. Nor should it be treated as self-proving assurance. The most important customer facts remain contractual and operational: what is being bought, which entity is responsible, which resources are authorised, where records are handled, who acts during failure, and how the dependency ends.
The US record answers the identity question far enough to begin serious due diligence. The live routing record answers the existence question far enough to show a functioning network. What neither can answer is whether a particular customer will receive reliable, local, governable support. That assurance has to be built at the boundary between the network and the people depending on it.