STPHNET Software Technology Park and the Evidence of a Quiet Network

Summary

• STPHNET Software Technology Park has a clear public network-resource identity around AS3969, but current routing evidence shows no visible originated public prefixes, no visible peers and no PeeringDB network record for that ASN.
• The broader STPI record establishes a real Indian software-export infrastructure and data-communications context, including SoftNET services, Hyderabad jurisdiction history and all-India ISP licensing, but those sources should not be treated as direct proof of current STPHNET tenant outcomes.
• The disciplined buyer question is whether the organisation can keep the accepted operating record coherent through support handoffs, access control, routing-resource changes, service exceptions, upgrades and recovery events, especially when public evidence is thin.

The company is best read through the operating record

STPHNET Software Technology Park sits in an awkward but important part of the technology market. It does not present, in the public evidence reviewed here, like a modern software-as-a-service vendor with a polished product catalogue, published status page, current case studies, open documentation and a visible customer community. It presents first as a directory entity tied to a network-resource record: AS3969, also known in registry-derived sources as ERX-STPHNET, described as Software Technology Park in Hyderabad, India. That is a narrower record than a normal corporate profile, but it is not a useless one.

For software firms that rely on connectivity, tenant facilities, leased-line service, support escalation and hosted infrastructure, the network-resource record can be a better starting point than marketing copy.

The article therefore uses a different test from the one that would fit a cloud application with a login page and public API. The useful question is not whether STPHNET can describe attractive technology services. The useful question is whether the public record shows a coherent operating surface: who the entity is, what network resources are attached to it, how the resources appear in current routing views, what broader service infrastructure sits around it, and where a buyer would need direct proof before relying on the service.

This is a practical question because developer teams and platform teams do not experience infrastructure as an abstract brand. They experience it through tickets, handoffs, port turn-ups, contact changes, route changes, billing lines, maintenance windows, outage notices, access approvals, backup evidence and post-incident explanations.

On that test, STPHNET is a thin-evidence company with a meaningful but quiet technical record. The strong evidence is identity evidence. Public directory, APNIC RDAP, RIPEstat whois, BGP.Tools, Hurricane Electric and Cloudflare Radar views all point to AS3969 or ERX-STPHNET as Software Technology Park in India. APNIC RDAP gives the aut-num name, country, Hyderabad description, historical registration and last-changed dates, and an incident-response entity tied to Software Technology Parks of India. The weak evidence is current production evidence.

RIPEstat's current routing-status and BGP-state views show no visible prefixes, no visible peers and no current route entries for AS3969. BGP.Tools says the ASN is active and allocated under APNIC but not currently in the global routing table, with zero IPv4 and zero IPv6 prefixes originated. Hurricane Electric similarly shows zero originated or announced prefixes and zero observed peers. PeeringDB's public API did not return a network record for ASN 3969.

That combination should shape the whole analysis. It would be misleading to say STPHNET has no relevance simply because AS3969 is quiet in public BGP feeds. STPI's official materials describe a long-running data-communications role for India's software-export industry, including SoftNET, Internet leased-line connectivity, international private leased-line connectivity and network operations through STPI centres. A quiet ASN can be legacy, reserved, replaced, used only in limited contexts, or disconnected from services delivered through other networks.

But it would be equally misleading to treat STPI's broad official service claims as evidence that this specific STPHNET entity currently carries tenant traffic, serves named customers or meets a particular reliability benchmark. The public record supports a conservative reading: STPHNET matters as a network-resource and software-park service identity, while the live operating state has to be verified directly before a buyer depends on it.

Identity is visible, but the boundary is narrow

The first discipline is entity boundary. The entity in scope is STPHNET Software Technology Park, also represented by aliases such as Software Technology Park and ERX-STPHNET Software Technology Park. The linked network resource is AS3969. The public directory classifies the entity as a company and associates it with ASN/IP network-resource records. APNIC RDAP lists the name ERX-STPHNET, describes Software Technology Park at 407, Maitrivanam HUDA Complex, S R Nagar Post, Hyderabad 500038, and places the record in India. It also says the aut-num entity was created as part of an ER-Transfer from ARIN.

RIPEstat whois repeats the same core aut-num fields. BGP.Tools repeats the Software Technology Park description, country and APNIC status.

