Connectivity Inc makes a local connectivity bill depend on upstream routes and field repair

Summary

• Connectivity Inc was a local-search and customer-intelligence software business, not a documented regional access provider. Its current site sells listings, review and data services; historical court and financing records describe YellowBot, advertising, data sales and hosted web applications rather than fibre, fixed wireless or household internet plans.
• The network behind that software was nevertheless real. ARIN assigned Solfo Inc, Connectivity's former name, AS53582, a /22 IPv4 block and a /45 IPv6 block. PeeringDB lists the network at One Wilshire and Telecom Center LA, with a 1Gbps Any2West port and a content-network classification.
• Present operating evidence is negative. RIPE's routing view showed no IPv4 or IPv6 announcements, no observed neighbours and no visible address space for AS53582 on 10 July 2026; its last observed route was in September 2025. The PeeringDB traffic, facility and exchange details are substantially older and cannot establish a live network today.
• The economically relevant failure paths were therefore colocation power, a router or optic failure, a cross-connect or metro-fibre fault, an upstream withdrawal and a shortage of authorised remote hands. No public evidence establishes access plant, towers, poles, customer-premises equipment, a regional service footprint or field crews serving broadband subscribers.

The name points to broadband, but the evidence points to content

There are two ways to read the word connectivity in this company's history, and only one is supported by the public evidence. The first is the ordinary telecommunications meaning: a company connects homes or businesses to the internet through fibre, fixed wireless, cable or another access technology. That reading implies a geographic service area, installable addresses, customer drops, poles or conduit, network electronics near subscribers, retail plans and a repair organisation that can reach damaged plant.

The second meaning is the one Connectivity Inc used commercially. Its product connected businesses with information about their customers. The current company site presents listing management, review management, data licensing, social-lead capture and customer activation. It says the platform serves more than 10,000 businesses. The site's description of listing management is about correcting business details across search engines, maps and online listings. Its privacy policy describes cloud-based reputation management, business-listings management and customer-relationship services. None of those pages offers an internet-access plan, an address checker, an installation charge, a speed tier or a service-level commitment for a data circuit.

That is not merely a distinction in marketing language. It changes the entire physical system that should be assessed. A regional broadband provider owns or leases a path from a network edge toward many customer premises. A content company can own a comparatively small set of routers and servers inside carrier-neutral facilities, buy upstream transit, peer with selected networks and deliver an application over access networks operated by other companies. Both depend on fibre and electricity. Only the first carries the local access obligation.

Connectivity belongs in the second group on the available evidence. Its 2015 customer agreement identifies a Delaware corporation based at 100 East Tujunga Avenue in Burbank and describes two proprietary products: Listings Management and an Opinion Monitoring System. The agreement concerns use of those online services and associated business data. It does not contract to transmit a customer's general internet traffic.

An earlier federal court record is even clearer. In a 2011 patent dispute, the court described Solfo Inc's YellowBot website as an online business directory. It said Solfo earned revenue from advertising and the sale of information gathered from other websites, maintained its only office in Burbank, employed eight full-time staff in California and hosted the Solfo and YellowBot computers in Los Angeles County. The record concerns a different legal question and is historical, but it provides unusually concrete evidence of what the company did and where its computing was located.

The corporate narrative continued in the same direction. A 2014 financing report described Connectivity as a customer-intelligence software provider, the parent of YellowBot and Weblocal, and the renamed Solfo. It reported a $6.35 million round and more than 92,000 paid business accounts. In 2016, SweetIQ announced that it had acquired Connectivity's local-marketing division, describing the acquired operation as a direct-to-business local-marketing concern working with more than 20,000 physical locations. These figures refer to software accounts or marketing locations, not premises connected to a Connectivity access network.

This distinction should govern every later inference. A business can have tens of thousands of accounts and still occupy only a few racks. It can reach users across North America without owning a single residential drop. It can register an autonomous system because it needs independent routing for its websites, not because it sells transit or broadband. Connectivity's name, customer count and autonomous system are therefore not cumulative proof of a regional ISP. They describe a software company that had reason to operate content infrastructure.

AS53582 was a real network resource, not a broadband licence

