Summary

  • 6545 HOLDINGS LLC is publicly tied to AS197443, a RIPE-assigned autonomous system whose current holder is shown as NET-6545 6545 HOLDINGS LLC in RIPEstat's AS overview and whose public routing record shows two active prefixes: 153.76.6.0/24 and 2a06:9801:743::/48.
  • The current network evidence is real but narrow. The IPv4 /24 sits inside a GoCodeIT-managed 153.76.0.0/19 block, the IPv6 /48 is recorded directly against 6545 HOLDINGS LLC, both prefixes validate under RPKI, and public route-observation services point to GoCodeIT as the live upstream dependency.
  • The operating downgrade is not about whether a route exists. It is about what remains unproven: public rack location, owned hardware stock, multi-site restoration, support depth, billing continuity, customer data portability and the real capacity available behind the advertised routed space.

The service promise is virtual; the failure modes are physical

The useful way to read 6545 HOLDINGS LLC is to start with the mismatch that defines small hosting infrastructure. A customer buys something that feels abstract: a VPS, a bare-metal server, an IP block, a managed service, a place to put an application, or a network endpoint that can be reached from the rest of the internet. The invoice may describe cores, memory, bandwidth, support and an address range. The failure, when it arrives, is rarely abstract.

It is a router session dropping, a facility circuit going dark, a power feed failing, a spare part not being on the shelf, a route authorization being changed, a ticket queue waiting on one person, or a customer discovering that backup and migration were assumed rather than contracted.

For 6545 HOLDINGS LLC, the public record supports the existence of a small routed footprint but not a broad operating footprint. The company appears in RIPE public records as ORG-HL413-RIPE, with the name 6545 HOLDINGS LLC, a United States country code, registration number 5613549, the email [email protected], and the address 6545 Market Avenue N, Suite 100, Canton, Ohio, 44721, US in the organisation record. The same address appears in the abuse contact record for the network. That address is not evidence of a data-centre floor, cage, meet-me room or repair bench. It is a legal and contact surface. The infrastructure surface has to be inferred from routing, address space, upstreams and any customer-facing materials that can be found.

The public network evidence is unusually young. The AS197443 aut-num record shows NET-6545 as the AS name, ORG-HL413-RIPE as the organisation and ORG-LCTL2-RIPE as sponsoring organisation. It records creation on 2026-05-19 and last modification later the same day. The company therefore enters the routing record as a May 2026 operator, not as a long-running hoster with years of visible customer references under the same public name. That does not make the network illegitimate. It changes the diligence burden. Buyers should treat every promise about uptime, migration, stock and data location as something to be verified in a contract or service document, not as something proven by the existence of an ASN.

There is also a caution around the history of the number itself. RIPEstat's routing-status call for AS197443 can show older first-seen routing history for the numeric ASN. That long tail should not be read as operating history for 6545 HOLDINGS LLC, because the current public RIPE record for this holder is new and specific. In small-network analysis, numeric history and current holder history are not the same thing. The safe reading is that 6545 HOLDINGS LLC has a current routed footprint tied to the ASN from May 2026 onward, while older observations belong to the number's previous life or wider routing context.

What the routed footprint proves

The strongest public fact is straightforward: AS197443 is announced. RIPEstat's announced-prefixes view shows 153.76.6.0/24 and 2a06:9801:743::/48 as prefixes visible through 2026-07-12. The prefix overview for 153.76.6.0/24 names AS197443 as the origin and identifies the holder as NET-6545 6545 HOLDINGS LLC. The prefix overview for 2a06:9801:743::/48 does the same for IPv6. In plain terms, the network has a globally visible IPv4 /24 and a globally visible IPv6 /48.

That is enough for a small hosting surface. A /24 is the minimum size generally accepted as an independently visible IPv4 route on the global internet. It offers 256 IPv4 addresses before reserved, management, gateway, customer, monitoring and anti-abuse uses reduce the practically sellable pool. For a small VPS host, proxy host, managed-service provider or bespoke infrastructure shop, a single /24 can support a meaningful customer base if addresses are carefully rationed. It cannot support a large public cloud without additional address supply, address-sharing architecture or upstream-provided pools.

The IPv6 /48 is much larger in address count, but IPv6 abundance does not solve IPv4 scarcity, support labour or hardware stock.

