M21 Data Center has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• M21 Data Center's AS141294 was visible on 12 July 2026 originating four IPv4 /24 routes, with two observed neighbouring networks and valid route-origin authorisation reported for the prefixes. That is credible evidence of a small operating hosting network, not evidence of a resilient data-centre building.
• Public records locate M21's network administration in Nagpur and show its own domain resolving inside its address space, yet they disclose no rack count, installed IT load, utility-feed design, UPS autonomy, generator endurance, cooling arrangement, fire certification, flood protection or physically diverse fibre entrances.
• The most important commercial question is therefore not how much address space M21 announces. It is how much customer load can remain available when grid power, a cooling component, a carrier path or a site system is removed, and whether recovery has been demonstrated under realistic load.
• Until M21 publishes site-specific engineering evidence, customer contracts should treat capacity, redundancy and recovery as unverified. The appropriate evidence grade is Weak even though the network itself is active.

A network exists; the facility proposition is still an open question

M21 Data Center is not invisible. The Asia Pacific Network Information Centre record for AS141294 names M21IDC-AS, gives India as the country and records the autonomous system from December 2020. Its administrative and technical contact is an IP administration role at Plot No. 2, New Dnyaneshwar Nagar, Manewada Road, Nagpur, Maharashtra. Two portable IPv4 blocks, 103.159.239.0/24 and 103.177.84.0/24, are registered with the description M21 Data Center. These are meaningful facts: an address holder has maintained registry records, contacts and routed resources over several years.

On 12 July 2026, RIPE NCC's announced-prefix view showed AS141294 originating those two blocks plus 163.227.38.0/24 and 163.227.39.0/24. Its routing-status view reported 1,024 announced IPv4 addresses and no IPv6 space, with the earliest currently reported origin first seen in December 2020. Cloudflare Radar also presented M21 as an Indian autonomous system with live routing observations. This is enough to reject the idea that the name is merely a dormant listing.

It is not enough to establish what the words “Data Center” might lead a buyer to assume. An autonomous system can be operated from owned space, leased racks, a shared server room, equipment in another provider's building or a mixture of arrangements. Internet routes identify an administrative routing domain. They do not identify the number of racks, the floor loading, the utility connection, the cooling plant, the fuel inventory, the fire compartment, the fibre entry points or the people on shift. Even a responsive server proves only that one service was reachable at the instant of observation.

That distinction is unusually important here because M21's public corporate surface is thin. On 12 July, m21.co.in resolved to 103.177.84.7, an address inside an M21-registered and M21-originated block. The web server returned an uncustomised Plesk default page, and its certificate had expired in April 2026. The response demonstrates a machine and hosting control panel on M21 space. The default page and expired certificate are weak operational signals about the public domain, but neither should be inflated into a conclusion about customer systems or the physical plant. A neglected corporate landing page can coexist with competent private operations; it can also indicate limited attention to basic external controls. The point is that public evidence does not settle the matter.

The first diligence task is therefore identity and boundary. M21 should state the legal entity that contracts with customers, the trading name used on invoices, the owner or landlord of each relevant building, and the party responsible for electrical and mechanical operation. It should identify whether the Nagpur registry address is an administrative office, the actual equipment site, or both. If servers sit elsewhere, the operator should name the facility and define which obligations belong to M21 and which belong to the underlying colocation provider.

Without that boundary, a buyer cannot tell whether a promise about “our data centre” describes owned infrastructure, rented capacity or simply a network brand.

Four routes reveal activity, not usable capacity

The routing evidence has real analytical value when it is read narrowly. RIPE NCC's routing status showed all four IPv4 routes visible to its reporting peers on the observation date. bgp.tools likewise classified the network as active and listed four IPv4 /24s with valid RPKI status. IPinfo's AS141294 profile classified the network as hosting, associated hundreds of domains with its addresses and reported responding hosts across the four blocks. The 103.177.84.0/24 detail included rt1.m21.co.in and my.hostmatrix.in reverse names and a recent path reaching an M21 address from a Mumbai measurement point.