The strongest evidence that Connectivity controlled internet infrastructure is the ARIN registration for AS53582. ARIN names the autonomous system SOLFO, gives a registration date of 23 June 2010 and links it to Solfo Inc in Burbank. The same record carries Solfo technical, network-operations and abuse contacts. Separate ARIN records assign Solfo the 199.15.176.0/22 IPv4 block and the 2620:101:d000::/45 IPv6 block. Those are direct number-resource records, not a third party's guess based on a company name.

An autonomous system number has a precise but limited meaning. ARIN defines an autonomous system as one or more IP prefixes operated under a single, clearly defined routing policy, and says the number allows an operator to exchange routing information with other networks. It does not say that the holder provides retail internet access. Universities, banks, cloud platforms, government agencies and content companies can all need an independent routing identity.

ARIN's own policy is explicit about the next limit. Registration does not guarantee that a prefix will be routed by any operator. The Number Resource Policy Manual separates the administrative assignment of number resources from their public reachability. That difference is central to Connectivity in 2026: the registrations remain, but the autonomous system is not visible as a current origin in the public routing data examined here.

Historical interconnection information fills in the original purpose. PeeringDB's AS53582 entry calls the network Connectivity Inc, lists Solfo, YellowBot and LocalRobot as alternate names and classifies it as Content. That is the database's category for a network delivering its own material, rather than an access carrier connecting end users. The entry claims ten IPv4 prefixes, one IPv6 prefix, balanced traffic of 1-5Gbps and a North American scope. It also advertises an open peering policy.

Those claims are consistent with a web publisher that wanted lower delivery cost and better control over how traffic reached users. A content network with enough page views can buy transit from one or more upstream carriers while exchanging traffic directly with willing networks at an internet exchange. Direct exchange can shorten the path to a consumer ISP, reduce the portion of traffic billed as transit and provide another logical route. A 1-5Gbps traffic band is entirely plausible for a group of busy local-search websites. It says nothing about homes passed, retail subscribers or access-network revenue.

The dates matter as much as the values. PeeringDB shows that the general network entry was last updated in July 2022. The listed public-exchange details were last updated in March 2016, and the facility records in the entry were also last changed in 2016. PeeringDB describes itself as a freely available, user-maintained database. It is highly useful for finding where operators say they can interconnect, but an old entry is not a live telemetry feed and its word Operational is not equivalent to a currently visible BGP announcement.

The correct conclusion is narrower than either extreme. AS53582 was not a decorative registration: historical route observations, address allocations, facility records and a public-exchange port form a coherent operating footprint. It also was not a regional access network. The public evidence establishes a content-serving autonomous system that was built to support the Solfo and Connectivity web properties.

Two downtown buildings defined the physical operating surface

PeeringDB places AS53582 in two Los Angeles facilities: CoreSite LA1 at One Wilshire and Telecom Center LA. It also records a 1Gbps connection to Any2West with IPv4 address 206.72.210.92 and IPv6 address 2001:504:13::92. The facility entries do not disclose rack count, power draw, server count, cross-connect inventory or whether Connectivity leased space directly or bought service from a colocation supplier. They nevertheless give the best public boundary around the company's physical network.

One Wilshire is not an abstract point on a peering map. It is a carrier hotel at 624 South Grand Avenue in downtown Los Angeles. The building's own description says its meet-me room is operated by CoreSite and provides access to more than 250 network service providers, cloud services, domestic and international carriers, and lit and dark fibre. CoreSite describes LA1 as one of the world's most densely interconnected data centres. A network present there can order short physical cross-connects to carriers and exchange infrastructure instead of extending a dedicated long route to every counterparty.

Telecom Center LA is around the corner at 530 West 6th Street. The Downtown Center Business Improvement District describes it as a data-centre and telecommunications building with direct connectivity to One Wilshire. PeeringDB currently lists only ten networks in the building, but the facility offers another place from which AS53582 historically said it could interconnect. Because the two buildings are close, moving traffic between them can be cheap and operationally convenient. Proximity is not the same thing as geographic independence.

That final point is important. Two facility names can produce an appearance of redundancy while sharing a small downtown failure domain. The buildings can use different utility feeds, generators, risers and operators, yet the route between them may pass through common streets, ducts, manholes or meet-me infrastructure. A network can also have equipment in both buildings but depend on one border router, one upstream contract or one fibre provider. No public Connectivity diagram identifies entrance paths, carrier names, router pairs or common points of failure.

