Summary

  • The public identity does not support treating DATACENTER OPERATIONS as a separate legal company. ARIN registers AS18521 to American Campus Communities, Inc and identifies DATACENTER OPERATIONS as a validated role contact attached to that organisation.
  • A live network is visible, but it is small: one IPv4 /24, no visible IPv6 space, one observed upstream relationship and no PeeringDB network record. That is evidence of routing activity, not evidence of a carrier-neutral data-centre business.
  • No public facility address, utility allocation, generator runtime, cooling topology, fire-protection design, carrier meet-me room, colocation tariff, certification or customer failover result was found under this name. Marketed megawatts, racks and saleable capacity therefore remain unverified.
  • American Campus Communities publicly offers internet service at student-housing properties, so network failure could affect residents and property operations. The available records do not establish that AS18521 carries those services, nor that the role contact owns or operates the buildings, access circuits or hosting rooms involved.
  • The operating-status verdict is network active, data-centre operation unproven. Any commercial infrastructure claim under the DATACENTER OPERATIONS name should remain downgraded until the operator supplies site-specific power, cooling, carrier and service evidence.

The name is not the company

The first capacity constraint is not electricity. It is identity.

The BTW directory entry presents DATACENTER OPERATIONS as a data-centre or colocation provider linked to AS18521. Read alone, the uppercase name resembles a corporate trading style. The registry record behind the ASN tells a different story. ARIN's record for AS18521 gives the autonomous system the name AMERICAN-CAMPUS-COMMUNITIES and assigns the registrant role to American Campus Communities, Inc. Within the same record, DATAC10-ARIN appears as the technical, administrative, abuse and network-operations contact.

That distinction is structural, not semantic. ARIN explains that a Point of Contact can be a person or a role account associated with an organisation or an internet number resource. Its separate DATAC10-ARIN record describes the contact as a group, supplies studenthousing.com email addresses and uses the same Austin mailing address that American Campus Communities publishes on its own website. The ACC-345 organisation record, by contrast, identifies American Campus Communities, Inc as an organisation and nests DATAC10-ARIN beneath it as a contact.

The practical reading is that “DATACENTER OPERATIONS” is the name of an internal operating function or role mailbox. It may represent people responsible for equipment in a private computer room, a contracted facility or several sites. It does not, by itself, establish incorporation, ownership, a customer-facing brand, a leasehold, a facility licence or authority to sell colocation. Capital letters do not turn a contact record into a company.

This matters because every later claim depends on the ownership boundary. A data-centre landlord may own the shell and electrical plant while a tenant owns racks. A colocation operator may lease a powered suite while carriers own the fibre. An enterprise IT team may control servers but neither the generators nor the building. A student-housing operator may provide internet as a residential amenity through local access suppliers without operating a commercial data centre at all. Those arrangements create very different failure responsibilities.

The public evidence supports only the last layer with confidence: American Campus Communities has a network resource and a role contact responsible for it. It does not support the directory's separate legal-company description. Until a legal name, trading name, contract party or facility operator is produced, DATACENTER OPERATIONS should be understood as an operational label attached to American Campus Communities, not as an independently verified infrastructure company.

A live route is the one hard operating signal

The identity correction does not make the network imaginary. AS18521 is visible in current routing data.

The RIPEstat overview identifies the holder as American Campus Communities and reports the ASN as announced. Its routing-status view shows one IPv4 prefix covering 256 addresses, no IPv6 announcement and one observed neighbour. The announced-prefixes record names that route as 216.54.130.0/24. This is meaningful operating evidence: at the observation date, global route collectors could see the ASN originating a usable block.

The shape is nevertheless much closer to a small enterprise edge than to a broad colocation network. CAIDA's AS Rank record reports one provider, no customers, no peers, one originated prefix and 256 addresses in the customer cone. BGP.Tools likewise reports one IPv4 prefix, no IPv6 prefix and Charter Communications' AS11427 as the upstream. RIPEstat's BGP-state output repeatedly places AS11427 immediately before AS18521 in observed paths. These independent views converge on a narrow public routing surface.