Taken together, those observations support three claims. First, M21 controls or is authorised to originate a modest body of public IPv4 space. Second, the space carries hosting activity rather than being entirely parked. Third, the network has maintained external reachability over a period measured in years. Those claims matter to customers seeking regional hosting in central India. A small network can serve local businesses effectively, and a Nagpur placement may offer lower access latency for some users than a distant metropolitan hub.

The same data cannot support a capacity figure. There is no valid conversion from 1,024 IPv4 addresses to racks, servers, kilowatts or occupied floor area. Network address translation, virtual hosting and shared web servers can place many domains behind a handful of addresses. Conversely, a large private computing estate may expose few public addresses. IPinfo's count of hosted domains describes observed naming concentration, not contracted compute load. The four routes are also all /24s, the common smallest IPv4 block accepted across much of the global routing system; route count alone says little about traffic volume.

Nor does route visibility measure headroom. A route can remain announced while every customer service behind it is unavailable. A border router and an upstream circuit may have power even when storage, virtualisation hosts or cooling-supported server rows have failed. The opposite can also occur: servers may remain healthy while an external route withdrawal makes them unreachable. Capacity is usable only when the full dependency chain works at the same time: utility or generator power, switchgear, UPS, rack distribution, cooling, controls, carrier access, routing, fire safety, security and staffed operations.

M21's address portfolio also contains an ownership clue that requires explanation. APNIC registers 163.227.38.0/23, the parent block of M21's other two announcements, to “PRECISION DATACENTER, PRECISION E TECHNOLOGIES PRIVATE LIMITED” at a different Nagpur address. Reverse names in that space use precisiontech.in. AS141294 originates the two /24s, but registry ownership remains with the Precision organisation. This may reflect a legitimate transit, hosting, address-origin or commercial arrangement. It does not by itself prove common ownership, a facility lease or a corporate relationship. The evidence needed to settle the boundary is a current letter of authorisation, route contract, site schedule and service-responsibility matrix.

This mixed portfolio is not necessarily a weakness. Originating customer or partner address space is normal for hosting networks. Yet it reinforces why asset claims must be separated into owned, leased and operated components. Two /24s are directly described as M21 resources; two are described as Precision resources but routed by M21. A prospective customer needs to know which addresses it would receive, who can authorise their routing, what happens at contract termination and whether the underlying holder can revoke the arrangement.

A prospective investor needs to know whether revenue attributed to M21 depends on infrastructure owned by another business.

Two observed neighbours may still collapse into one physical path

External databases do not agree perfectly on M21's immediate connectivity. RIPE NCC's ASN-neighbours view observed AS133007, UCN Cable Network, and AS151690, Fab Five Network, on the left side of paths to M21. IPinfo also listed both as upstreams. bgp.tools displayed UCN as the upstream while listing both networks as peers. Such differences are normal because collectors observe routes from different places and classification methods vary. The safe statement is that two adjacent autonomous systems have recently been visible, not that M21 has two fully independent transit services.

Logical diversity and physical diversity are different products. Two border sessions can run over fibres in the same duct, enter through the same building sleeve, terminate on the same optical equipment, depend on the same metropolitan provider or backhaul to the same city. A road excavation, building-entry fire, failed patch panel or upstream power incident could then remove both. Even contracts with two companies may converge on shared underlying infrastructure. The public route table cannot reveal that common mode.

The absence of an AS141294 record in the public PeeringDB network interface at the observation date leaves another gap. PeeringDB is voluntary, so no record is not proof that M21 lacks exchange ports or private interconnection. It does mean customers cannot use that widely consulted directory to verify exchange presence, facility names, traffic policy, contact roles or port capacity. Hurricane Electric's India network table also shows the small scale of M21's visible network: four IPv4 prefixes, no IPv6 prefixes and two observed peers. Again, this is a routing snapshot, not a service verdict.

Carrier resilience must therefore be established with physical evidence. The useful document is not a map with two coloured lines. It is a site drawing that traces each service from separate building entry points to separate meet-me or network rooms, shows duct and riser separation, identifies every active and passive shared component, and names the upstream handoff location. Contracts should specify committed bandwidth, burst treatment, repair targets, escalation routes and whether the second service is active under ordinary load or merely cold standby.