The Any2West record supplies another piece of physical context. CoreSite says Any2Exchange connects networks at its facilities and offers ports at several speeds. A port is a real interface on an exchange switch, reached through a cross-connect and a router owned or controlled by the participant. Connectivity's listed 1Gbps port therefore implies at least a router interface, an optic or electrical handoff, a cable path and a commercial relationship with the exchange or a supplier.

It does not establish one gigabit per second of sustained traffic, one gigabit of upstream transit or a one-gigabit customer product. Port speed is installed interface capacity. Actual traffic depends on peer sessions, routes accepted, remote network policy, server demand and the health of every component between application and exchange. PeeringDB's broader 1-5Gbps traffic statement is self-reported and older than the present routing withdrawal. Neither value should be treated as current usable capacity.

The court's statement that the host computers were in Los Angeles County aligns with this facility evidence. Burbank was the office and corporate address; downtown Los Angeles was the documented interconnection area. The distance between them is modest, but the ownership boundary is sharp. Connectivity could administer servers and routers, while building owners, colocation operators, fibre carriers, the exchange operator and the electric utility controlled much of the environment that made those machines reachable.

The local bill was a rack-and-route bill, not a last-mile bill

For a retail ISP, the dominant physical bill often begins at the street: poles, trenching, conduit, towers, drops, customer equipment and technicians distributed across a service territory. Connectivity's documented bill began inside a carrier hotel. It likely combined rack or cage space, power, cooling, cross-connects, exchange access, metro transport, internet transit, hardware and labour. The precise contracts and amounts are not public, so the components can be identified without inventing a budget.

The rack is only the first layer. A server serving YellowBot needs power and cooling. A top-of-rack switch needs a path to a border router. The router needs interfaces toward upstream transit or peers. Each interconnection requires an optic, cable and configured session. A second facility requires transport between sites or an independent copy of the application and data. A domain needs authoritative name service, certificates and application health beyond the network itself. If any single element is unique, the physical system can be less resilient than the number of vendors suggests.

Peering changes the variable portion of that bill. When two autonomous systems exchange traffic directly, they can avoid sending that traffic through a paid transit path. CoreSite describes Any2 peering as a way to shorten routes and exchange traffic directly. For a content site, the value depends on traffic volume and which consumer networks are present. An exchange full of potential peers does not save money automatically. Connectivity needed active BGP sessions, acceptable traffic ratios, enough demand toward each peer and a fallback route for every destination not reached directly.

Transit remained essential. Public peering normally covers only the peer's network and its customers, not the entire internet. A content company still needs one or more upstreams willing to carry traffic to all other destinations and to propagate its prefixes. The upstream also carries inbound requests from networks with which the company does not peer. The autonomous system becomes publicly useful only when its route is accepted and propagated.

This is where the title's upstream dependency becomes literal. Connectivity may have owned the 199.15.176.0/22 registration and the router originating it, but it could not make the block globally reachable alone. Upstream carriers and peers had to accept and announce paths. Filters, expired routing records, contract changes, a disabled session or a physical fault could make registered addresses disappear. ARIN could still show the block as active while users had no route to it.

Field repair also takes a different form inside a carrier hotel. There is no evidence of Connectivity crews splicing neighbourhood fibre. The relevant hands would replace a failed optic, move a cross-connect, reseat a line card, restore power to a cabinet, inspect a fibre patch or connect a console cable. Those tasks may be performed by the company's staff, a colocation provider's remote-hands team or a specialist contractor. Response time depends on access authorisation, spare parts, site staffing and the service contract, none of which appears in the public record.

The result is a small but consequential physical economy. A web company can avoid the enormous capital burden of a regional access build by locating in an interconnected building. In return, it accepts recurring charges and concentrates operational risk in a few rooms, cross-connects and people. Connectivity's network footprint appears to have followed exactly that logic.

Registered capacity and usable capacity diverged

Several public values can be mistaken for capacity: a /22 allocation, a /45 IPv6 allocation, ten claimed IPv4 prefixes, one claimed IPv6 prefix, a 1Gbps exchange port and 1-5Gbps of stated traffic. They describe different things and cannot be added together.

