Summary

  • The identity evidence is narrow but strong. APNIC's current record marks AS17774 active, names it SWCLOUD, describes the holder as Zhejiang Shiwei Data Technology Co., Ltd., and publishes Zhejiang contacts using the swcloud.com domain. The BTW directory independently links the same company name to AS17774.
  • Registration is not the same as present route operation. RIPE's snapshot on July 15, 2026 identified the same holder but marked the autonomous system unannounced, while its announced-prefix view found no routes visible to at least ten full-feed peers during the first half of July. That observation does not prove inactivity, but it leaves no public basis for claims about current reach, scale, upstream diversity or traffic performance.
  • A public swcloud.io site contains service, support, privacy and availability terms, yet those pages identify only an undefined """SWCLOUD team""" and never name Zhejiang Shiwei Data Technology Co., Ltd. The shared brand is therefore limited public evidence to attribute those services, policies or availability commitments to the company profiled here.
  • The practical conclusion is an evidence sequence rather than a rating. A buyer should first reconcile the legal entity, contract and service domain; then verify assigned addresses and current route origins; then document data locations, automation ownership and support escalation; and finally run recovery and exit exercises. Until those joins are made, AS17774 is evidence of an attributable network identity, not a substitute for operating assurance.

The strongest public fact is also the narrowest

Company research often starts with a website and works outward. SWCLOUD requires the opposite method. The reliable starting point is not a product catalogue, customer case study or corporate history. It is an internet-number registration. The APNIC record for AS17774 gives the autonomous system the name SWCLOUD, describes the holder as Zhejiang Shiwei Data Technology Co., Ltd., records the country as China and marks the registration active. The BTW directory entry makes the same company-to-ASN link while classifying the subject as a private company associated with network resources.

That is meaningful evidence. An autonomous system number is not a slogan invented for an advertisement. It is an identifier used to express routing policy between networks. Registration ties the identifier to a holder and gives other operators a place to start when they need to understand who is represented by an announcement, a routing-policy entity or an operational contact. Here, the name match is exact enough to distinguish Zhejiang Shiwei from the many unrelated businesses and products that use some variation of """SW Cloud."""

The registration also supplies a geographic and contact trail. APNIC lists Lu Qi in an administrative role and Wang Tianqiang in a technical role, both with a Jinhua, Zhejiang address, the same telephone number and email addresses at swcloud.com. The rendered WHOIS view supplies the fuller address text: Room 429 in Building 1 at the Yatai incubation base on Yongkang Street in Wucheng District, Jinhua. These details were entered in 2018, while the autonomous-system record shows registration and last-change events in May 2020. Dates in a registry describe the record, not necessarily the incorporation or start of a business, but the alignment of name, place, telephone and domain makes this more than a loose keyword match.

The contact domain adds another modest join. Public domain registration data for swcloud.com shows a 2008 creation date, a registrant province of Zhejiang and a Chinese registrar. The domain still resolved during the review, though it did not return a usable website over the attempted connections. Its address sat in a small Jinhua network assignment described by APNIC as belonging to Xiamen Sanwu Netware Science Co., Ltd. That hosting fact does not establish ownership of the address or the company behind the site. It merely shows that the domain used in the autonomous-system contacts remains a real, registered name with a Zhejiang trace.

This is the point at which precision matters. The evidence supports the statement that Zhejiang Shiwei Data Technology Co., Ltd. is the registered holder named for AS17774 and that its network contacts use swcloud.com. It does not establish that the company currently sells a particular cloud product, runs a public cloud region, owns a data centre, employs a given number of engineers or serves any named customer. It does not show revenue, licences, capacity, uptime or a support organisation. A strong identifier can resolve identity without resolving the operating questions that make the identity commercially useful.

That narrowness is easy to lose because the label SWCLOUD sounds like a product. The human eye reads """cloud""" and fills in compute, storage, orchestration and support. The network system reads only a registered autonomous-system name. Research becomes unreliable when those two readings are treated as equivalent. The disciplined position is more useful: AS17774 is a firm anchor, and the rest of the service must be joined to it with separate evidence.

An active registration does not imply an active announcement