M21 should also demonstrate failure rather than describe it. A controlled test should remove each external path while representative customer traffic continues, record route convergence and packet loss, and show that management access remains available. The test should include loss of a border router, optical handoff and meet-me-room power feed. If both observed neighbours are reached through UCN infrastructure at some layer, that dependency should be disclosed. If Fab Five supplies a genuinely separate path, the route and entrance separation should be documented.

IPv6 is another unresolved capacity question. Current sources show no IPv6 originated by AS141294. Many small hosting customers can still operate on IPv4, but the lack of visible IPv6 narrows protocol resilience and future readiness. It may force customers to rely on translation or another network for dual-stack services. M21 should state whether IPv6 is available privately, planned, or unsupported, and whether its upstream design has been tested for dual-stack failover. The correct conclusion today is not that M21 has no redundancy.

It is that public routing evidence cannot prove the kind of redundancy a customer can safely price into an availability assumption.

Power turns a rack count into a serviceable-load question

Every data-centre capacity claim eventually becomes an electrical question. The number that matters is not the sum of server power-supply labels or the rating printed on a transformer. It is the critical IT load that can be supplied continuously in the least favourable allowed maintenance state, after cooling, pumps, controls, security and other support loads have been accounted for. Public material reviewed for M21 contains no number for utility service, transformer capacity, UPS output, rack density, generator rating or contracted demand.

This missing information prevents even a rough estimate of installed capacity. A room may contain space for twenty racks while having power and cooling for ten. A generator may have sufficient nameplate output while the transfer switch, fuel system or downstream distribution creates a smaller limit. A UPS may support the present load but leave no safe margin for battery ageing or a failed module. A sales figure based on floor area can therefore exceed simultaneously supportable customer load.

Uptime Institute's explanation of its Tier system provides a useful test without implying that M21 claims a certification. At the concurrently maintainable level, every capacity component and distribution path can be removed for planned work without affecting operations. Fault-tolerant infrastructure adds survival of an individual failure or path interruption. These are topological outcomes, not equipment shopping lists. A pair of generators does not establish either outcome if they share a fuel pump, switchboard, starting battery arrangement or control panel.

M21 should publish a simplified electrical one-line diagram under customer confidentiality terms. It should show utility sources, transformers, main switchgear, automatic transfer equipment, generators, UPS modules, bypasses, distribution boards and rack feeds. Each component should carry its continuous rating and present peak load. The operator should state the design state used when quoting available capacity: ordinary operation, one component unavailable, or one path under maintenance. Historical peak demand and power-quality events would reveal more than a theoretical maximum.

The phrase “dual utility feed” also needs precision. Two feeders from one substation may share a transformer, bus section, cable trench or protection scheme. A fault or planned outage at the common point can remove both. Genuine diversity requires the operator to identify substations, voltage levels, routes and automatic or manual transfer behaviour. If only one utility source exists, that can still support a viable small hosting facility, but customers must price the generator and fuel system as part of normal continuity rather than exceptional backup.

Generator autonomy is a chain of quantities and actions. Uptime Institute's fuel-system discussion treats twelve hours at the required load as a minimum starting point for Tier-defined sites and emphasises every pump, valve, control panel, bulk tank and day tank in the path. M21 makes no public claim against that benchmark. A buyer should ask for runtime at measured critical load, not tank volume alone; for fuel age and testing records; for refuelling contracts; and for delivery assumptions during a regional outage when roads, suppliers and other generator users are competing for diesel.

Battery autonomy is similarly easy to overstate. UPS batteries bridge the interval between utility loss and stable generator supply and protect against power-quality disturbance. Their usable duration changes with load, temperature, chemistry and age. Evidence should include the most recent discharge or impedance tests, replacement dates, alarm history and the demonstrated transfer time under realistic load. The critical test removes utility power and records whether generators start, stabilise and accept the full facility load without dropping IT or cooling support.