That is enough to identify the public network-resource entity. It is not enough to collapse several related things into one commercial story. Software Technology Parks of India, usually abbreviated STPI, is the much broader government-linked organisation under India's Ministry of Electronics and Information Technology. STPI operates across India, promotes IT and IT-enabled services, runs schemes and centres, and publishes official material about SoftNET and data communication services.

STPI-Hyderabad is a jurisdictional centre with Hyderabad as the main centre and sub-centres in places including Kakinada, Tirupati, Vijayawada, Visakhapatnam and Warangal. The APNIC record for AS3969 uses a Hyderabad Software Technology Park description and an STPI incident-response contact, so the connection is real. But the public evidence does not justify treating every STPI service, every STPI centre, every export statistic or every startup support programme as a direct claim about STPHNET Software Technology Park.

This boundary matters because the article is not trying to write a celebratory history of STPI. It is testing a specific directory entity and its service relevance. A buyer looking at STPHNET should ask: is the counterparty STPI, a local STPI centre, a legacy Software Technology Park entity, a network-resource holder, a facility operator, a connectivity service desk, or a different commercial arrangement that inherited the STPHNET name? Which invoices, service orders, contracts, abuse contacts, support queues and routing authorisations carry the relevant name? Which contact is authoritative today?

The public record shows historical and registry identity, but it does not provide a current commercial contract boundary.

The AS3969 record also contains a personal administrative and technical contact from the old APNIC entity, while the incident-response entity points to Software Technology Parks of India with a Bangalore address and an email at stpi.in. That mixture is common in older number-resource records. It does not necessarily mean the old individual contact is the right support path in 2026. It does mean any customer or counterpart should verify current role contacts through the service contract and the relevant registry update process rather than assuming that legacy contact fields match today's operational chain.

The right reading is therefore precise. STPHNET is visible as a public network-resource identity linked to Software Technology Park in India. It is connected to the STPI ecosystem by the registry contact and by the broader service history around Indian software parks. It should not be merged with unrelated companies, customer systems, similarly named technology parks, parent programmes, upstream networks or current STPI-wide statistics unless the evidence explicitly connects that claim to the AS3969/STPHNET record.

AS3969 proves identity, not current production traffic

Autonomous system records are useful because they are harder to fake than marketing claims. An aut-num entity gives a number, name, country, contacts, maintainers and source registry. APNIC's own documentation explains that aut-num entities describe Autonomous System numbers and can be used with other routing entities to describe routing policy and help network administrators debug network problems. A route object, by contrast, is how an interdomain route that originates from an AS can be specified in the APNIC Whois database for IPv4 or IPv6. The existence of an aut-num therefore proves that a resource record exists.

It does not, by itself, prove that a network is currently announcing public prefixes.

That distinction is the central technical finding for STPHNET. APNIC RDAP shows AS3969 as active, with registration in 2008, last changed in 2013, and the ERX-STPHNET name. RIPEstat whois returns the same aut-num fields and APNIC authority. BGP.Tools says the ASN is active and allocated under APNIC, registered on 1 August 2002 in its view, but not currently in the global routing table. RIPEstat's announced-prefixes endpoint returned an empty prefix list for AS3969 over the current query window. RIPEstat routing status showed zero IPv4 and zero IPv6 announced prefixes, zero observed neighbours, and zero RIS peers seeing the route.

RIPEstat BGP state returned no route entries. Hurricane Electric showed zero prefixes originated and announced, zero observed peers and zero originated IPv4 or IPv6 space. PeeringDB returned no network entity for ASN 3969.

These are not small details. For an organisation being assessed as a cloud-service dependency or a technology-park connectivity provider, the difference between registered identity and visible route origination changes the due-diligence path. A visible active ASN with prefixes, upstreams, RPKI state, exchange presence and peers can be evaluated through route stability, provider diversity, prefix hygiene, registry consistency and incident history. A quiet ASN cannot be tested that way from public data.

There is no public prefix to ping, no public route path to compare, no visible upstream mix to analyse, no direct public BGP incident trail to map to that origin, and no PeeringDB interconnection profile to review.

The absence of public BGP visibility should not be overread. A software-park service can operate through upstream provider addresses, private circuits, customer-assigned resources, internal networks, data-centre cross-connects, or successor ASNs. The AS3969 label may be a legacy identity retained for registry history, an old transfer entity, a resource reserved for limited use, or a record that is not currently used for Internet origination. None of those possibilities can be confirmed from the public data alone.