The distinction between allocation and operation becomes visible in the routing record. On July 15, 2026, the RIPE Stat overview for AS17774 returned the same holder name as APNIC but marked the autonomous system announced: false. The separate announced-prefixes view returned no prefixes for its July 1 to July 15 observation window. RIPE notes that this view excludes routes seen by fewer than ten full-feed peers, so the finding is specifically that no sufficiently visible route met that collection threshold. It is not a declaration that the number has never been used or that no private or narrowly visible arrangement exists.

That caveat is important, but it does not make the empty current view meaningless. A publicly announced autonomous system normally leaves observable routing evidence: originated prefixes, paths through upstream networks and changes over time. When none appears in a broad collector view, a researcher cannot responsibly infer a present internet edge from registration alone. There is no current public route in this frozen evidence pack from which to estimate address scale, identify transit providers, compare IPv4 and IPv6 policy, inspect route-origin authorisation or assess path diversity.

Several benign explanations are possible. The company could hold the number without currently originating routes. It could use another operator's autonomous system for a service. It could operate a private network, a customer-specific environment or a route with visibility below the collector threshold. The number could be reserved for a future deployment, retained after a change, or used intermittently. Each possibility is technically plausible. None is established by the public record reviewed here, and choosing one would turn uncertainty into fiction.

The absence also cannot support a negative performance claim. It does not show that Zhejiang Shiwei's services are unavailable, because no attributable service endpoint has been identified. It does not show that the company lacks engineers, facilities or customers. It does not show why the route view is empty. The correct conclusion concerns evidence, not quality: the current public BGP view does not provide operating proof for AS17774.

Historical route data needs even more care. RIPE's routing-history endpoint contains prefixes originated by AS17774 in the early 2000s, years before the present SWCLOUD registration events and the 2018 contacts. Autonomous system numbers can move through administrative histories, and a time series keyed only to the number does not prove that every historic announcement belonged to the current holder. Those old routes therefore cannot be used to give Zhejiang Shiwei an operating history extending back to 2001. They are a warning about temporal attribution, not evidence of company longevity.

For a prospective customer, the next step is straightforward. Ask the provider to identify the legal service entity, the autonomous system or systems actually used, the prefixes assigned to the proposed service and the upstream networks that carry them. Then check those facts at the time of the trial. If AS17774 is intended to originate customer-facing routes, a route collector and the customer's own monitors should see that origin. If another ASN carries the service, the provider should explain the relationship and the incident boundary.

If addresses are supplied by a facility or transit partner, the contract and abuse contacts should say who controls them.

The same test should cover route security without treating it as a magic seal. The buyer can verify whether relevant origins have Route Origin Authorisations, whether invalid announcements are rejected by the chosen upstreams and how route changes are approved. It can monitor for origin changes and unexpected more-specific routes. Those controls reduce particular routing risks; they do not prove application health, physical path diversity or account security. A valid origin can still lead to an unhealthy service, while a healthy private service may produce little public routing evidence.

This is why the empty route view matters commercially. It removes one of the easiest independent ways to test a provider's network story. A contract can still establish a service, and direct measurement can still establish performance, but neither is present in the registry itself. Until a buyer can match order, address, origin and measured path, """active""" should be read as the status of an APNIC record, not as a claim about a live cloud platform.

The same name on another site is not an identity bridge

The web offers a tempting shortcut. A Chinese-language site at swcloud.io publishes service terms, an acceptable-use policy, a privacy policy and a service-level agreement under the SWCLOUD name. Those pages look like the kind of service proof missing from the autonomous-system record. They describe selectable plans, accounts, data-transfer services, automated link controls, support limits, traffic allowances and availability levels. A hasty profile could combine them with AS17774 and produce an apparently detailed company description.

The documents themselves prevent that shortcut. The service terms say only that """SWCLOUD""" owns swcloud.io and provides the service, then define that name as the SWCLOUD team. They do not give a company registration name, address, licence number or reference to Zhejiang Shiwei Data Technology Co., Ltd. The privacy policy uses the same team-level identity. None of the reviewed pages links swcloud.io to swcloud.com, AS17774, the APNIC contacts or the Jinhua address.

The gap is not repaired by similarity. SWCLOUD is a compact, attractive label that can be coined independently. Search results include unrelated storage products, industrial platforms and network services using the same letters. Even within the frozen evidence pack, the swcloud.io pages describe a data-transfer and subscription service, while the APNIC record says nothing about product type. Matching the two would require a first-party statement, a contract naming Zhejiang Shiwei, a verified domain relationship, a consistent company address or another reliable bridge. None was found in the permitted pass.