India's draft national data-centre policy is a policy proposal rather than a certification standard, but it correctly frames uninterrupted and clean electricity as a core enabling condition. A 2026 Press Information Bureau update says Indian data-centre capacity reached around 1,500 MW by 2025 and notes the sector's electricity and water needs. Those national totals do not validate M21. They show why a small operator competes for trust in a market where capacity is increasingly expressed in measured megawatts and where buyers can demand disciplined disclosure.

Nagpur heat makes cooling resilience part of electrical resilience

Nagpur's climate is not a background detail. The Maharashtra State Disaster Management Authority's 2024 Heat Wave Action Plan identifies Vidarbha among the state's most vulnerable regions and emphasises reliable water and electricity during extreme heat. An India Meteorological Department bulletin for 25 May 2026 recorded 46.5 degrees Celsius at Nagpur and forecast heat-wave conditions. These conditions raise heat-rejection demand just when the grid and backup plant may be under stress.

The effect on data-centre capacity is direct. Servers turn nearly all consumed electricity into heat. That heat must move from chips to room air or liquid, through cooling equipment and ultimately outside. As ambient temperature rises, air-cooled condensers and dry coolers can lose efficiency; compressors work harder; electrical consumption increases; and marginal components have less thermal headroom. A facility that can support a quoted IT load on a mild test day may have to derate during a 46-degree afternoon unless its equipment and redundancy were selected for the local design condition.

Humidity and contamination create different risks during monsoon conditions. Dust entering during the dry season can load filters and heat exchangers. Moisture can contribute to condensation or corrosion if control is poor. ASHRAE's contamination guidance for data centres explains why temperature and moisture limits alone do not capture corrosive environmental effects. M21 discloses no environmental envelope, filtration regime, sensor layout, cooling technology, water dependency or maintenance record.

This is not an argument that Nagpur is unsuitable for hosting. It is an argument that the site must be engineered and tested for Nagpur rather than for a generic brochure climate. A credible operator can show the outdoor design temperatures used, heat-rejection equipment ratings at those temperatures, the number and capacity of cooling units, and the result when one unit or one electrical feed is unavailable. It can show rack inlet temperatures at high load, hot-spot surveys and alarms from the hottest recent days.

Cooling continuity also determines how much UPS and generator capacity is genuinely available to IT. If backup calculations exclude chillers, pumps, computer-room units or controls, the server load may remain energised while inlet temperature rises toward shutdown. Uptime's Tier classification explanation notes continuous cooling as part of the fault-tolerant objective. M21 need not pursue that objective for every customer, but it should state what happens thermally during utility-to-generator transfer and after loss of one cooling component.

Water dependency requires the same candour. An air-cooled system may use little operational water but carry a larger hot-weather energy penalty. An evaporative or water-cooled design may be efficient yet depend on storage, treatment, pumps and municipal supply. The operator should state daily and peak water use, onsite storage duration, quality requirements and the response to supply interruption. If no process water is used, that is a useful resilience fact worth documenting.

The decisive evidence is a load test near the site's worst credible ambient condition. It should run long enough for thermal equilibrium, remove one cooling component, and record rack inlets, return temperatures, humidity, power draw and alarms. A short no-load generator start in cool weather cannot validate summer capacity. Until M21 discloses such evidence, the responsible estimate of usable load must remain below any unqualified installed or marketed figure.

Fire, water and the building envelope define the maximum loss

A data-centre outage is not always a component failure that redundancy can absorb. Fire, smoke, contaminated suppression discharge or water ingress can affect both sides of a nominally redundant design. The Nagpur District Disaster Management page links the district plan and maintains a local control room, while the Maharashtra district-plan index explains that district plans assess local hazards and response capacity. These sources establish the need to examine site hazards; they do not reveal M21's exact building location or protection measures.

That missing physical location limits analysis. The registry contact on Manewada Road may or may not be the equipment site. IP geolocation places some M21 addresses in Nagpur, but commercial geolocation is probabilistic and cannot identify a rack room. The two Precision-labelled prefixes are geolocated differently by some databases, another warning against treating an IP map pin as a facility address. M21 should disclose the actual site to contracted customers and provide enough information to assess surrounding land use, flood path, access, emergency response and utility exposure.