There are important limits to that inference. Route collectors do not see private circuits, internal routing, standby links that announce nothing, software-defined overlays or a second carrier used only during failure. A single visible upstream does not prove there is only one physical fibre. Conversely, two commercial contracts would not prove physical diversity if both circuits enter through the same duct, building entrance or carrier aggregation point. Public BGP gives a view of advertised reachability, not a cable survey.

The negative interconnection evidence is still relevant. A direct query to the PeeringDB network interface for ASN 18521 returns no network entity. There is therefore no operator-maintained PeeringDB disclosure of exchange ports, facility presence, traffic levels, interconnection policy or network operations contacts. PeeringDB is voluntary and incomplete, so absence is not proof that the network has no facility presence. It does mean that a buyer cannot independently verify a carrier meet or exchange footprint there.

The originated address space also has a dependency boundary. ARIN's record covering 216.54.130.0 places the address inside the larger TWTC-NETBLK-1 allocation registered to Level 3 Parent, LLC. Its remarks describe addresses in the block as non-portable and subject to continued service conditions. That is different from a directly allocated portable block under the end user's own control. If the commercial service associated with the parent allocation ends, address continuity may become part of the migration risk.

The RIPEstat RPKI check reported the route's validation status as unknown and found no validating route-origin authorisation at the observation date. An unknown state is not an invalid route, and it does not say the announcement is unauthorised. It means the cryptographic origin-validation layer did not provide affirmative protection for this origin-prefix pair in that view. For a network presented as resilient infrastructure, that is another control to clarify rather than another megawatt to claim.

The narrow conclusion is defensible: AS18521 is active, globally visible and associated with American Campus Communities. The same facts do not establish a data-centre site, a colocation product, a diverse carrier fabric or any customer-available capacity.

The address locates responsibility, not infrastructure

ARIN's organisation and contact records both use 12700 Hill Country Blvd, Suite T200, Austin, Texas 78738. American Campus Communities publishes the same address and telephone number on its corporate website and its communities page. That match is strong evidence that the role contact belongs with ACC. It is weak evidence about where routers, servers, generators or cooling equipment sit.

A mailing address can be a headquarters office, a property-management suite, a billing point or the administrative address for assets located elsewhere. Even if equipment is present in the building, the public record supplies no room number, floor area, rack count, landlord, utility meter, critical load or facility operator. It does not show whether the route terminates in Austin, at a carrier hotel, in a managed hosting cage or at a student-housing property.

One unofficial market view adds a clue but not a site. IPinfo's page for the prefix reported a recent trace reaching AS18521 through Charter's network and labelled an important router in San Antonio. Geolocation and traceroute interpretation can be wrong: router names may describe a carrier node, database locations may follow registration addresses, and the endpoint may be remote from the servers it supports. This signal suggests a Texas network edge worth testing. It cannot establish that DATACENTER OPERATIONS owns a San Antonio facility, has customer racks there or draws a particular utility supply.

Without a verified street address for the technical facility, four essential tests cannot even begin. The utility service territory cannot be identified. Local planning and building approvals cannot be matched to the operator. Carrier entrances and conduit routes cannot be inspected. Site hazards such as floodplain, wildfire, storm and adjacent-use exposure cannot be mapped with confidence. The FEMA Flood Map Service Center is the official US source for address-level flood-hazard information, but a corporate mailing address should not be substituted for an undisclosed equipment site.

The same caution applies to the “Global” region label. Global route visibility means networks around the world can learn a path to the prefix. It does not mean the operator has data centres around the world. The public corporate footprint of American Campus Communities is broad across US university markets, but no evidence reviewed here ties AS18521 to every property, much less to a global colocation estate. Geography must follow physical assets and contracts, not the propagation range of a BGP announcement.

An operator seeking to establish the facility layer would need to disclose, at minimum, each technical site's address or independently verifiable facility identifier; the party that owns the building; the party that operates critical plant; the suite or room under its control; the date service began; and the service sold from that location. Until then, the physical asset base remains unknown.

Capacity has six different meanings

Data-centre marketing often compresses six stages into one capacity number. They should be separated here because none is publicly evidenced under the DATACENTER OPERATIONS name.