The route authorization picture is also positive. RIPEstat's RPKI validation calls show 153.76.6.0/24 as valid for origin AS197443 and 2a06:9801:743::/48 as valid for origin AS197443. That matters. A small network with invalid RPKI would face avoidable reachability loss as more networks filter invalid routes. 6545 HOLDINGS LLC does not appear to have that specific problem on the two active prefixes. The routing is small, but it is not obviously an invalid-origin announcement.

The public route objects line up with the same story. The RIPEstat whois view for 153.76.6.0/24 shows a route entity for 153.76.6.0/24 with origin AS197443, created on 2026-05-20, and also shows the less-specific 153.76.0.0/19 associated with GoCodeIT. The IPv6 whois view shows 2a06:9801:743::/48 assigned to 6545 HOLDINGS LLC and a route6 entity for AS197443 created on 2026-05-19. The timing is coherent: organisation, ASN, IPv6 assignment and IPv4 route authorization appear within the same May 2026 start window.

The good news should not be inflated. An ASN, two prefixes and valid RPKI prove internet reachability. They do not prove the existence of a specific facility, the number of racks, the ownership of servers, the diversity of power, the availability of spare drives, the number of support staff or the customer migration path. A public routed footprint is a necessary condition for many hosting services. It is not a full operating proof.

The address space points to dependency, not self-sufficiency

The IPv4 side is the clearest dependency. RIPEstat's public record for 153.76.6.0/24 shows the less-specific block as 153.76.0.0/19, netname CA-GOCODEIT-19910923, country CA, organisation ORG-GI100-RIPE, and GoCodeIT maintainers on the lower, domains and routes fields. The route object for 6545's /24 exists, but the less-specific block is GoCodeIT's space. That means 6545's IPv4 capacity depends on the continued delegation, route permission and commercial relationship around a slice of GoCodeIT-managed address space.

This is common in hosting. Many small providers do not own or hold a large IPv4 allocation. They rent or receive delegated space from an upstream, facility partner, IP broker, sponsor or network provider. The economics are rational: a young hoster can begin selling service without first obtaining scarce address assets. The operational consequence is just as real. If the parent allocation, route object, billing relationship or upstream routing policy changes, customers using that /24 may face renumbering, routing loss or a constrained migration window. A hosted virtual machine can be moved faster than a public reputation tied to an IP address.

Mail delivery reputation, firewall allow lists, DNS glue, customer ACLs and API callbacks can all make a small IPv4 block operationally sticky.

The IPv6 side is cleaner as a record, but not necessarily as a customer promise. The IPv6 public record names SFFF-HOLDINGS-20260518, describes 6545 HOLDINGS LLC, uses the United States country field and points to the sponsoring Lagrange maintainer. A /48 is more than enough for generous IPv6 assignments to customers. Yet IPv6 capacity is not a substitute for the physical and support layers that make hosted service recoverable. If an application still needs IPv4, if a customer requires a particular geolocation, or if a compliance team needs a firm processing location, the IPv6 /48 does not answer those questions by itself.

The public record also shows the role of Lagrange Cloud Technologies Limited. The AS197443 record lists ORG-LCTL2-RIPE as sponsoring organisation, and the Lagrange organisation record identifies Lagrange Cloud Technologies Limited as a UK LIR with RIPE contact and maintainer references. Sponsorship is not a weakness by itself. It is part of the normal RIPE administrative structure for networks that receive resources through a sponsoring LIR. But it is another boundary. If a hosted service customer assumes that all address, route and registry matters are controlled solely inside 6545 HOLDINGS LLC, the public record says the situation is more layered.

Layering changes the failure path. A pure hardware failure can be solved by replacing a server. A route permission failure requires the people with authority over route objects and parent resources to act. A billing dispute can become a reachability problem if it touches upstream transit, delegated address space or sponsorship. A compliance question can become harder if the registered company, address resource sponsor, observed upstream and exchange presence point to different jurisdictions. For buyers of low-cost hosting, those are not abstract governance matters.

They are the difference between a recoverable incident and a forced renumbering exercise.

The upstream picture is useful, but not as simple as one line