The address blocks describe numbering space. The IPv4 /22 contains 1,024 addresses in arithmetic terms, although network design, reservation, filtering and actual assignments determine how many can host services. The IPv6 /45 is vastly larger in address count but does not imply more throughput. Addresses identify endpoints; they do not move bits without a route.

The exchange port describes the upper line rate of one interface. Protocol overhead and traffic direction reduce practical payload, while peer policy limits which destinations can use it. A content network might send substantial outbound responses and receive much smaller inbound requests, despite PeeringDB's old balanced-traffic label. An exchange port cannot replace transit unless the exchange provides paths to every required network under acceptable policy.

The claimed number of prefixes is especially difficult to reconcile with observed history. RIPE's routing-history view for AS53582 shows five origin prefixes over the life of the autonomous system: 64.235.248.0/24, 199.15.176.0/22, 207.171.7.0/24, 2607:f238:3::/48 and 2620:101:d000::/45. Some were provider address space and some direct assignments; they were not all present for the same period. PeeringDB's ten-plus-one count may have reflected more-specific operational announcements, an earlier inventory convention or information that was never refreshed. Public route observation should take precedence for claims about what was globally visible.

Usable capacity also depends on the application. A web directory can be constrained by database queries, storage, cache efficiency or server compute before a 1Gbps port fills. A distributed denial-of-service attack can exhaust state, packets per second or an upstream protection limit while average bandwidth remains modest. A single database dependency can stop useful service while every BGP session stays healthy. Network capacity is necessary, not sufficient.

The only safe present-tense capacity statement is negative: AS53582 had no publicly observed announced address space in the current RIPE view. The old hardware and contracts may have been decommissioned, may remain idle, or may support private connectivity that is not visible to public collectors. None of those possibilities creates public IP capacity under AS53582 today.

The route withdrawal is the clearest operating-status signal

RIPE's routing-status response for AS53582 records the first observed route in July 2010 and the last observed route, 64.235.248.0/24, on 29 September 2025. At 08:00 UTC on 10 July 2026, it showed zero IPv4 prefixes, zero IPv6 prefixes, zero observed neighbours, and no visibility among 327 IPv4 and 321 IPv6 RIS peers. The companion announced-prefixes response returned an empty list.

This is stronger evidence of present network state than a static company profile. Public BGP collectors are not omniscient: they see routes received by participating peers, not private sessions or every local exchange announcement. A route accepted only by one private counterparty could escape broad observation. A private internal network can also continue using an ASN without originating public space. But an organisation serving public websites from its own addresses normally needs those addresses visible beyond a closed group. Zero broad visibility for more than nine months is a substantial downgrade.

The 64.235.248.0/24 history illustrates the handoff. RIPE's current prefix overview shows that the address falls under the larger 64.235.224.0/19 route originated by AS5580, associated with GTT, rather than by AS53582. That does not identify Connectivity's former commercial terms or explain why the more-specific route ended. It shows that a provider aggregate can remain reachable while the customer's independent origin disappears.

The company's own domains reinforce the transition without revealing the private origin architecture. Public DNS for connectivity.com returns addresses within Cloudflare's published ranges, as does YellowBot. Those answers place the public web edge behind another network; they do not reveal where the application server sits or who owns it. Cloud delivery can continue while AS53582 is withdrawn.

Solfo's old domain is more revealing. Public DNS for solfo.com points to 199.15.177.178, inside Solfo's registered /22. RIPE shows that /22 is not currently announced. A stale address record is not proof that the whole company is inactive, but it is consistent with a retired origin network whose legacy hostname was not fully cleaned up.

It would be easy to tell a dramatic outage story from this evidence, and that would go too far. There is no public incident notice tying the September 2025 withdrawal to a failure. It may represent an intentional migration to cloud hosting, the end of a transit contract, disposal of colocation equipment, a corporate change or an operational error. The duration and current third-party edge make planned retirement plausible, but only the operator or its suppliers could confirm the cause.

For operating status, the measured conclusion is still firm: Connectivity has a live software website, but its separately registered autonomous system does not present as a live public network. The company should not be treated as a currently operating regional ISP on the strength of old facility and traffic fields.

Six failures show what the network actually depended on