Planned capacity is what a concept, planning application or investment announcement proposes. It may have no land control, utility reservation or construction contract. Designed capacity is what drawings and engineering studies say a completed building could support. It may still depend on substations, generators, chillers and carrier work that have not been installed. Installed capacity is equipment physically in place. A nameplate rating can overstate what the system can deliver after redundancy, derating and ambient conditions are considered. Energised capacity has passed commissioning and can receive power. Usable critical load is what can be delivered to IT equipment while preserving the promised redundancy and cooling margin. Customer-available capacity is usable load that is not already occupied, reserved or blocked by another constraint.

A seventh commercial number is often confused with all six: contracted capacity. A megawatt can be sold before it is energised, and an energised megawatt can be unavailable because cooling or switchgear is the bottleneck. Rack count is no better without density. One hundred racks designed for 5 kilowatts each are not equivalent to one hundred racks intended for 40 kilowatts each. Floor area does not disclose power. Generator nameplates do not disclose utility capacity. Utility capacity does not disclose the cooling envelope.

No public material reviewed for DATACENTER OPERATIONS states any of these quantities. There is no building area, number of data halls, rack inventory, design megawatt figure, installed transformer rating, energisation notice, critical IT load, occupancy level or available-capacity figure. There is also no tariff or order form showing that an outside customer can buy a cabinet, cage, cross-connect, remote-hands service or power allocation.

This absence changes how the company should be described. It is not reasonable to infer a facility from the word “datacenter” in a contact name. It is not reasonable to infer capacity from a /24; 256 addresses can support a compact office edge, network appliances, resident-facing services, hosted applications or many other arrangements. It is not reasonable to infer carrier neutrality from an ASN; enterprises obtain ASNs to control routing without selling interconnection. And it is not reasonable to infer spare capacity from a live route, because reachability says nothing about electrical headroom.

The US Department of Energy's current data-centre design guide spans IT conditions, air management, cooling, electrical systems, heat recovery and benchmarking. That breadth illustrates why a credible capacity statement needs a balanced engineering envelope. The maximum customer load is bounded by the weakest commissioned subsystem, not the largest number in a brochure.

For this entity, every capacity figure should therefore remain “not publicly established” rather than zero. Zero would claim knowledge that no equipment exists. The evidence supports a more precise finding: a routed network exists, while the size, location, ownership and usable capacity of any computing facility behind it are undisclosed.

Network scale is not facility scale

The /24 is useful because it sets an upper bound on what can be observed, but it is a poor proxy for the physical estate. Address use changes with network design. Carrier-grade network address translation, private addressing, virtual hosting and cloud front ends can support large service populations with little public space. At the other extreme, an organisation can retain a lightly used prefix for stable corporate systems. Neither arrangement discloses the number of servers or the watts behind them.

The absence of IPv6 is similarly a network-modernisation signal, not a capacity measurement. It may reflect application requirements, upstream configuration, migration priorities or an undisclosed deployment. It does not prove obsolete equipment, and it does not reveal whether the associated room is full or nearly empty. For commercial colocation, however, buyers would reasonably expect the operator to explain its addressing options, route-security controls, upstream choices and migration support.

Facility scale must be measured in commissioned critical load and supported rack density, with the cooling and redundancy state attached. Network scale must be measured in reachability, traffic, interconnection and route control. Business scale must be measured in contracts, customers and occupied capacity. DATACENTER OPERATIONS has one observable fact in the second category: a live origin route. It has no public measurements in the first or third.

Keeping those units separate prevents a common analytical error. The active route means the role contact should not be dismissed as a dead database residue. The small route does not make the underlying systems trivial. But neither point turns an internal network function into a data-centre investment proposition. That transition requires site and service evidence.

Power proof is absent at every layer

Power availability is the first physical test of a data-centre claim because servers convert electricity into heat continuously. The power chain normally runs through utility service, substations or transformers, switchgear, uninterruptible power supplies, distribution equipment and rack-level delivery. Backup generation adds another chain of engines, controls, fuel storage, pumps and replenishment contracts. A weakness at any point can reduce the IT load that remains supportable during maintenance or failure.