The swcloud.io material is therefore useful only in a negative and methodological sense. It demonstrates that detailed service language can be publicly available under a matching brand without proving which legal entity stands behind it. The site's service-level agreement sets different availability percentages for three account levels, defines unavailability using a condition affecting more than half of accounts at a level for more than ten minutes, excludes planned maintenance and several outside causes, and gives customers three days to make a claim. Those are concrete terms, but they cannot be assigned to Zhejiang Shiwei.

The same applies to support and privacy. The service terms say basic support generally covers inability to use the service when caused by the provider and allow some requests to be closed without reply. The privacy policy discusses collection of account, connection, port, traffic, device, DNS and usage information, and it permits the use of third-party services. These provisions could materially affect a buyer of that site's service. They say nothing reliable about the company in this profile unless the legal identity bridge is established.

This exclusion may feel conservative, but it protects both reader and company. Attributing a low availability commitment or a broad monitoring policy to the wrong organisation would be unfair. Attributing an orderable product and support surface to Zhejiang Shiwei without proof would be equally misleading. Good research does not maximise the number of details; it maximises the number of details that survive an identity check.

A buyer can resolve the ambiguity with ordinary documents. The quotation, order form, invoice and service agreement should name the contracting company in Chinese and English, give a registered address and identify the service domains. Corporate email should come from a domain the company controls. The account portal should link to the same legal terms. Network documentation should state whether AS17774 participates in delivery. If a reseller or affiliate is involved, each role should be explicit: seller, operator, infrastructure supplier, support owner and data processor are not interchangeable labels.

Until that packet exists, swcloud.io remains outside the company evidence boundary. Its terms are not proof of Zhejiang Shiwei's service and should not be used to praise or criticise the company. The most revealing fact about the site is the join that cannot yet be made.

A service begins with an accountable order, not a suggestive label

Once the same-name shortcut is removed, the public record contains no attributable service catalogue for Zhejiang Shiwei. That does not mean no service exists. It means service existence must be proved at the transaction boundary. A buyer should be able to identify what is being ordered, from whom, where it will run, who will administer it, which technical commitments apply and how the relationship ends.

The legal entity is the first field. """SWCLOUD""" may be a brand, an autonomous-system name or both. The agreement should state the complete company name and registration identifiers. The bank account and invoice issuer should align with that entity or disclose the authorised collection arrangement. If a second company provides racks, transit, licences or customer support, the documents should name it and explain whether the buyer has rights against it. A brand that crosses several parties can be perfectly legitimate, but the chain of accountability must be visible before an incident.

The product boundary comes next. """Cloud""" can describe virtual machines, hosted servers, storage, transit, a management panel, content acceleration, remote access or a bundle assembled from several suppliers. Each creates different failure paths. A virtual-machine service requires evidence about compute isolation, images, storage durability, network policy and console recovery. A transit service requires route policy, capacity, filtering and abuse handling. A managed hosting service adds privileged access, patch ownership and change control. The APNIC record cannot choose among these possibilities.

An orderable service should also have an inventory that can be reconciled. The customer needs account identifiers, resource identifiers, assigned addresses, service location, plan, renewal date, support entitlement and owner. That inventory is the base layer for automation. Provisioning scripts, billing records, monitoring and incident tools must refer to the same resources. When the commercial order says one thing, the portal another and the route table a third, automation can make the mismatch repeat faster rather than correct it.

Price alone is a poor substitute for this clarity. A low monthly charge can hide the labour required to understand a thinly documented service, maintain workarounds or coordinate several support parties. A higher charge can still be poor value if the contract gives little recovery or exit protection. The relevant comparison includes integration, monitoring, support effort, migration work and the cost of uncertainty. With Zhejiang Shiwei, the public evidence is too sparse to calculate that burden; a trial should be designed to expose it.

The trial should begin with one non-critical workload and a written acceptance sheet. Record the exact order, the contracting entity and the service domain. Capture which address is assigned and which autonomous system originates it. Measure reachability from the user networks that matter. Open a normal support request. Create a backup, restore it elsewhere and remove the test resource. Export bills and event records. The goal is not to manufacture an outage. It is to see whether the service leaves enough evidence for ordinary operations.