What can be confirmed is narrower: as of the reviewed public routing views, AS3969 is not visibly carrying public originated prefixes in global BGP feeds.

That makes the buyer test more documentary than technical. A prospective tenant, platform team or enterprise buyer should ask for current service diagrams, active circuit identifiers, upstream-provider names, public or private IP allocation records, change windows, escalation contacts, route and DNS ownership documentation, backup contact paths, and evidence of recent incidents or maintenance events. If STPHNET or an STPI-linked service is providing connectivity, the buyer should know whether AS3969 is operationally relevant or merely historical. If another ASN or upstream is used, the buyer should have that record.

If service is delivered as private leased-line connectivity, the buyer should inspect the private service record rather than expecting public BGP data to answer the question.

The STPI service context is real, but it is broader than STPHNET

The broader STPI context explains why a quiet network-resource record can still matter. STPI's official Internet Services and Data Communications page says STPI has been a data communication service provider in India since 1993. It describes SoftNET services, including SoftPOINT for point-to-point International Private Leased Line Connectivity and SoftLINK for Internet leased-line connectivity to software exporters doing offshore development.

It also states that STPI holds a unified Category-A ISP licence with all-India service area, describes STPI as India's first commercial Internet service provider, and says its national service delivery and management infrastructure includes independent gateways through network operations centres at STPI centres. The same page lists network management tools, single point of contact for support, fault logs on intranet, redundancy, multi-homed gateway architecture, continuous technical support and online bandwidth statistics among the service features.

The Hyderabad context is also meaningful. STPI's official Hyderabad page says the Hyderabad jurisdiction has its main centre in Hyderabad and several sub-centres, and that it has supported the growth of software and hardware industry in Andhra Pradesh and Telangana for three decades. It says STPI-Hyderabad began in 1992 with STPI-registered units working from the complex and ready-to-use space for member units. It also reports a large FY 2024-25 software-export contribution by units under the Hyderabad jurisdiction.

These statements provide institutional context for why a Software Technology Park identity in Hyderabad might be attached to network service, tenant service and software-export infrastructure.

Regulatory context reinforces the service surface. TRAI's April 2024 ISP list includes Software Technology Parks of India with licence number 821-42/2013-DS, Category A, all India. The Department of Telecommunications describes Category-A ISP authorisation as nationwide, while Category B and C are narrower. The DoT eServices portal describes ISP service as connectivity for individuals and organisations, delivered through technologies such as fibre, DSL and wireless broadband, and notes obligations around reliability, speed, cybersecurity and data retention.

A Press Information Bureau release in 2025 gives macro context for STPI's role in the Indian technology economy, including STPI-registered units' software exports and startup support programmes. Digital India's STPI page frames STPI as a single-window service provider for software exporters, covering statutory services, data communications, incubation, training and value-added services.

Those official sources are strong for the STPI ecosystem. They are not narrow proof for AS3969. The official STPI pages describe organisational capabilities and infrastructure, not a current route announcement from STPHNET. They support an article about service dependency because they show the broader work surface: software-export units, tenant support, leased connectivity, network operations, incubator spaces, statutory services and regional technology clusters.

But they do not show a customer count for STPHNET, an active customer list, a current SLA performance record for AS3969, a present route table, a support-response benchmark, a price sheet or a public status history.

This is why the article keeps the two layers separate. The direct STPHNET evidence is an ASN-linked identity record with quiet public routing. The broader STPI evidence is a real service and policy context around Indian software parks and data communications. The commercial risk sits in the gap between them. If a buyer assumes the broad STPI context automatically proves current STPHNET performance, the buyer will overtrust the evidence. If the buyer ignores the STPI context and sees only an inactive route table, the buyer may miss the local institutional role that a technology-park service desk or facility operator can still play.

A quiet route table changes the supervision model

When a vendor's current public routing data is rich, supervision can be partly external. Network teams can watch route announcements, RPKI status, route leaks, upstream changes, prefix withdrawals and public outage signals. They can compare provider views and build independent alerting. For AS3969, that external supervision path is limited because the public routing surface is quiet. There are no visible originated prefixes in the reviewed RIPEstat, BGP.Tools and Hurricane Electric views. That means a customer relying on a STPHNET-linked service has to push supervision closer to the service contract.