The absence of an access network does not eliminate physical failure. It concentrates failure into a different set of components. Six scenarios explain the operating surface more accurately than a hypothetical cut to a residential fibre route.

1. A cross-connect or metro-fibre fault

Connectivity's router had to reach upstreams and Any2West through physical cables. A bent patch lead, failed optic, dirty connector, mislabelled jumper or damaged building fibre could remove one path. A fault in the short metro route between Telecom Center LA and One Wilshire could affect equipment in both buildings if the second site depended on the first for transit or exchange access.

Recovery would require a known circuit identifier, optical measurements, access to both ends, a spare optic or patch lead and coordination between Connectivity, the facility and the carrier. Two building entries do not prove two street routes. The evidence needed for diversity would be carrier route letters, separate building entrances, riser details and confirmation that the paths do not merge in the same conduit before reaching an upstream point.

2. Colocation power or cooling loss

Routers, switches and servers stop when their power chain fails or when cooling loss forces shutdown. The building may offer utility feeds, uninterruptible power and generators, but the tenant's cabinet can still have a single power distribution unit, one supply connected to both device inputs or a breaker with insufficient headroom. Generator runtime also depends on maintenance and fuel resupply.

CISA's communications dependency guidance notes that communications facilities depend on electricity and on transport for backup-generator fuel. Connectivity published no cabinet power design, dual-cord arrangement, battery runtime or generator test evidence. Presence in a prominent carrier hotel reduces some risks while leaving the tenant's exact power chain unknown.

Recovery would begin with deciding whether the failure is inside the rack, within the colocation suite, across the building or on the utility supply. Remote telemetry, branch-circuit identification and an authorised person on site matter as much as spare server capacity. A service can remain unreachable after building power returns if a router or server does not boot cleanly.

3. Border-router or optical hardware failure

A single border router can make a multihomed diagram logically impressive but physically fragile. If every transit and peering session terminates on one chassis, a failed supervisor, power supply, line card or software image removes all routes at once. Two routers in one rack can still share a power feed, management switch or configuration error.

The PeeringDB record does not identify router count. It also does not say whether Connectivity placed one router in each building, used redundant route reflectors or kept a cold spare. Hardware replacement requires compatible equipment, saved configuration, current credentials, console access and a technician who can distinguish the failed component from an upstream problem.

NIST's contingency-planning guidance recommends alternate equipment and alternate locations as recovery methods. Its detailed telecommunications guidance specifically includes routers, switches and ownership boundaries in recovery planning. Connectivity discloses none of the associated recovery arrangements.

4. Upstream or routing-policy loss

A router can be powered, connected and healthy while the internet has no path to its prefixes. An upstream may disable a session for non-payment, maintenance or policy reasons. A route can be rejected because an IRR object or route-origin authorisation is absent or inconsistent. A configuration change can attach the wrong community, advertise the wrong prefix length or withdraw the route entirely. A provider can retain an aggregate while the customer's more-specific origin vanishes, as the current 64.235.248.0/24 view demonstrates.

The best recovery is not merely a second upstream name. It is a second upstream with a separately engineered physical path, tested advertisements, valid routing-security records and enough capacity to carry the full service. The operator should test whether traffic actually converges when one path is withdrawn. No public AS53582 record identifies current upstreams, and RIPE currently sees no neighbours at all.

5. Exchange congestion or peer loss

The listed Any2West port had a 1Gbps line rate. If traffic approached that rate, packet loss could degrade page loads even while the interface remained up. A distributed attack or sudden surge could saturate it. A peer could reset a session or change policy. Public peering would then shift traffic to paid transit only if that route remained available and had spare capacity.

This is the difference between installed and recoverable capacity. A network with a 1Gbps exchange port and a 1Gbps transit circuit may appear to have 2Gbps, but not if both share one 1Gbps router interface, one metro circuit or one provider handoff. Likewise, traffic engineered toward a peer may fail over to a longer path with higher latency or insufficient headroom. The old 1-5Gbps traffic statement does not reveal peak demand, port utilisation or failover capacity.

6. Too few authorised hands

Connectivity had eight California employees in the 2011 court record, but that figure is historical and did not identify network technicians. Small content companies often rely on a technically skilled founder, systems administrator and facility remote hands rather than a round-the-clock field organisation. That can be efficient until an incident requires simultaneous work at two sites, a replacement part not held locally or access outside the supplier's standard scope.