The public routing picture around AS197443 has three layers. The AS197443 RIPE record lists import and export policy with AS35661 and AS6939. RIPEstat identifies AS35661 as VIRTUASYS-EU VIRTUA SYSTEMS SAS and AS6939 as Hurricane Electric. At the same time, RIPEstat's ASN-neighbours view shows observed neighbours AS835 and AS62513, both of which RIPEstat names as GoCodeIT in separate overviews for AS835 and AS62513. IPinfo's AS197443 page also shows GoCodeIT as the listed upstream and shows no downstreams.

That divergence should be treated as a timing and evidence issue, not as a scandal. Registry policy can lag actual BGP sessions; public BGP observation can miss private or low-visibility sessions; small networks can change upstreams quickly while entities are updated later; and a route may be seen through a parent route or delegated block provider even when a separate policy reference remains. The right conclusion is not that 6545 HOLDINGS LLC has four fully diverse upstreams. The right conclusion is that public evidence does not prove robust transit diversity.

The strongest observed dependency as of the current public views is GoCodeIT, while the RIPE policy record still names Virtua Systems and Hurricane Electric.

This matters because transit diversity is not the same as a list of network names. True diversity requires separate physical cross-connects, separate routers, separate upstream contracts, different failure domains and enough routing policy discipline to keep a bad session from becoming a customer outage. A small hoster can show two ASNs in an import policy and still have one actual facility handoff. It can also have one upstream that itself has strong backbone diversity. Customers cannot tell from the public record which of those is true here.

The assignment's main failure path therefore lands on upstream and provider-contract risk. If AS197443 depends operationally on GoCodeIT for IPv4 address space and observed transit, the customer impact of a GoCodeIT-side change could be larger than the customer impact of a single 6545 server failure. A block-level issue can affect every customer using addresses in the /24. A route-object removal can erase reachability faster than a support queue can explain it. A provider contract change can make migration necessary even when all disks are intact.

The Sibir-IX signal adds another layer rather than a full location answer. Hurricane Electric's Sibir-IX exchange page lists AS197443 with 185.1.81.28 among Sibir-IX members, and the exchange page identifies Sibir-IX as located in Krasnoyarsk, Russian Federation. That is useful evidence of an exchange presence or route-server adjacency. It is not proof that customer servers sit in Krasnoyarsk, not proof that 6545 owns racks there, and not proof that customer data is stored there. It is enough to make locality questions important. A customer buying a service from a US LLC with Canadian IPv4 parent space, UK sponsorship and a Russian exchange signal should ask for precise service-location terms before assuming where data or traffic will reside.

A public domain without a public product surface

The public records list [email protected], and IPinfo points to 6545.ltd as the ASN domain. A quick DNS lookup during this review showed Cloudflare nameservers and Cloudflare-routed MX records for the domain, but no A or AAAA answer for a public website. A simple HTTPS request to the root did not return a usable public site. That does not prove the business is inactive. A hoster may operate through private sales, broker channels, reseller relationships, Discord or Telegram communities, marketplace listings, direct invoices, or customer panels on another domain. But for a public buyer, it removes an ordinary verification channel: there is no visible product page, service description, terms page, support status page, facility page, network map, SLA page or migration guide under the listed domain.

That absence changes the article's stance. If a company advertises cloud or hosting capacity on a visible website, the analysis can test claims against the site: locations, plans, bandwidth caps, support promises, abuse handling and backup language. For 6545 HOLDINGS LLC, the public network record does most of the evidentiary work, while the customer-facing commercial surface remains thin. The right downgrade is therefore operating-evidence downgrade, not network-existence downgrade. AS197443 exists. The visible product wrapper is not enough to know what a customer is actually buying.

The public address reinforces that caution. The address in the RIPE organisation record is the same North Canton suite used by Ohio statutory-representation providers, as shown on public pages for Ohio Registered Agent and Ohio Statutory Agent. A statutory-service address is normal for many LLCs. It is also not an infrastructure site. If 6545 HOLDINGS LLC has racks, cages or leased servers, they are elsewhere. A customer should therefore separate legal contact from operating location. The legal contact can receive notices; it does not reboot a router, swap a failed NVMe drive or move data out of a failed rack.

For hosting economics, this is the important distinction. Thin public presence can be efficient. A small operator can keep overhead low, rent upstream infrastructure, automate provisioning and undercut larger providers. That same efficiency can concentrate risk. If the public company footprint consists of a legal address, an email domain, an ASN and two routed prefixes, buyers should not assume a broad support bench or deep hardware inventory. They should ask who answers incidents, who has hands in the facility, where spares are stored, how many sites can take a restored workload, and what happens if the upstream relationship changes.