That supervision should start with the accepted operating record. In a technology-park or tenant-connectivity setting, the accepted record is not just a router configuration. It is the set of facts that staff and customers act on: which tenant has which circuit, which IP range, which contact, which access credential, which port, which service level, which maintenance window, which billing state, which escalation path and which exception history. A clean operating record reduces support time because the next shift, next engineer and next manager can see the same facts.

A weak record increases hidden work because every outage or change request turns into archaeology.

For STPHNET, the public record suggests several places where the operating record should be tested. First, contact authority. The APNIC aut-num points to historical contacts and an STPI incident-response entity. A current customer should know which contact path is contractual, which path is for abuse, which path is for routing, and which path is for tenant support. Second, network authority. If AS3969 is inactive in public routing, the customer should know what active network resource delivers the service. Third, location and facility authority.

If the service is tied to Hyderabad or the STPI-Hyderabad jurisdiction, the buyer should know which physical site, data room, exchange, upstream or local service desk is responsible. Fourth, change authority. The buyer should know who can approve routing, firewall, access, circuit or support-queue changes and what evidence is retained.

The key failure mode is not a dramatic technical collapse. It is drift. Contact fields drift away from current staff. Old route objects or aut-num fields remain while services migrate. Tenant names change but circuit records do not. Access lists are copied forward without a clear owner. Maintenance notices go to the wrong mailbox. A leased line is delivered through a different upstream but billing records still use the old label. A helpdesk marks an issue resolved before the customer application has actually recovered.

This kind of drift is common in long-lived infrastructure organisations, and it matters more when public routing evidence cannot independently confirm the live path.

Good supervision would make drift visible. It would produce periodic service inventories, current escalation matrices, route and DNS ownership lists, access reviews, incident timelines, maintenance logs, backup contact lists and customer-visible change records. The public sources do not show whether STPHNET or the STPI-linked service has that discipline today. They do show why the discipline is the right buyer test.

Tenant service value is local labour plus record discipline

The commercial attraction of a technology-park service is not only bandwidth. It is local labour organised around repeated operating problems. A software exporter, startup, platform team or enterprise tenant may value a provider that can combine connectivity, support access, facility knowledge, statutory context, local escalation and practical network operations. STPI's own materials position the organisation around software exporters, data communications, incubation and support. STPI-Hyderabad's official history places the jurisdiction in the development of Hyderabad as a technology cluster.

That is a service story about labour, not just equipment.

Local support labour becomes valuable when systems cross organisational boundaries. A tenant may run its own application, use a cloud provider, depend on a leased line, host some equipment, receive public IP space through a provider, and coordinate with a facility or jurisdictional office for access. The failure rarely sits in one clean box. A build server cannot reach a partner. A DNS change has not propagated. A firewall rule was approved but not applied. A private circuit is down but the upstream says the local handoff is clean. A tenant employee left and still appears on the access list.

A scheduled maintenance window touched a dependency that nobody listed. A backup worked, but the restored application cannot reach its database because a route or access rule changed.

In those cases, the product is the record. The customer is buying the ability to get from symptom to responsible owner without losing time. A strong provider can say: here is the circuit, here is the port, here is the active upstream, here is the last change, here is the maintenance notice, here is the access approver, here is the ticket, here is the incident sequence, here is the recovery evidence, and here is what changes before the next window. A weak provider can only say that another team is checking.

STPHNET's public evidence does not let an outside reader score that support function directly. There is no public support dashboard, no customer reference set, no post-incident library and no public SLA performance history tied to the entity. The correct inference is not that the support function is poor. It is that support quality must be verified through customer-specific evidence.

Buyers should ask for sample incident reports, redacted maintenance notices, support workflow descriptions, escalation time targets, on-call handoff process, tenant inventory process, service-credit terms, access-review cadence and a recent example of a service exception that crossed between facility, network and tenant teams.

The cost side is just as important. Local support can reduce work if it owns coordination. It can add work if the customer still has to chase every boundary. A low advertised connectivity or facility cost can become expensive when every exception consumes developer time, management attention and customer goodwill. Conversely, a service that looks less modern on public evidence can still be commercially useful if the local team keeps the operating record clean and resolves exceptions quickly. The public evidence leaves that outcome open.

Integration risk is not software alone