The provider's response to these requests can be more informative than marketing. A coherent operator should be able to explain which records are authoritative, who approves changes, what information a support case needs and which dependencies lie outside its control. Some answers may be confidential and available only under contract. That is acceptable. What matters is that the answers exist and are joined to accountable roles.

Without those materials, a profile should stop at network identity. It should not infer a compute fleet from an ASN, a support desk from an email address or a data centre from the word """cloud.""" The commercial service begins where a buyer can place an accountable order and follow the resulting resource through operation, failure and exit.

Automation is only as reliable as the records it joins

The topic of enterprise automation may seem remote from an autonomous system with no visible routes, but it is central to the assurance problem. Modern services are operated through repeated machine actions: create an account, provision a resource, assign an address, apply access policy, collect usage, issue a bill, detect an event, open a case, restore a backup and terminate a resource. Every action depends on records that identify the right customer, service, location and owner.

At its best, automation turns a well-defined service contract into repeatable control. An approved request creates a resource under the correct account. Configuration policy checks encryption and access settings. Monitoring attaches to the assigned endpoint. Billing reconciles the resource to an order. A support case carries the right identifiers and recent events. Deletion removes the resource and verifies that retained copies follow policy. The operator can show who or what made each change and whether it succeeded.

At its worst, automation hides uncertainty behind a polished portal. A button creates something, but the customer cannot tell which legal provider operates it, where data is stored or which network carries it. A dashboard reports """running""" while users cannot reach the service. A billing system continues after cancellation because the commercial and technical inventories diverge. A support form rejects an incident because its resource identifier does not match the account. These are not exotic artificial-intelligence failures. They are ordinary record failures amplified by software.

AS17774 provides one potential join key, but the current evidence does not connect it to a service resource. A buyer should not assume that an address received from a product branded SWCLOUD will originate from AS17774. It should record the address, query the origin and ask why if another network appears. The answer may be reasonable: a transit provider, hosting partner, content-delivery network or protection service may originate the route. The explanation must then be reflected in monitoring and escalation.

Account lifecycle deserves the same attention. Who verifies the customer? Which email controls password reset? Can more than one administrator be required for destructive changes? Are machine credentials separate from human accounts? What event record exists for privilege changes, address reassignment, plan changes and deletion? How long are those records available, and can the customer export them? None of these controls is established by the APNIC registration, but each determines whether automated operation is reviewable.

Automation also creates a responsibility boundary between provider and customer. The provider may automate host maintenance, network policy, capacity allocation and abuse controls. The customer may automate deployments, guest configuration, secrets, backups and scaling. A managed-service layer may move some tasks across the boundary. The contract and technical guide should agree on who owns each action. Otherwise both parties can believe the other is protecting a resource.

Metrics should follow accepted operations rather than decorative activity. Provisioning success means the requested resource is reachable and correctly configured, not merely that a job finished. Backup success means a representative restore works. Support response means a qualified owner engages, not that an automated acknowledgement arrives. Deletion success means access ends and retention follows the agreement. Route control means the expected origin is visible and unauthorised changes are detected. These measures turn automation into evidence.

For Zhejiang Shiwei, the public record cannot answer whether such systems exist. The useful conclusion is a design for verification. A customer should ask for the event history around a small trial, deliberately perform normal changes, compare the portal with observed network state and document every human handoff. If the records stay aligned, automation reduces effort. If they do not, the customer has discovered the supervision cost before putting a critical workload behind the name.

Data locality requires a chain of custody

The company name includes Zhejiang, the APNIC contacts point to Jinhua, and the domain registration gives Zhejiang as the registrant province. These are identity and contact facts. They are not data-locality commitments. No frozen source identifies a facility used by an attributable Zhejiang Shiwei service, promises that customer content remains in a named jurisdiction or describes replication, backup or support access.

That distinction is fundamental. The location of a company office is not necessarily the location of its servers. The registration country of an autonomous system is not a map of every router or customer workload. An IP geolocation result is an inference about network use, not proof of storage. The address serving a company domain can belong to a hosting supplier without saying where a proposed cloud resource will run. Locality becomes meaningful only when a specific data class is joined to a specific service, location and contractual rule.