DATACENTER OPERATIONS discloses none of that chain. There is no named utility, service voltage, committed megavolt-ampere allocation, feeder count, substation, transformer topology, UPS configuration, battery autonomy, generator count, generator output, fuel type or tested runtime. There is no evidence that two utility feeds, if they exist, originate from separate substations or avoid a common transmission constraint. There is no load-bank test, black-start result or record of a full transfer under production load.

The distinction between component redundancy and system resilience is central. Two generators can share one control panel. Dual utility feeds can enter through one vulnerable duct. An N+1 design can lose its spare during maintenance. Fuel tanks can be full while the resupply route is blocked. Batteries can bridge a short interruption but fail before generators stabilise. What matters is the end-to-end sequence under the actual critical load, including the maintenance state in which one component is already unavailable.

The Uptime Institute's explanation of its Tier system describes Tier III as concurrently maintainable and Tier IV as fault tolerant. It also stresses that a site's long-term performance depends on how it is operated. DATACENTER OPERATIONS makes no public Tier claim that could be checked, and no certification was identified. It would be wrong to award an implied tier merely because the contact name contains “datacenter”.

Backup duration is equally unknown. Uptime's discussion of fuel-system reliability explains that its Tier topology starts with a 12-hour minimum fuel-storage requirement at the necessary load while maintaining the relevant topology objective. That is a benchmark, not evidence about this network. No public record says whether any associated room has generators at all, how much fuel is stored, whether local rules constrain testing, or whether refuelling has been exercised during a regional outage.

Permitting can constrain capacity even after equipment is purchased. The US Environmental Protection Agency's data-centre resources note that primary and backup generating equipment can be subject to air-emission standards and that state and local agencies issue many relevant permits. A site name and generator schedule would allow those records to be checked. Neither is public here.

Texas now offers another reason not to equate proposed load with delivered load. ERCOT's June 2026 large-load connection framework groups qualified projects of 75 MW or more for study so that location, grid capacity and transmission upgrades can be considered together. There is no evidence that DATACENTER OPERATIONS has submitted such a request, and nothing suggests a load near that threshold. The point is methodological: even a well-funded project does not have usable power until the relevant grid and utility work is approved, built, commissioned and kept within operating limits.

The correct power verdict is therefore not “redundant” or “non-redundant”. It is unverified. A credible operator statement would identify the site, utility, firm service, maximum critical load, redundancy basis, maintenance state, UPS autonomy, generator runtime, fuel-resupply assumptions and latest integrated systems test. Without those facts, there is no defensible conversion from marketed capacity to survivable capacity.

Cooling can strand power that exists

Electrical service is only half the capacity equation. Every watt consumed by IT equipment emerges almost entirely as heat that must be removed. A room can have spare breaker capacity and still be unable to accept another rack because airflow, chilled water, condenser capacity or water availability has reached its limit.

No cooling evidence is public for DATACENTER OPERATIONS. There is no indication whether associated equipment uses comfort air conditioning, dedicated computer-room air handlers, direct expansion units, chilled water, evaporative cooling, rear-door heat exchangers or liquid cooling. There is no design temperature, humidity range, rack-density limit, containment scheme, cooling redundancy, water source, leak-detection system or thermal commissioning result.

That gap matters particularly for a name that could describe an internal enterprise room. A server room inside an office can be entirely functional without having the plant or operating discipline expected of commercial colocation. It may depend on the building's shared mechanical system. Maintenance may require a shutdown. Heat rejection may have no redundant path. None of those possibilities can be selected from the public record; each remains a question.

The Department of Energy's cooling-water guidance describes a typical evaporative system in which chilled-water and condenser-water loops transfer heat to a cooling tower. It also defines power usage effectiveness as total facility energy divided by IT-equipment energy and water usage effectiveness as annual site water divided by IT-equipment energy. These measures become informative only when the underlying boundary and load are disclosed. DATACENTER OPERATIONS publishes neither PUE nor WUE, and a generic industry average should not be assigned to it.

Operational resilience requires more than an efficient annual ratio. A cooling plant must survive the loss of a pump, fan, chiller, control system or water supply for long enough to protect workloads. Operators need to show what happens during utility transfer, because cooling equipment may restart differently from IT equipment. They need to show how hot spots are detected, how rapidly temperatures rise after a failure, which alarms are staffed and what load must be shed first. Maintenance windows matter because redundant equipment is only useful if it can be isolated without interrupting the remaining path.