The category context places STPHNET in a cloud-service dependency frame, but this is not cloud dependency in the narrow sense of a hyperscale platform or a SaaS API. It is a dependency between software firms and the service environment that supports them. That environment may include leased lines, upstream connectivity, routing-resource records, physical access, service desks, statutory services, local networks, support queues, monitoring, billing and recovery evidence. The software firm may not care which ASN is used on a normal day. It will care when the dependency breaks.

The integration risk therefore has several layers. The first is network-resource integration. If a tenant depends on a specific IP range, upstream path or DNS configuration, the tenant needs authoritative records and change control. The second is identity and access integration. If facility access, support contacts, router credentials, customer portal users or abuse contacts are outdated, incident response slows. The third is workflow integration. If tenant tickets, provider tickets and upstream tickets are not linked, the root cause can disappear into separate queues. The fourth is billing and contract integration.

If the contract describes one service but the operational team delivers another, disputes become likely during outages or upgrades.

These integration risks do not require exotic technology. They are ordinary infrastructure risks. They become harder when the public record is old or quiet because external observers cannot easily infer current topology. AS3969's quiet route table is a useful warning sign in that limited sense. It says the public ASN record should not be mistaken for the active service path. A buyer should ask for the active path. If STPHNET-linked service is delivered through STPI's broader network infrastructure, the buyer should ask how the service maps to current STPI gateways, NOCs, circuits and escalation points.

If it is delivered through an upstream carrier, the buyer should ask how outage responsibility is divided. If a service has migrated away from the old ASN, the buyer should ask why the old record remains, who maintains it, and whether any customer documentation still points to it.

Maintenance is another integration point. Official STPI material describes network management tools, fault logs, redundancy, multi-homed gateways and continuous technical support as features of SoftNET services. Those are useful claims, but a buyer needs implementation evidence. How are planned changes communicated? Are tenants grouped by dependency so a single maintenance window can be assessed for downstream application impact? Does the provider record which tenants use which circuits or address ranges? Are failed changes reviewed? Are rollback records retained? Are access changes tied to named approvers?

Is there a customer-facing incident number that can be referenced later?

The total cost of a dependency is not the service fee. It is service fee plus governance labour, incident labour, compliance labour, migration labour and exit cost. A technology park or connectivity provider can reduce that total cost if it absorbs coordination and preserves evidence. It can raise the total cost if the customer must build its own shadow records because the provider's records are not visible or current. STPHNET's public record leaves the total-cost question unresolved. That is exactly why the article treats uncertainty as part of the analysis rather than filling it with assumptions.

Reliability claims need customer-specific proof

Official STPI material includes broad reliability language, including redundancy, multi-homed gateways, continuous technical support and an SLA uptime claim for SoftNET services. Those claims are important because they identify the service promise. They should not be converted into a measured reliability number for STPHNET or AS3969. Public routing views do not show AS3969 carrying current public prefixes. The reviewed evidence does not include a customer-specific SLA, outage log, maintenance history, uptime report, service-credit record or independent monitoring data for STPHNET Software Technology Park.

The difference between capability, reliability and outcome is essential. Capability means the provider describes or possesses the means to deliver a service: data communication infrastructure, leased-line offerings, network operations centres, support teams and regulatory authorisation. Reliability means the service actually performs over time within defined boundaries: uptime, packet loss, repair time, escalation speed, change success, route stability and backup contact availability.

Customer outcome means the customer's own work improves: fewer interrupted releases, less downtime, lower support burden, faster recovery, more predictable deployment windows, cleaner audit evidence or lower total cost. Public sources establish some capability context. They do not prove reliability or customer outcome.

For a buyer, the evidence request should therefore be practical. Ask for the active service description and the active network path. Ask for a recent uptime or availability report, with measurement method. Ask how faults are logged and whether customers can inspect their own fault history. Ask how planned maintenance is announced and whether emergency maintenance has a separate path. Ask for the escalation matrix and the process for stale contacts. Ask whether the provider has a customer-visible change-control process for routing, access, firewall, cabling and circuit changes.

Ask how disputes are handled when the upstream carrier says the circuit is healthy but the tenant's application remains down. Ask whether the provider can supply a redacted post-incident report that shows timeline, impact, cause, mitigation and prevention.

Security and compliance evidence should also be concrete. The DoT eServices portal describes ISP obligations around reliability, speed, cybersecurity and data retention. That does not tell a buyer how STPHNET-linked service handles access control, log retention, abuse response or customer data. The buyer should ask who has administrative access to network equipment and customer portals, whether privileged access is reviewed, how abuse complaints are routed, whether logs are retained for an agreed period, how data shared during troubleshooting is protected, and how staff changes are reflected in access records.