A buyer should start with a data inventory. Production content, account details, access logs, support attachments, billing records, backups, monitoring telemetry, security events and deployment artefacts may all travel differently. For each class, record where the primary copy resides, where replicas and backups go, which parties can access it, what encryption applies, how long it remains and how deletion is confirmed. A broad phrase such as """hosted in Zhejiang""" cannot answer those questions.

The network path is another layer, not the final answer. If a customer resource is delivered through an address originated by AS17774, that would show Zhejiang Shiwei's registered network identity at the route origin. It would not prove that the storage system is in Zhejiang or that traffic never crosses another jurisdiction. If the route is originated by a partner, the partner's role must be included in the locality analysis. Private links, protection services, recursive DNS, software updates and support tools can introduce additional paths.

The legal chain matters alongside the technical one. The service agreement should name the operator and any processors or infrastructure suppliers. It should say whether the customer chooses a region, whether the provider may move data, how government or legal requests are handled, and what happens to retained copies after termination. Where a claim depends on a licence or filing, the buyer should verify the current document and the entity to which it applies. No such service-specific material was attributable in the frozen evidence.

The separate swcloud.io privacy policy illustrates why identity must come first. It discusses connection details, traffic information, DNS queries, cookies, outside services and disclosures. If the site were contractually linked to Zhejiang Shiwei, those terms would be relevant to a locality review. Because the link is absent, they cannot be used to fill the gap. The only responsible action is to request the policy that governs the actual order and confirm the legal party on it.

Locality claims also need operational testing. A customer can inspect the service endpoint and route origin, review account and region settings, examine backup destinations and trace where monitoring data is sent. It can ask support to explain which team and supplier can access a case attachment. It can delete a trial resource and request evidence of the applicable retention period. These checks will not reveal every physical movement, but they can test whether the service behaves consistently with the contract.

The goal is not to insist that every component stay in one city. Distributed operation may be necessary for resilience, protection or support. The goal is to make movement deliberate and accountable. A buyer may accept a cross-region backup, an outside support processor or a third-party transit network if the benefit and control are clear. What it should not accept is a locality conclusion derived from a company name.

Zhejiang is therefore part of the identity evidence, not yet an operating geography. The public record locates contacts and registration traces. A service-specific chain of custody must still establish where customer data, operational metadata and recovery copies live, who can reach them and how the buyer verifies the answer over time.

Support is a labour system, not an address in WHOIS

The APNIC entry publishes named administrative and technical contacts, a Jinhua telephone number and swcloud.com email addresses. Those contacts are useful for stewardship of an autonomous-system registration. They do not describe a customer support plan. Registry contact, abuse response, account assistance, network operations and application support are different functions, even when a small team covers several of them.

This difference becomes acute during an incident. A route-origin problem needs someone who can change network policy or coordinate an upstream. A lost account credential needs an identity process. A failed virtual machine, if such a product exists, needs a platform operator. A corrupted application may belong to the customer. A billing suspension needs a commercial owner. Sending every problem to the technical contact in a public registry can delay resolution and expose information to the wrong channel.

The frozen evidence does not publish Zhejiang Shiwei's support hours, languages, case system, severity levels, acknowledgement targets, escalation path or staffing depth. It does not show incident outcomes. Silence on those points should not be interpreted as poor support. It means support quality cannot be measured from public materials and must be established in the purchased service.

A useful support schedule names the owner for each failure class. It says how a case is opened when the portal itself is unreachable, which account roles may declare a high-severity incident, what evidence the provider expects and how an unresolved case escalates. It identifies the time zone and languages in which engineering help is available. It separates an automated receipt from engagement by someone able to act. It also explains how provider and customer teams coordinate when responsibility is uncertain.

The customer should test this schedule before production. A normal architecture question can reveal whether the desk understands the product. A harmless configuration problem can show how evidence is requested. A billing query can test the handoff to commercial staff. A route question can reveal whether network operations are reachable through the customer channel. The objective is not to trap the provider; it is to find the fastest shared method while stakes are low.

Labour appears in less dramatic tasks too. Someone must verify account details, approve sensitive changes, maintain documentation, investigate abuse, reconcile bills, update contact records and help with termination. Automation can route and record this work, but it cannot make unclear ownership disappear. If the service uses partners, the customer needs to know whether Zhejiang Shiwei coordinates them or expects the customer to open separate cases.