High-density computing sharpens those questions, but there is no evidence that this entity hosts high-density racks. The conservative issue is more basic: even a small private room needs enough continuous heat removal for its actual load. Public route visibility can persist while applications fail from overheating. Conversely, a well-cooled room can lose external service if its only carrier path is cut. Resilience must cover both systems together.

Fire and water risks sit at their intersection. The NFPA 75 public standard page identifies construction, fire detection and protection, utilities, emergency procedures and recovery as distinct parts of protecting information-technology equipment. No site-specific fire detection, suppression, compartmentation, leak detection or emergency response information is available under the DATACENTER OPERATIONS name. A buyer therefore cannot assess whether a local equipment fault would be contained or whether a building event would remove the whole network edge.

Cooling capacity remains wholly unquantified. Until the operator supplies commissioned thermal limits, redundancy diagrams, alarm coverage and maintenance evidence, no amount of nominal electrical supply can be called customer-usable data-centre capacity.

Carrier diversity is claimed by neither routes nor facilities

A data centre without external connectivity is a powered warehouse. The relevant carrier question is not how many logos can be named but how many independent paths survive the same incident.

The public routing view for AS18521 is narrow. RIPEstat observes one neighbour. CAIDA classifies one provider. BGP.Tools names Charter's AS11427 as the upstream. There is no PeeringDB record listing exchange participation or facility presence. Taken together, these facts support one visible upstream routing relationship. They do not establish a carrier-neutral meet-me room, a second transit provider, a private interconnection fabric or a dark-fibre route.

They also do not conclusively prove single-homing. A backup circuit may remain silent until failure. One provider may supply physically diverse services. Private links may not appear in global route data. The correct finding is therefore “one publicly observed upstream, diversity unproven,” not “only one cable exists.”

Physical commonality is the hidden risk. Two circuits bought from different brands can lease the same local fibre, cross the same bridge, enter through the same vault or terminate on the same metro equipment. Two entries on opposite walls can converge at the property line. Two routers can share one power distribution unit. A meet-me room can be diverse at the carrier level but vulnerable to one building fire or flood. Contract count is a weak substitute for route drawings and failure tests.

NIST's Security and Privacy Controls for Information Systems and Organizations treats alternate telecommunications as a continuity control. Its CP-8 discussion calls for reducing shared single points of failure, obtaining provider separation where appropriate and seeking transparency into actual physical transmission capability. The guidance is not a certification for commercial data centres, but it expresses the right evidentiary standard: diversity must be demonstrated below the invoice level.

No public material for DATACENTER OPERATIONS identifies building entry points, conduit owners, carriers, cross-connects, meet-me rooms, exchange ports, wavelengths, transit commits or tested failover times. No customer report shows traffic moving to an alternate path during maintenance or an outage. No network status archive exposes incident duration. No service-level agreement defines restoration or credits.

The single originated /24 introduces an additional recovery question. The parent address allocation is registered to Level 3 Parent, while the visible path reaches AS18521 through Charter. The available records do not explain the contractual arrangement or whether the prefix can be announced through another provider under current authorisations. A migration or failover plan should state who controls the address assignment, who can issue letters of authorisation, which networks will accept the route and how origin validation is handled.

An outside customer considering this infrastructure would need a current carrier matrix, route maps with common segments identified, letters confirming building entries, live and maintenance-state failover tests, and a clear demarcation between landlord, carrier and operator responsibilities. None is public. The carrier-meet verdict is therefore weaker than the route-status verdict: reachability exists, but the physical and contractual diversity needed for a resilient colocation product is unproven.

American Campus Communities defines the likely service context

The registrant behind AS18521 is not obscure. American Campus Communities describes itself as a developer, owner and manager of student housing. Its about page focuses on residential communities, university partnerships, development and property operations. It does not present ACC as a commercial data-centre or colocation provider.

The ownership context changed in 2022. Blackstone's completion announcement says its funds acquired ACC for approximately $12.8 billion including assumed debt. At June 30, 2022, the announcement reported 166 owned student-housing properties with about 111,900 beds and a total managed portfolio of 204 properties with about 143,100 beds. ACC's last public-company 2021 annual filing likewise describes a real-estate portfolio built around student housing, ground or facility leases, development and property management.