Installed capacity is not the same as usable capacity

The internet sees an origin ASN and two prefixes. Customers experience CPU, memory, disk, I/O, bandwidth, support and time. The difference between those two views is where small hosters can either be excellent or fragile.

The IPv4 /24 is the most concrete installed asset visible from outside. It can be routed, validated and observed. It can support customers. It also places a hard ceiling on a common selling constraint. A hoster selling one public IPv4 address per VPS will exhaust a /24 quickly. A hoster using NAT, IPv6-first service, reverse proxies or shared ingress can stretch it. A bare-metal provider may reserve more addresses per customer for management, virtualization, failover, BMC access or routed subnets. A managed-service provider may use fewer direct customer IPs but more internal monitoring and control addresses.

Without product terms, no one can translate the /24 into a customer count.

The IPv6 /48 gives a different impression because the address count is vast. A /48 can be subdivided into many customer /64s or routed subnets. But the abundance of IPv6 addresses can hide the bottleneck that matters: physical capacity. How many servers are actually installed? Are they owned, leased or resale nodes? How much power is committed? Are customers on one rack, one cage, one city, or one upstream's hosted environment? Are disks local only, replicated in the same building, replicated to another site, or left to the customer? Are backups included, optional, or outside the provider's responsibility?

The public records do not answer these questions.

The support side is just as important as hardware. In hosting, a repair window is a product feature whether or not it is written that way. A drive failure at 03:00 is a different event if there are on-site hands, a spare pool, remote console access, tested provisioning images and a clear escalation path. It is a different event if the operator must wait for a landlord, a remote-hands queue, a reseller, a billing department or one engineer in another time zone. Public ASN evidence cannot distinguish between those worlds. Customers have to ask.

The route record tells us the service has an internet edge. It does not tell us the control plane. Does 6545 HOLDINGS LLC maintain its own routers? Does it use virtual routing on a provider platform? Does GoCodeIT originate or carry the route on its behalf? Are BGP sessions under 6545's day-to-day control, or are they ticket-driven through another party? If a route flap occurs, who can see it and who can fix it? The answer changes both outage duration and customer communication. A small provider with excellent operational control can outperform a larger provider with indifferent support.

A small provider without direct control can leave customers waiting while several parties coordinate.

Data locality is not solved by a company country field

The country field in the 6545 organisation record is US. The IPv4 parent record says CA-GOCODEIT-19910923 and country CA. The sponsoring organisation is a UK LIR. The Sibir-IX page places an AS197443 exchange entry in Krasnoyarsk. IPinfo's geolocation section shows the IPv4 share as Canada, while warning that the legally based country may not correspond to where IP addresses are used. These are not contradictions if read carefully. They are different layers of the same network story.

For customers, the risk is assuming one layer answers every locality question. A US LLC does not guarantee US hosting. Canadian-address metadata does not guarantee Canadian physical servers. A Russian exchange presence does not guarantee Russian data storage. UK sponsorship does not guarantee UK service. Internet routing is a control plane, not a complete map of disks. But when public layers point across several jurisdictions, the customer should not rely on intuition.

They should require a location statement, a subprocessor statement if applicable, a data-transfer position, and a migration right if the provider moves service to another facility.

This is especially important for regulated or reputation-sensitive customers. A customer handling health, finance, identity, legal, public-sector or export-controlled data may need a specific processing country. A gaming server, proxy node, scraping service, mail relay or crypto-adjacent workload may care less about data protection law but more about IP reputation, sanctions exposure, local filtering and abuse handling. A latency-sensitive customer may care about actual path and exchange proximity. The same 6545 network can be acceptable for one use and unsuitable for another.

The correct standard is not to demand that every small provider publish a hyperscale-style compliance library. It is to match the risk to the promise. If the service is low-cost ephemeral VPS capacity with no locality promise, the buyer should plan for self-managed backups and easy migration. If the service is sold as managed hosting for production workloads, the buyer should expect clear locality, backup, support and incident terms. If the service is sold into a sensitive jurisdiction, the buyer should expect more than a country field in a registry record.

The most likely failure paths