If tenant services involve software exporters or regulated customers, these questions are not optional housekeeping. They are part of the operational risk.

The public evidence does not support customer names, benchmarks, prices or a comparative ranking against other technology-park or connectivity providers. It supports a narrower conclusion: STPHNET has a durable resource identity and sits inside a broader STPI service context, but current service reliability cannot be inferred from the public pages. It has to be proven by live service records.

What buyers can verify before committing

A buyer does not need to wait for perfect public evidence. It can build a verification checklist around the known uncertainty. The first item is identity. The buyer should ask the provider to confirm the legal counterparty, current service name, operational contact, billing contact, abuse contact and escalation owner. If AS3969 appears in any proposal, the buyer should ask whether it is actively used. If a different ASN, upstream provider or private network carries the service, the buyer should ask for the actual records. The answer should be specific enough for the buyer's network team to understand the service path.

The second item is inventory. For each tenant service, the provider should be able to list circuits, ports, IP assignments, VLANs, DNS dependencies, facility access roles, maintenance windows, support contacts and upstream dependencies. The provider should be able to show how this inventory is updated after a change. If the provider cannot produce a current inventory, the customer will eventually have to create one itself, which weakens the value of the service.

The third item is exception handling. Buyers should ask what happens when a leased line fails, a route changes, a customer contact leaves, a support ticket crosses from facility to network to upstream carrier, or a maintenance window causes unexpected application impact. The provider should show how exceptions are logged, who owns them, how customers are informed, how recurrence is prevented and how evidence is retained. The practical test is not whether the provider says it has support. It is whether support can reconstruct a messy incident without relying on memory.

The fourth item is access control. Technology-park services often involve a mix of physical and logical access. The buyer should ask how access requests are approved, how emergency access is handled, how former employees are removed, how shared accounts are prevented, how privileged credentials are rotated, and how facility access maps to network access. A provider that cannot explain access control will struggle during security reviews and incident response.

The fifth item is exit. If the buyer later moves to another provider, what happens to IP assignments, DNS, cabling, equipment, logs, access records, billing disputes and support history? A provider that reduces lock-in will have a clear exit process. A provider that creates hidden dependency may be cheap at entry and expensive at departure. Exit cost is especially important when public data is thin because the customer cannot rely on outside documentation to reconstruct the service later.

The final item is evidence cadence. A one-time due-diligence packet is not enough for a service dependency. Contacts, circuits, routes and access rights change. The buyer should require periodic reviews of service inventory, escalation contacts, maintenance history, incident summaries and access lists. If STPHNET-linked service is important enough to support production software work, it is important enough to review as an operating dependency rather than a one-off procurement line.

A conservative verdict

STPHNET Software Technology Park is a case where the absence of a loud public footprint is itself useful evidence. The public record does not support a glossy story about a current cloud platform, a large customer base, named tenants, measured uptime, modern software features or superior support outcomes. It supports a more modest but still important story. There is a real network-resource identity around AS3969. That identity is connected through public registry data to Software Technology Park in Hyderabad and to STPI-related incident-response records.

The broader STPI ecosystem has a documented role in Indian software-export infrastructure and data communications. Current public routing views, however, do not show AS3969 originating public prefixes or carrying visible public BGP relationships.

For readers, that means the company should be assessed through record discipline. The useful question is whether the organisation can keep the service record coherent when tenants and software firms rely on it. Can it state the active network path? Can it separate legacy ASN identity from current service delivery? Can it keep contact authority current? Can it preserve route, access, ticket, maintenance and recovery evidence? Can it explain exceptions without pushing the customer through several disconnected teams? Can it show customer-specific reliability proof rather than broad service language?

There may be a valuable service underneath the quiet public routing evidence. Local infrastructure operators often matter most when they know the facility, the customer, the circuit and the practical escalation path. But that value must be proven through operating records, not inferred from old registry fields or broad institutional history. STPHNET's market relevance is therefore not that it looks like a modern cloud company.

It is that a software-park service lives or dies by the mundane records software firms depend on: who owns the connection, who answers during failure, what changed, what recovered and what evidence remains after everyone moves on to the next incident.