This corporate scale creates a plausible reason for an internal data-centre function. A nationwide property operator needs identity systems, finance and leasing applications, communications, security services and operational support. It may use private infrastructure, outsourced hosting, cloud services or a mixture. The ARIN role name could refer to the team responsible for that environment. Plausibility is not proof of any particular architecture.

ACC also markets connectivity to residents. Its Plaza Verde II property page advertises internet included in every unit and service up to 1 Gbps per bed. Other community pages make similar promises in several markets. This gives the network question a real human consequence: failures in residential connectivity can disrupt study, remote work, communications, building operations and customer support.

But the service promise must not be mapped automatically onto AS18521. Property internet may be delivered by university networks, local carriers, managed Wi-Fi suppliers or site-specific access networks. Traffic may never cross the single /24. The public material does not identify which properties use ACC-originated addresses, whether ACC is the internet service contract party, or whether the corporate role contact manages resident access. It also does not identify any colocation customers outside the corporate group.

ACC's current sustainability reporting reinforces the property boundary. The 2024 impact update discusses student communities, building certifications, energy and water performance, and resource conservation. Those disclosures are useful for understanding a large housing estate. They do not provide the electrical one-lines, cooling limits, generator schedules or carrier inventory for an identifiable data-centre site.

The likely customer surface is therefore asymmetrical. There is credible evidence of a large student-housing business whose operations and some resident services depend on digital systems. There is no credible public evidence of a customer base buying colocation from a separate DATACENTER OPERATIONS company. When the visible network fails, the potentially affected groups may include ACC staff, property teams, residents or counterparties, but the scope cannot be measured from the ASN alone.

That context makes resilience important while weakening the commercial classification. The public record looks like enterprise infrastructure supporting a property operator, not a global carrier-neutral facility business.

Failure paths cannot be tested without an asset boundary

Five failure paths were central to this review: utility outage, cooling failure, carrier interruption, construction or commissioning delay, and fire or flood. Each produces a different evidence demand. None can be resolved for DATACENTER OPERATIONS because no facility boundary has been established.

During a utility outage, the decisive timeline runs from static bypass and batteries through generator start, transfer and fuel resupply. The operator would need to show the maximum production load, battery autonomy under aged conditions, generator start success, maintenance state and tested runtime. No such data is public.

During a cooling failure, thermal inertia rather than fuel becomes the clock. Rack inlet temperatures can rise even while electrical power remains stable. The relevant evidence includes sensor coverage, alarm response, redundant cooling paths, restart behaviour and a controlled load-shedding plan. None is public.

During a carrier interruption, BGP may reconverge only if an alternate physical path and accepted route exist. The public view shows one upstream. There is no documented second carrier, separate entry or customer-observed failover. A single cut near the building could therefore be harmless, partially disruptive or total; the evidence cannot distinguish among those outcomes.

A construction or commissioning delay is relevant only if capacity is being built or expanded. No announced project, planning case, construction schedule or commissioning milestone was identified under this name. That means there is no basis to count future capacity, but also no basis to say a project has failed. The status is undisclosed, not delayed.

For fire and flood, site specificity is unavoidable. Fire compartments, battery chemistry, cable loading, suppression, drainage, raised floors and emergency access vary by building. Flood exposure depends on the actual equipment elevation and map location, not a headquarters postcode. With no verified technical site, assigning a hazard score would create false precision.

Recovery evidence is similarly absent. There is no stated recovery-time objective, recovery-point objective, alternate processing site, backup restoration result or incident exercise. NIST's contingency-planning guide notes that high availability inside one site does not address a facility-wide interruption and discusses extending resilience to an alternate location. DATACENTER OPERATIONS discloses neither same-site redundancy nor an alternate site.

The lack of public incident history should not be interpreted as perfect uptime. Private enterprise failures may never be reported publicly. The absence of customer complaints under a role-account name is particularly uninformative because users would more likely identify the property brand, carrier or parent company. Conversely, a general complaint about internet at one property would not prove failure of AS18521.