The stale-looking parts of a public record can themselves become a test. APNIC's named contacts date from 2018, and the autonomous-system record last changed in 2020. That does not mean the contacts are invalid; the registration remains marked active. A contracting review should nevertheless confirm that the company can receive messages at the published domain and that the service has a current support path distinct from registry maintenance. The failed attempt to obtain a usable page at swcloud.com makes that confirmation more important, not impossible.

Support accountability should also survive a security event. The buyer needs an authenticated way to report compromise, protect account access and preserve evidence. Public email may be appropriate for general network abuse but unsuitable for customer secrets. Emergency changes should require clear authority and leave an event history. After the incident, both parties should be able to reconstruct decisions and close temporary access.

The local-support question is thus not whether a phone number exists in Zhejiang. It is whether named people, queues and escalation rights can carry a customer problem from observation to resolution. AS17774 provides a contact starting point. Operating assurance requires the labour system around the actual service to be contracted, tested and kept current.

Recovery and exit expose every unresolved boundary

Recovery is where a vague provider identity becomes an operational liability. Restoring a service requires more than infrastructure. The customer needs valid account access, known resource ownership, usable backups, deployment materials, dependency information and support that can act on the right layer. If the legal entity, service domain and network operator have not been reconciled, a failure can become an argument over who owns the next step.

No public source in the frozen pack describes Zhejiang Shiwei's backup service, retention, redundancy, recovery objectives or exit terms. No claim about those capabilities is justified. A buyer must define its own recovery target and ask which provider features support it. The target should be expressed as an elapsed time and acceptable data loss for a named business function, not as a generic expectation that """the cloud""" is redundant.

A representative restore is the most valuable test. Create a small workload, protect its data, remove or isolate it and rebuild it using the documented process. Measure the full time, including identity approval, address assignment, dependency changes and validation. Confirm whether the recovered service appears under the expected route origin. Record which steps required provider labour and which the customer owned. A backup completion notice without a restore is only evidence that one automated action reported success.

Network recovery needs its own exercise. If a proposed service uses AS17774, monitor reachability and origin from relevant access networks. Ask how upstream failure is detected and escalated. Do not infer physical diversity from a list of carrier names, and do not infer absence of resilience from the current collector gap without first identifying the actual delivery network. If another ASN is used, include that operator in the test and the contact map.

Exit provides the final consistency check. The agreement should say how the customer terminates, how long resources and backups remain, how data can be exported, when billing stops and which records remain available afterwards. The customer should price transfer, transformation, parallel operation and engineering labour. Familiar protocols can make movement easier, but account, addressing, security and application dependencies still need rehearsal.

The trial should end with an actual export and deletion. Retrieve the data in a documented format, recreate the essential service elsewhere, remove the trial resources and verify the final bill. Preserve the contract, invoices, event records and support correspondence. If the provider relies on another operator, confirm which party handles retained data and closed-account enquiries.

These exercises do not presume that Zhejiang Shiwei will fail. They acknowledge that the public record cannot carry the recovery claim. A real provider should be assessed through the service it actually offers and the obligations it accepts. A registered ASN can help identify one network role, but recovery and exit prove whether all roles can work together when normal operation ends.

A practical acceptance sequence for AS17774 and any service behind it

The evidence supports a staged decision rather than a single confidence score. Each stage has a fact to verify, a boundary it does not cross and a reason to stop if the next join cannot be made.

First, settle identity. Obtain the legal name in Chinese and English, registration details, registered address, service-domain ownership and authority of the person signing. Reconcile those details with Zhejiang Shiwei Data Technology Co., Ltd., the company named by APNIC. Confirm whether SWCLOUD is a brand of that entity, whether swcloud.com is still its controlled domain and whether any other same-name domain belongs to it. Do not import terms from swcloud.io unless the company provides a verifiable link.

Second, settle the commercial boundary. Identify the exact service, plan, invoice issuer and agreement. List every party that supplies infrastructure, network access, software, payment or support. For each party, record the role and escalation route. Confirm what happens when a supplier fails or the relationship between supplier and seller changes. A buyer cannot manage concentration risk if the supply chain remains unnamed.