The first failure path is upstream reachability. The observed BGP neighbours and IPinfo upstream view point to GoCodeIT. The IPv4 parent block also points to GoCodeIT. If GoCodeIT changes route policy, filters AS197443, withdraws a delegated route, experiences a facility problem, or terminates a commercial relationship, 6545 customers using the IPv4 /24 could lose reachability even if their servers are still powered. RPKI validity helps protect against origin filtering, but it does not protect against upstream withdrawal or contract failure.

The second failure path is address continuity. A /24 is small enough that every address may become valuable. If a customer builds mail reputation, allow lists, API access, VPN peers or branded DNS around a specific address in 153.76.6.0/24, migration to a new block becomes a customer-side project. A good provider can reduce that pain with notice, temporary dual-running, reverse DNS coordination and support. A thin provider may simply announce a change and leave customers to adjust. The public record gives no assurance either way.

The third failure path is rack or facility concentration. Nothing in the public evidence proves multiple sites. A single rack can host many small VPS customers. A single upstream-provided environment can support many seemingly independent accounts. If that rack loses power, if a top-of-rack switch fails, if remote hands are delayed, or if the facility has a cooling incident, the impact can look like a full provider outage. Customers need to know whether workloads can be restored elsewhere, whether backups are off-rack and whether the provider has capacity to absorb a site failure.

The fourth failure path is hardware stock. Small hosting providers often run close to efficient utilization. That can produce attractive pricing. It can also mean that a server failure has no immediate spare, or that a motherboard, RAID controller, SSD, PSU or NIC replacement waits on a third party. If 6545 HOLDINGS LLC is selling bare-metal or VPS capacity, the repair window depends on spare parts and access to the physical environment. The public route record says nothing about spare stock.

The fifth failure path is support depth. The public record gives an abuse and legal email. It does not show a 24/7 network operations contact, status page, customer portal, SLA, escalation tree or support phone number for hosting incidents. That does not mean support is absent. It means support is not publicly evidenced. For low-cost hosting, the difference between an excellent small operator and a fragile small operator is often visible only after the first incident. Buyers should test support before production dependence, not during the outage that matters.

The sixth failure path is billing and provider-contract continuity. A small network that relies on a sponsor, delegated address space and an upstream provider can be operationally sound if contracts are stable. It can become fragile if any of those relationships are month-to-month, prepaid, reseller-based, disputed or undocumented from the customer's point of view. The customer sees a hosting invoice; the actual service may depend on several invoices upstream. If one breaks, the customer may not have standing with the party that can restore service.

Who is affected when this system fails

The most exposed customers are those who treat 6545 capacity as stable infrastructure while buying it as commodity capacity. A hobby project that can be rebuilt from a Git repository and a backup may tolerate a small provider's thin public footprint. A production SaaS service, payment-adjacent application, mail service, VPN endpoint, customer database, game backend or managed client site has a different risk profile. The failure may not just be downtime. It may be address reputation loss, support silence, backup gaps, compliance uncertainty or a forced move under time pressure.

Developers are affected differently from business owners. A developer may be able to rebuild quickly if they have Terraform, images, backups and DNS control. A business owner may only know that the site is down and the ticket is unanswered. A reseller or managed-service customer may face a reputational problem even though the root dependency is upstream of them. If 6545 capacity is resold through another brand, the end customer may not know AS197443 exists until a traceroute or outage report exposes it.

There is also an abuse-handling dimension. Small routed blocks can become magnets for high-churn workloads: proxies, scraping, scanners, grey-market mail, VPN resale, crypto dashboards or trial-account abuse. If a /24 gains poor reputation, clean customers can suffer collateral damage through blacklists, blocked payment APIs or mail-delivery problems. Public records show legal and abuse contact fields, but not enforcement practice. A hoster's ability to keep bad workloads off a small block is part of its usable capacity. One noisy customer can consume more operational attention than dozens of quiet customers.

For counterparties, the question is not whether to avoid 6545 HOLDINGS LLC outright. The question is what level of dependence is appropriate. The current public evidence supports experimental, secondary, non-critical or carefully backed-up workloads better than it supports unqualified production dependence. A customer can use a small provider responsibly if they keep independent backups, maintain DNS control, avoid address lock-in, document rebuild steps and avoid storing the only live copy of important data on the provider's disks.

What would strengthen the case