The response chain matters. Who receives an alarm? Who can call the upstream? Who is listed on the facility access roster? Where are optics, cables, power supplies and a replacement router stored? Can the technician reach both buildings during a downtown closure? Does the person with BGP credentials also have physical access? No public record answers these questions.

Local labour in this setting means concentrated specialist labour, not a fleet of installers. A single experienced person may understand the entire routing and server estate. That knowledge is valuable and also creates a key-person risk. Recovery evidence would include an on-call rota, documented escalation contacts, tested console access, spares at both sites and a measured time to replace a failed component.

These six scenarios lead to one larger finding. Connectivity's documented network could have been redundant at the protocol level while remaining exposed to common buildings, short metro routes, power chains and a small operations group. Conversely, a modest two-site design could have been robust if paths, power and staff were genuinely independent. The public record supports neither claim. It supports the questions.

The affected users were application users, not stranded broadband homes

Failure impact follows the service boundary. When a regional ISP loses an access route, households and businesses can lose all internet access, voice service and the ability to reach unrelated online applications. When Connectivity's content network failed, the likely direct effect was loss or degradation of Connectivity, YellowBot, Weblocal or related services hosted behind the affected routes. Users' own broadband connections would continue to carry traffic to other destinations.

The scale could still be material. The 2011 court record described millions of YellowBot visits from Texas alone and thousands of local business pages. The 2014 financing report claimed more than 92,000 paid business accounts. The 2016 division sale referred to more than 20,000 physical business locations, and the current company site claims more than 10,000 businesses served. Those figures come from different years and measures and should not be combined. They show that an outage could affect a broad commercial audience even though Connectivity did not control users' last mile.

Different failures would produce different symptoms. Loss of one peer could slow access for customers of one network while other users saw no change. Loss of the origin route could make all services on the affected addresses unreachable. A database or server failure could return errors despite healthy routing. Loss of a public web edge could hide an origin that remained online. Accurate incident analysis therefore requires application, DNS, route and facility evidence together.

Current DNS reduces the direct relevance of AS53582 to the live public sites. Cloudflare addresses answer for connectivity.com and YellowBot, so those names no longer require a user to find a route originated by AS53582. The origin behind Cloudflare could still depend on one site or provider, but that private path is not disclosed. The route withdrawal may therefore have moved risk rather than removed it: from company-operated public interconnection toward contracts with a cloud edge and an undisclosed hosting environment.

That shift can improve resilience if the service is distributed across regions and origins. It can also create new concentration if every domain, name server and origin depends on one vendor or account. A logo on a cloud service does not reveal origin replication, backup quality or recovery time. The public evidence is sufficient to say that Connectivity's web edge changed; it is not sufficient to score the new architecture.

The regional-ISP test fails at every access-network layer

The FCC describes a broadband-serviceable location as a home or business where mass-market fixed internet access can be installed. Providers report where they offer that service over their own network facilities, and the National Broadband Map is organised around locations, technologies and advertised speeds. This is a useful test for the regional-ISP label even without relying on a negative name search.

Connectivity publishes no serviceable-location file, address checker or consumer broadband label. It gives no residential or small-business internet speed, installation interval, monthly access price, data allowance or equipment charge. It identifies no fibre-to-the-premises, coaxial, copper, licensed wireless or unlicensed fixed-wireless technology. It names no local exchange, tower, hub, cabinet or access node serving customers.

There is likewise no disclosed physical service area. Burbank is a corporate address, not a broadband footprint. Los Angeles is a hosting and interconnection location, not proof that nearby buildings could buy Connectivity internet access. PeeringDB's North America scope describes where the content network expected traffic or peers, not where it installed last-mile service.

Ownership evidence fails in the same place. ARIN proves control of number-resource registrations. PeeringDB suggests presence at two facilities and one exchange. Neither record identifies poles, conduit, towers, street fibre, customer drops or customer-premises equipment. No public record reviewed here shows Connectivity owning, leasing or operating any of those access assets.