The only responsibly testable operating claim is the route itself. It was visible. Everything behind and around that route needs an asset map before failure analysis can move from scenarios to conclusions.

What evidence would change the verdict

The downgrade is reversible. A compact set of site-specific disclosures could establish whether DATACENTER OPERATIONS represents an internal room, leased colocation, a managed hosting environment or a genuine commercial facility operator.

First, the operator should establish identity and authority: the legal entity that contracts for space and power; the relationship between the DATACENTER OPERATIONS role and American Campus Communities; the owner of AS18521; and the party authorised to sell any service. A role mailbox can be a valid operational contact, but the customer contract must name a legal counterparty.

Second, it should establish the facility boundary: address or recognised facility identifier, building owner, operator, suite, service commencement date and whether space is owned, leased or managed. Sensitive room details need not be public, but enough information must exist for utility, permit and hazard claims to be independently matched.

Third, it should quantify capacity by stage: designed, installed, energised, usable, contracted and currently available critical load. Rack count should include supported density and redundancy state. Capacity should be reported per site, not rolled into an unexplained global number.

Fourth, it should document the power chain: utility, firm allocation, feeder and substation diversity, transformers, switchgear, UPS, batteries, generators, fuel storage, resupply contracts and latest integrated test. The figures should state whether they apply under normal operation, one-component maintenance or a failure condition.

Fifth, it should document cooling and environmental control: system type, commissioned thermal limit, redundancy, water dependency, containment, leak detection, alarm staffing and the effect of losing one component. PUE and WUE should include measurement boundaries and periods rather than appearing as context-free ratios.

Sixth, it should document the carrier meet: upstreams, facility entrances, conduit separation, meet-me rooms, cross-connects, exchange presence, private links, routing policy, address portability and RPKI status. A failover demonstration should show that production traffic moves without relying on a shared physical segment.

Seventh, it should publish operating evidence: commissioning date, staffed hours, maintenance regime, incident reporting, service-level terms, recent integrated systems testing and anonymised customer failover results. Certifications can support this case, but only when the certificate names the specific site and remains current.

Finally, it should define who depends on the system. If AS18521 supports only corporate applications, the risk belongs mainly to ACC's internal operations. If it supports resident internet, the affected properties and local access dependencies should be identified. If outside customers buy colocation, the operator should disclose the product boundary and restoration responsibility. These are not interchangeable claims.

Until that evidence appears, prospective counterparties should not use the directory label as proof of capacity, Tier level, carrier neutrality or global service. The live route can support a network-operations finding. It cannot support a facility-investment finding.

Verdict: active network, unproven data-centre operation

DATACENTER OPERATIONS has one strong attribute: a validated and recently maintained contact record attached to a live autonomous system. That gives the name an operational context. It does not give it a separate corporate identity or a commercial data-centre estate.

The clearest public chain runs from American Campus Communities to AS18521, from AS18521 to one routed IPv4 /24, and from that route to one observed upstream. The corporate parent operates a large US student-housing platform and advertises internet service at some properties. Those facts make the network relevant. They do not establish that the contact role owns the facility, controls utility and cooling systems, offers colocation, has diverse carrier entrances or can keep customer load operating through a site failure.

The marketed-capacity question therefore fails before the megawatt calculation. No marketed megawatts, racks or cabinets can be tied to a named site. No utility or cooling envelope defines usable load. No carrier-meet record defines external diversity. No operating history demonstrates maintenance without interruption. No alternate-site evidence demonstrates recovery from a building-wide event.

The appropriate evidence grade is weak for data-centre operations and medium for network identity. AS18521 should continue to be treated as a real, active network resource associated with American Campus Communities. DATACENTER OPERATIONS should not be treated as a verified standalone colocation provider unless the identity and asset boundary are corrected with stronger public records.

For infrastructure buyers, the implication is simple. Do not ask whether the advertised capacity is available until the operator proves that there is a facility and explains who controls it. Then ask how much power is firm, how much cooling survives maintenance, which carrier routes are physically separate, how long backup systems have actually run, and which customers have completed a failover. In this case, those questions are not yet diligence at the margin. They are the difference between a contact name and an operating data centre.