The evidence bar is practical. 6545 HOLDINGS LLC could materially improve public confidence without revealing sensitive details. A short network page could list current service locations at city level, upstream categories, maintenance notice practices and abuse contact expectations. A status page could show historical incidents and maintenance windows. Terms could state backup scope, data locality, support response targets, IP-address change rights and customer migration obligations. A looking-glass page or route transparency page could show BGP sessions without exposing private contracts.

Even a plain statement that service is resale, colocation-based, dedicated-server-based or cloud-platform-based would reduce ambiguity.

The most valuable addition would be a recovery statement. Customers do not need to know every rack number. They need to know what happens after a rack, upstream, hardware, support, billing or provider-contract failure. Can a VM be restored to another host? In what time window? Are backups included by default? Are they off-site? Can customers export images? How much notice is given before IP renumbering? What happens if a delegated IP block is withdrawn? Who can approve emergency route changes? Those answers separate a small but serious infrastructure provider from a thin pass-through operation.

Transit diversity would also benefit from clarification. The public record currently mixes registry policy references to Virtua Systems and Hurricane Electric with observed GoCodeIT dependencies. That may be harmless and temporary. It may reflect a planned routing design that is not fully visible. It may also mean actual diversity is narrower than a quick glance suggests. A customer should ask whether production traffic has more than one independent upstream today, whether those upstreams enter through separate routers and whether the IPv4 /24 can remain reachable if GoCodeIT is unavailable.

The same question should be asked at the customer-change layer. If a customer has to move away from 6545 capacity, the important details are not only whether data can be downloaded, but whether the move can happen while routes, reverse DNS, firewall allow lists and support access are still available. A useful customer agreement would state how long an address remains active after cancellation, whether emergency exports are allowed during a billing dispute, how reverse DNS is changed, and whether the provider will support temporary dual-running while a service is renumbered.

Those terms are mundane, but they decide whether an infrastructure dependency can be exited cleanly. In a small-provider environment, a graceful exit plan is part of resilience because it gives the customer a recovery path even when the provider's own repair path is slow.

Facility disclosure matters because the service category is physical at the bottom. If the company operates at a single leased rack, that can be acceptable for low-cost workloads if disclosed. If it operates across multiple sites, that would improve the resilience story. If it resells another provider's servers, that may still be useful if the reseller adds support, billing and migration value. What is not useful is ambiguity that lets a buyer imagine a larger footprint than the public record proves.

The operating-status call

The operating-status call is a cautious live-network classification with an operating-evidence downgrade. 6545 HOLDINGS LLC should not be dismissed as empty: AS197443 is visible, its two active prefixes are recorded, and both prefixes validate under RPKI. The IPv4 route is seen with broad RIPE RIS visibility, and public secondary views such as IPinfo also list 6545 HOLDINGS LLC for the /24, with GoCodeIT as upstream. The network layer has enough evidence to support a company research article.

But the hosted-capacity claim should be held to a lower confidence level than the route-existence claim. Public evidence does not prove customer count, customer contracts, facility footprint, rack ownership, multi-site recovery, spare stock, support depth or data-portability practice. The company's listed domain does not present a clear public product surface. The legal address is not an operating site. The IPv4 block depends on GoCodeIT-managed space. The observed upstream dependency also points to GoCodeIT. The Sibir-IX signal raises locality questions without answering them.

That makes 6545 HOLDINGS LLC a useful case study in hosting economics. The smallest sellable unit in the market can look like a server plan or a monthly invoice, but the actual service is made of dependencies: sponsorship, address rights, route objects, upstreams, racks, power, remote hands, parts, abuse handling and customer migration. The lower the price and the thinner the public footprint, the more those dependencies matter. A buyer can still choose the service.

The buyer should choose it with the right mental picture: not as abstract cloud capacity floating above the physical world, but as a young, small, route-visible network whose real resilience depends on contracts and repair windows that are not yet public.

The final judgment is therefore balanced. For non-critical workloads, lab environments, short-lived deployments or customers with strong backups and low locality needs, the public evidence may be sufficient to begin a limited engagement. For production workloads, regulated data, address-sensitive services, mail, customer-facing managed hosting or any service that cannot tolerate abrupt renumbering, the unanswered questions are material.

Before using 6545 HOLDINGS LLC as primary infrastructure, a buyer should obtain written answers on facility location, upstream diversity, backup responsibility, support coverage, hardware replacement, IP-address continuity, export rights and notice periods. Until those answers are visible, the network is real, but the resilience claim remains unproven.