Fire protection should be demonstrated as a layered system. Early smoke detection, compartmentation, rated walls and doors, cable-fire stopping, suitable extinguishing systems, trained response and maintained alarms each address a different stage. The question is not whether cylinders or detectors are visible on a tour. It is whether the design matches the room volume and hazard, inspections are current, alarms reach staffed responders, and an incident in a battery, UPS, electrical or customer area can be isolated without disabling the entire service.

Water can enter from rain, drains, plumbing, roof failure, suppression or cooling equipment. A resilient site keeps critical switchgear, UPS, batteries and network entries away from likely ingress paths, uses leak detection and drainage, and understands which common risers or floors connect supposedly separate systems. Customers should see floor levels, drainage arrangements, roof and pipe inspection records and the response to recent heavy rain. “Not in a flood zone” would be only a starting statement; local drainage blockage and building-level leaks can still create a common-mode event.

Battery and fuel areas deserve explicit treatment because their hazards differ from ordinary office IT. Battery chemistry affects thermal-runaway controls, ventilation and extinguishing strategy. Diesel storage affects fire separation, spill containment and refuelling access. Generator exhaust and heat rejection must remain safe at full run. M21's public footprint provides no basis for judging these details, so no claim about fire or flood resilience should be inferred from uninterrupted route announcements.

Permitting evidence would help close this gap. A customer does not need every architectural drawing, but it should receive current occupancy, electrical-inspection and fire-safety documents applicable to the actual use. It should know whether local authorities classify the space as a dedicated data centre, commercial server room or another occupancy. Any material exception should be disclosed with a remediation date. Insurance schedules can also clarify which entity owns the plant and which losses are covered.

Physical security belongs in the same boundary analysis. Registry records and public DNS do not show whether visitor access, loading, spares, remote hands and customer cages are controlled. A modest facility can implement strong access practices without expensive theatre: named authorisation, two-person access for high-risk work, recorded entry, camera retention, secure media handling and separation between public offices and critical rooms. Evidence should be recent and site-specific.

Customer impact depends on the service layer, not merely the route

M21's visible footprint suggests shared hosting activity. IPinfo associates hundreds of hosted domains with AS141294, and reverse DNS on the M21 blocks includes web-hosting and control-plane names. This implies a customer impact surface broader than four network routes: websites, mail, DNS, virtual servers, management panels and backups may share hosts or support systems. The exact service mix, customer count and concentration remain undisclosed.

Shared infrastructure creates economies of scale but also concentrated failure. One physical host can carry many small sites. One storage array, licence service, authentication system or DNS pair can affect customers across multiple addresses. A route-level view may make the network look distributed while the service layer remains concentrated in a few servers. Buyers need a service architecture that identifies which components are clustered, which are single instances and which backups are isolated from the primary site.

The M21 domain itself illustrates why service evidence must be interpreted carefully. An expired public certificate and default control-panel page are concrete hygiene issues for the corporate endpoint. They do not prove that customer certificates are expired or that customer control panels are exposed in the same way. Still, a hosting provider should be able to explain asset ownership, certificate monitoring and removal of default pages because these are basic controls that customers reasonably use as signals of operational discipline.

Recovery claims require objectives and results. Recovery time states how long restoration may take; recovery point states how much data may be lost. Neither can be inferred from a nightly-backup label. The operator should specify backup frequency, retention, encryption, immutability where offered, storage location, restore priority and the last successful customer-representative restoration test. Backups in the same rack, storage system or building do not address a site loss.

NIST's contingency-planning guide is written for US federal systems, not as a rule for M21, but its separation of client/server, telecommunications and mainframe contingency concerns is broadly useful. Restoration must cover applications, data, communications, people and facilities. A hosting operator's plan should define who declares an incident, who can change routes or restore data, how customers are contacted and what happens when normal management systems are unavailable.

Customer failover evidence is stronger than a facility-only test. M21 should select representative services, remove an upstream, isolate a power path, stop a cooling unit and restore a backup while customers or independent observers verify continuity and data integrity. The results should record duration, packet loss, temperature, recovery actions and exceptions. A test that avoids production-like load proves less than one that reproduces the dependencies customers actually buy.