Third, settle the network boundary. Record every address assigned to the trial, the expected route origin and the reason for any difference from AS17774. Check announcements from more than one source and from the customer's own locations. Ask for upstream and route-security policy. Because RIPE found AS17774 unannounced in the frozen snapshot, any claim that it currently carries the service deserves fresh, service-specific evidence before acceptance.

Fourth, settle the resource record. Make the order, account, resource, address, location, owner and bill reconcile. Exercise provisioning, change and deletion. Export the event history. Confirm that automation fails visibly when a request is invalid and that a human can correct the underlying record. The test should measure accepted outcomes, not the number of completed jobs.

Fifth, settle data custody. Build a table for production data, account information, logs, support material, backups and monitoring. Identify location, processor, encryption control, retention and deletion for each. Compare contract with observed configuration. Treat Zhejiang contact details as identity evidence, not as proof of storage location.

Sixth, settle support. Open several low-risk cases and record acknowledgement, ownership, escalation and resolution quality. Verify the emergency route when the normal portal is unavailable. Confirm that network, account, security, billing and application questions reach the right owners. Make sure registry contacts are not the only apparent path.

Seventh, settle recovery. Restore representative data, rebuild access, test network reachability and validate the application. Measure the customer and provider labour required. Include a failure in an outside dependency if the service relies on one. A written redundancy claim is not equivalent to a completed recovery exercise.

Eighth, settle exit. Export, migrate and delete the trial. Check the closing bill and retention terms. Confirm which records remain available after access ends. Price the work while the deployment is small enough to move. Exit evidence disciplines procurement because it reveals which conveniences are really dependencies.

The stop conditions matter. If the legal service entity cannot be reconciled with the public identity, the buyer cannot know whose promises it is accepting. If assigned addresses and expected origins cannot be explained, network monitoring and abuse response will be unreliable. If data location or support ownership cannot be stated, regulated or critical workloads should wait. If restore and export cannot be demonstrated, the service should not become the only copy or only operating path for important data.

These conditions are not unusual demands reserved for an obscure provider. Large cloud platforms also divide responsibility and require customers to test architecture, support and exit. The difference is that a well-documented platform supplies more of the evidence in advance. Zhejiang Shiwei's sparse public surface shifts more discovery into direct diligence and increases the value of a small, measured trial.

The sequence also prevents a weak public record from becoming a permanent negative label. The company can answer each open question with current documents and observable service. A live route, a coherent contract, a support test and a successful restore would add evidence that the present research pass could not. The profile should remain capable of improvement when better evidence appears.

What can be said now

SWCLOUD Zhejiang Shiwei Data Technology Co., Ltd. is not an invented name assembled from a stray search result. APNIC's active record for AS17774 names the company directly, uses the SWCLOUD autonomous-system label and provides contacts in Jinhua, Zhejiang. The BTW directory carries the same link. The swcloud.com contact domain has a long-lived registration with a Zhejiang trace. That is a coherent public identity for a holder of internet-number resources.

The next claim cannot be made with the same confidence. RIPE's July 15 snapshot marked AS17774 unannounced and found no prefixes meeting its visibility threshold during the first half of the month. No current upstream, routed address surface or path behaviour can be attributed from the frozen sources. Historic routes attached to the number predate the current registration trail and were excluded from the company story.

Nor can a public cloud service be confidently attached. The contact domain did not provide a usable company site during review. The separate swcloud.io policy set describes a service under the same brand but does not name Zhejiang Shiwei or connect itself to AS17774. Its product, privacy, support and availability statements therefore remain outside the evidence boundary.

This leaves a conclusion that is restrained but operationally useful. The company has a verifiable network identity. Public evidence does not yet convert that identity into proof of a current, attributable cloud service or its quality. Buyers should neither dismiss the company because the record is thin nor supply missing facts from a same-name site. They should ask the service itself to produce the joins.

The decisive evidence would be ordinary and testable: a contract naming Zhejiang Shiwei, a verified service domain, assigned resources, an explained route origin, a data-custody schedule, a working support escalation, a measured restore and an executable exit. When those pieces agree, the SWCLOUD name can become part of operating assurance. Until then, AS17774 should be valued for what it actually proves: who is named in a network registration, and where the next questions must begin.