The labour evidence also diverges. Historical staff operated a web business; a Texas contractor maintained the YellowBot site and another handled customer-service issues. That is not evidence of line crews, fibre splicers, tower technicians or installers. The field work implied by the autonomous system was inside or between data-centre buildings, with a very different safety regime, parts inventory and travel radius.

Finally, the economics do not resemble regional access. Connectivity's reported funding was intended for a customer-intelligence platform, and its revenue descriptions concern advertising, data and software accounts. There are no disclosed access passings, take rates, average revenue per broadband user, construction costs or network grants. Calling the company a regional ISP would import an entire cost and customer structure that the record contradicts.

The most defensible classification is a software and content operator with a historical autonomous system. The regional-ISP category should be treated as an unresolved classification problem, not as a fact to be repeated.

What would establish a current operating network

The evidence gap is not impossible to close. A concise set of disclosures could distinguish retirement, migration and continuing private operation.

First, Connectivity could state whether AS53582 remains in service and explain the September 2025 route withdrawal. If the autonomous system is intentionally dormant, the company could identify which public services moved and whether any customer dependency remains on the registered address blocks. If it is meant to be active, a visible authorised announcement and current routing-security records would provide the first objective confirmation.

Second, it could refresh or remove the PeeringDB details. Current facility presence, exchange-port status, port speed and peering policy should be dated. If the One Wilshire and Telecom Center LA equipment has gone, leaving the records marked operational creates a false impression. If it remains, the operator could identify whether both sites carry production traffic or one is only a secondary location.

Third, resilience claims would require topology rather than a count of locations. Useful facts include the number of border routers, upstream carriers, independent building entrances, metro-fibre providers and power feeds. A diagram need not expose sensitive addresses. It can show whether two logical routes share one physical path and whether either facility can carry the full service alone.

Fourth, recovery evidence should state who can act. Remote-hands coverage, spare optics and routers, access authorisation, escalation contacts and tested restoration times turn a facility list into an operating capability. A measured failover exercise is more informative than the word redundant.

Fifth, any claim to broadband service would need a wholly different evidence set: an address-level service area, technology, standard installation terms, retail plan, customer equipment, access-plant ownership and field-repair responsibility. Nothing presently published supplies that set. An ASN announcement alone would not supply it either.

Unofficial market signals cannot bridge these gaps. A cached network profile, an IP-data vendor or an old facility listing may suggest that a network once operated. It cannot prove that equipment remains in a rack, a bill is paid, a route is accepted or a technician is available. Current BGP visibility, facility confirmation and operator disclosure would settle those questions.

The same discipline applies to the live software business. A functioning homepage proves that a web service responds. It does not prove that the response comes from Connectivity-owned equipment or AS53582. Current DNS shows an external edge, but only the company can disclose the origin, replication and recovery arrangements behind it.

A retired route can be more informative than an active registration

Connectivity Inc offers a useful warning about infrastructure inference. Names, categories and registry records describe different layers. The name suggests a carrier. The commercial pages describe marketing software. ARIN describes number-resource rights. PeeringDB describes a historical content network at two Los Angeles facilities. RIPE describes what the public routing system can see now: no AS53582 origin at all.

The old network was substantial enough to take seriously. It had directly registered address space, an autonomous system, a listed 1Gbps exchange port and a presence in the dense interconnection environment around One Wilshire. That arrangement made a nationwide web product depend on a surprisingly local set of assets: downtown power, cross-connects, metro fibre, upstream policy, routers, optics and authorised hands.

It did not make Connectivity a regional ISP. There is no evidence of an access network, broadband subscribers, serviceable addresses, poles, towers, drops or local installation crews. The people affected by a failure were users of the company's applications, not customers whose general internet line went dark.

Today, even that narrower network claim needs a negative operating-status mark. The public route disappeared in 2025 while old interconnection fields remained online. Connectivity's current web properties can continue behind third-party infrastructure, but AS53582 should not be presented as live until a route, neighbour or current facility confirmation returns.

The lesson is practical. Installed infrastructure is not whatever a profile once listed; it is the equipment, contracts and paths that can carry traffic now. Usable capacity is not an address allocation or port label; it is capacity that survives a failure and can be restored by someone with access and spares. For Connectivity Inc, the public evidence shows the historical bill clearly enough. It also shows that the route which once justified that bill is no longer visible.