The likely blast radius is uneven. A local brochure site may tolerate several hours offline, while a retailer can lose orders, a professional firm can lose mail, and an organisation using hosted DNS can find otherwise healthy systems difficult to reach. If the same provider supplies web, mail, DNS and backup, one site incident can remove both the primary service and the tools needed to explain or restore it. Resellers add another layer: the named customer may support dozens of small organisations that have no direct contact with M21 and learn about an outage only through their intermediary.

Public evidence does not identify such customers, so this is a dependency model rather than a claim about M21's account list.

The operator should map impact by service class and concentration. It should know how many customer services depend on each host, storage unit, top-of-rack switch, DNS server, carrier handoff and power branch, and use that map to set restoration order. Customers supporting payments, healthcare, public information or other time-sensitive functions need explicit escalation and geographic recovery; ordinary shared-hosting customers still need an honest estimate of restoration time. The same map helps prevent a maintenance action on a seemingly minor control system from becoming a broad outage.

Without it, capacity planning counts servers but misses the business services concentrated behind them.

Contract language should follow the architecture. An availability percentage without exclusions, measurement points and remedies can conceal a narrow promise. Customers should know whether the service level covers network reachability only or also host, storage and control-panel availability; whether planned maintenance is excluded; and whether an upstream outage counts. Service credits do not compensate for unrecoverable data or prolonged business interruption, so critical customers need their own geographic replication and tested exit path.

Installed, lit, sellable and resilient capacity are four different numbers

The strongest way for M21 to improve confidence is to publish a capacity bridge. “Installed” capacity could mean equipment placed in the building. “Lit” capacity means connected and ready to operate. “Sellable” capacity removes existing commitments and operating reserves. “Resilient” capacity is the load that still meets the promised service state when a defined component or path is unavailable. These quantities can differ sharply.

A truthful bridge begins with location and ownership. For each site, M21 should state gross rack positions, installed racks, occupied racks, utility capacity, generator-backed capacity, UPS output, cooling capacity and the lower critical-load limit after the required redundancy is reserved. It should identify customer equipment that is single-corded, because Uptime Institute's discussion of dual-corded power explains how the device layer can defeat redundant facility feeds. A rack connected to A and B supplies is not protected if all important devices ultimately depend on one feed.

Capacity should also be reported by density. Ten lightly loaded web-hosting racks present a different cooling and distribution challenge from ten high-density compute racks. Average density can conceal a local hot spot or branch-circuit limit. A buyer should see maximum approved rack load, the number of racks that can support it simultaneously, and any restrictions on equipment airflow or power-factor characteristics.

Maintenance state is the crucial denominator. If one UPS module is removed, can the remaining modules support present customer load plus cooling? If one generator is unavailable for service, can the site carry the same load through an extended utility failure? If the answer is no, ordinary maintenance reduces the protected capacity, and sales headroom should be reserved accordingly. Concurrent maintainability is valuable precisely because planned work is inevitable.

Carrier capacity needs a parallel bridge: physical ports, committed bandwidth, measured peak traffic, protected capacity after loss of one link, and route-convergence performance. Two 10-gigabit links do not create 20 gigabits of resilient capacity if one must carry the entire load after failure. Nor does spare bandwidth help if both circuits share a cut-prone route. M21's current four-prefix footprint may require modest bandwidth, but only traffic records can establish the margin.

Operational capacity includes people and spares. A small operator may have excellent engineers yet be exposed when one person is unavailable. M21 should identify 24-hour monitoring coverage, on-call depth, remote-hands response, critical spares and vendor support. It should show that maintenance and emergency authority are documented and that no single individual holds the only credential or knowledge needed for restoration. This is not a demand for a large staff; it is a demand that staffing match the service promise.

Financial capacity matters as well. Generators need fuel, batteries need replacement, cooling units need overhaul and carriers need payment. Public route continuity cannot establish whether reserves exist for lifecycle maintenance. Customers considering multi-year commitments should seek evidence of insurance, maintenance contracts and asset replacement planning, with commercially sensitive figures disclosed under appropriate terms.

What would move the evidence grade upward

M21 can move from a Weak evidence grade to Medium without revealing customer secrets. The first step is a dated site fact sheet naming the contracting entity, facility operator, city and ownership model. It should separate owned and leased plant and explain the Precision-labelled address space. The second is a capacity table that distinguishes installed, occupied, available and protected IT load.

The third step is engineering evidence: an electrical one-line, cooling diagram and carrier-path drawing, each simplified to protect security while preserving common dependencies. These should include ratings, present peaks and the state after removal of one component. Current fire and electrical inspection records, environmental trends and maintenance evidence would establish that the drawings correspond to an operating site.

The fourth is demonstrated performance. M21 should provide recent results from utility-loss, generator-load, UPS, cooling-component, carrier-failover and data-restore exercises. The tests should identify load, duration, observers, exceptions and corrective actions. Customers do not need a perfect record; they need proof that weaknesses are found, owned and closed.

The fifth is customer-level transparency. Service descriptions should identify what is redundant and what is not, where backups reside, how maintenance is communicated and how a customer can migrate data and addresses. Public status history or anonymised incident summaries would show whether recovery promises survive contact with real events. Route-origin history can supplement this evidence but cannot replace it.

An independent facility certification could strengthen confidence, but labels must be exact. Uptime Institute's certification overview distinguishes design documents, constructed facilities and operational sustainability. A design award does not prove that the completed site matches the drawings; a constructed-facility award does not by itself describe every customer service. M21's public material reviewed here shows no such claim, so none should be implied.

Investment evidence should be treated with the same discipline. New racks, servers or address blocks may indicate expansion, but they do not establish sellable resilient capacity unless power, cooling and carrier headroom expand with them. A construction announcement is not an operating asset. A purchase order is not an installed system. A commissioned system is not proven until tested under load. Customers and investors should date-stamp each stage.

The unresolved relationship with Precision is a particularly efficient test of disclosure quality. If M21 provides transit for Precision, it can say so. If it hosts Precision equipment, it can define the site and responsibility boundary. If the two businesses share people, facilities or plant, common dependencies should be disclosed. If the routing arrangement is temporary, customers need to know whether services rely on it. Clear answers would improve confidence; ambiguity should be priced as concentration risk.

The present verdict: active network, unproven resilience

M21 Data Center has passed the most basic existence test. AS141294 is registered, has been visible for years, originates four current IPv4 /24 routes and carries apparent hosting activity. Two neighbouring networks are observable, route-origin authorisations are reported as valid, and M21's own domain sits inside its routed space. These are stronger signals than a company name or static listing.

It has not passed the facility-capacity test in public. No reviewed source identifies an operating site's rack count, critical IT load, utility arrangement, UPS design, generator endurance, cooling topology, water dependency, fire protection, flood defence, carrier entrances, staffing model or tested recovery performance. The public website's default page and expired certificate add a limited negative signal, while the Precision-owned address block introduces an unresolved operating boundary.

The correct response is not to declare the network fictitious or unsafe. It is to resist converting route observations into claims they cannot bear. A /24 announcement is evidence of reachability. Two adjacent autonomous systems are evidence of logical connectivity. Neither proves that customer equipment will survive a utility outage, a 46-degree day, a cooling failure, a fibre cut or a building incident.

For a small business buying non-critical regional hosting, M21 may still offer a useful service at an appropriate price. The customer should maintain external DNS, independent backups and a tested migration path. For workloads where downtime or data loss creates material harm, the burden of proof is higher: documented site design, measured headroom, physically diverse connectivity, witnessed failover and off-site recovery.

M21's opportunity is to turn an observable network into an investable operating story. The underlying questions are practical rather than grand: where is the equipment, who owns each dependency, what load can be protected, what fails together, how long can the site run without the grid, and when was recovery last demonstrated? Until those answers are available, marketed capacity should be treated as a hypothesis and resilient capacity as undisclosed. The final network evidence grade is Weak, not because nothing is operating, but because the evidence stops at the edge of the building where the hardest dependencies begin.