06 / Services
Colocation Infrastructure Installation_
Install your own infrastructure inside a third-party colocation facility with a clear division of responsibility. We coordinate the agreed physical IT work around facility access rules, approved rack positions and the equipment you provide.
For customers building inside someone else's facility_
For enterprises, managed-service providers and infrastructure owners fitting out leased cabinets or cages. This service helps your project team execute the customer-side installation while the colocation provider retains control of the facility and its services.
An available cabinet does not mean the project is ready to install. Escort rules, dock bookings, facility cross-connect orders and restrictions on working hours can interrupt the build. We document the dependencies and coordinate the interfaces in our scope so each party knows what must be ready.
Your provider retains hosting and facility services. Identify customer-side demarcations, orders, access rules and provider dependencies so the installation window is based on actual readiness.
Separate supplying a cabinet, installing that cabinet and installing equipment inside it. Equinix's Private Cages documentation allows customer-procured or Equinix accessory cabinets but states that Equinix performs cabinet installation in either case. Its Secure Cabinet comparison lists Equinix-owned cabinetry for Express and an Equinix or approved customer-provided cabinet for the configurable product. These are one operator's product descriptions, not approval for a particular cabinet or for Leviathan to install it. Confirm the actual provider-accepted arrangement before defining tenant work.
Customer-side installation scope_
Facility coordination
Review work rules, contacts, approved access and customer-side dependencies with your nominated facility representative.
Equipment readiness
Check the supplied equipment list, rail kits, staging arrangement and work package for installation gaps.
Rack and equipment fit-out
Install the agreed customer-supplied IT equipment to approved positions and handling conditions.
Cabling inside the authorized space
Route, connect, dress and identify the agreed customer-side IT cabling using approved pathways and endpoint records.
Provider interface records
Document customer-side endpoints and dependencies for facility-provided cross-connects or services; the provider performs its own work.
Installation documentation
Record installed items, agreed checks, deviations and unfinished customer or facility dependencies.
What to send with your inquiry_
Facility & Space
Customer inputFacility and cabinet/cage identifiers, rack elevations and equipment list.
Contacts & Access
Customer inputCustomer and facility contacts, access requirements and intended installation window.
Provider Interfaces
Customer inputProvider cross-connect order status and authorized customer-side demarcation details.
Connection Records
Customer inputLabel scheme, cabling schedule and the documents your operations team needs at handoff.
Readiness & Approval
Before engagementConfirm customer access rights, facility approval and provider-interface readiness for the work window.
A coordinated installation window_
Separate responsibilities
Identify which work belongs to the customer, Leviathan, the facility and other contractors.
Confirm access and dependencies
Review facility approvals, work windows, staging and readiness before mobilization.
Install the customer infrastructure
Carry out the authorized rack, device and physical IT cabling work.
Verify the agreed scope
Check placement, identification and the specified physical connections; record unavailable provider dependencies.
Close the work package
Review the installation record and remaining actions with the customer and relevant facility contact.
Assign the task, not just the equipment owner_
A useful colocation scope distinguishes who owns an item, who is permitted to perform the proposed task, who confirms its prerequisites and who receives its result. Those parties may differ. Owning the servers does not establish access to every facility interface; leasing a cabinet does not assign every task inside or around it to the tenant installer. Record the actual provider arrangement rather than choosing the performer from the asset owner alone.
For each work-package line, name the equipment or location, exact task, proposed performing party, prerequisite and its confirming owner, applicable customer/provider reference, and expected handoff record. If the performing party or permission is unresolved, leave that line open. This worksheet supports a scope decision; it does not grant access, replace a provider order or approve a technical method.
- Cabinet or cage readiness: The customer identifies the contracted product, accepted cabinet arrangement and cabinet/cage references. The provider confirms its own supply, installation and readiness responsibilities. Keep those tasks distinct from device fit-out; the named-operator product examples above do not transfer cabinet installation authority to Leviathan.
- Tenant equipment fit-out: Identify the devices, approved positions, supplied mounting parts and customer-side IT work requested from Leviathan. The customer supplies the approved input package and identifies its change approver. Actual inclusion, handling conditions, personnel and available work window must be agreed for the engagement.
- Provider services and demarcations: Identify the provider-controlled circuit or cross-connect and its order/readiness reference, then state the exact customer-side endpoint or record required. The provider performs its assigned work. A tenant installation entry cannot stand in for provider completion or acceptance.
- Receiving, staging and movement: State the supplying and delivery parties, the intended receiving/staging arrangement and who resolves missing items. Do not silently include freight, offload, heavy handling or loaded-cabinet movement in an equipment-mounting request. Actual permissions and methods remain separately defined.
- Checks and handoff: Name the agreed physical records, unavailable provider dependencies and customer recipient. Keep formal tests and facility, OEM, network or software acceptance with their appointed owners. A person receiving the installation record does not thereby accept every outside service.
The existing provider product documentation illustrates why the assignment matters: a cabinet can be customer-procured while its installation is still a provider task under that particular product. Use the actual site's current arrangement and instructions. This page makes no Equinix partnership, universal operator rule, engineering authority or provider-access claim.
Send a scope brief that can support a scheduling decision_
A requested date is a planning input, not a reserved installation window. A useful brief lets the parties identify the actual work, remaining dependencies and decision needed before resources or a site visit can be confirmed. Use the fields below as an inquiry worksheet. Mark an unknown explicitly and name who will resolve it instead of presenting a desired date as evidence of readiness.
- Place and provider basis: Facility, customer/tenant reference, authorized cabinet or cage identifiers, contracted provider product and whether the cabinets are already installed or remain a provider dependency. Share only the nonconfidential detail appropriate for the inquiry.
- Equipment and materials: Exact configuration and quantities, approved rack positions, required mounting-kit references, appointed equipment/material supplier and delivery responsibility. State what is expected, what is available and which evidence or parts remain outstanding; do not turn the brief into a purchasing commitment.
- Requested tenant tasks: Separate device mounting, customer-side cable routing/dressing/identification, agreed physical checks and documentation. Identify receiving/staging or remediation only if requested. Name the source drawing or schedule issue behind each line and identify exclusions.
- Provider interfaces: Relevant cross-connect/circuit request or order reference, nominated provider contact and the exact readiness or demarcation information still needed. Keep provider work outside the tenant installer's task list unless its actual assignment has been separately established.
- Access and work conditions: The customer/provider process, nominated approval owner, intended receiving/staging arrangement, permitted work conditions and any access/escort dependency. The inquiry itself grants no entitlement, booking, photography permission or authorization to work.
- Requested window: Proposed dates and time zone, applicable working-hour restrictions and the customer priority if more than one window is possible. Distinguish a request from a provider-confirmed window and from confirmed installer availability. No universal lead time or completion duration follows from a cabinet or device count.
- Decision and change owners: Who confirms the input package, who approves a scope or endpoint change, who can confirm provider readiness and who receives the installation record. Identify the decision still required and the source reference that will record it.
- Handoff and open dependencies: Required item/endpoint records, agreed check evidence, permitted photographs if any, output format and the treatment of incomplete provider services. State whether a limited physical handoff is useful before a separate service or technical package is accepted.
Once those inputs are reviewed, the parties can decide which tasks belong in the proposed package and what must be resolved before scheduling them. A complete-looking worksheet does not establish resource availability, facility permission, equipment compatibility or a guaranteed delivery date. If an input changes, identify the affected task and return the scope/window decision to its actual owner.
Read the existing work-authorization planning guidanceMake the unresolved scheduling decision visible_
Fictional brief EX-CO-B20 requests fit-out of two customer devices in one cabinet, C-EX10. For this example only, the provider record identifies the cabinet as installed; equipment list A2 and the proposed mounting-part references are available. The requested window W-A is not confirmed, the customer-side endpoint definition E2 is incomplete, and provider cross-connect request X-EX1 has no completion confirmation. These invented inputs describe a documentation problem, not an actual site, compatible configuration, work permission or available crew.
- W01 / tenant device fit-out: The proposed task concerns the two devices and their proposed positions in C-EX10. Equipment and part inputs can be reviewed, but site/window and installer-availability decisions remain open. The requested W-A must not be shown as a booked field visit.
- W02 / tenant cabling and endpoint record: The customer/design owner must resolve E2 and the applicable customer-side demarcation. Keep that input gap visible rather than inventing a termination or assuming every device can be connected. Any later installation/check scope depends on its actual release and prerequisites.
- P01 / provider cross-connect dependency: X-EX1 remains a provider-owned request with no completion confirmation in this brief. Record its next owner and required readiness evidence. Do not count it as a tenant installation task or accept it because the customer devices were mounted.
- D01 / document preparation: A source index and open-input list can be prepared from the supplied records if included in the agreed documentary scope. That limited preparation is distinguishable from performing W01/W02, confirming X-EX1 or releasing a site visit.
The brief contains four scope/dependency lines: two proposed tenant field-task lines still lacking a scheduling or input decision, one provider dependency and one limited documentation line. It does not contain four devices, four completed tasks or a duration estimate. Naming separate lines lets the customer ask for the exact missing decisions without resetting an unaffected record or hiding the provider boundary.
If the provider later confirms X-EX1, retain that reference and review which dependent decisions it actually resolves. It does not automatically confirm W-A, installer availability, E2 or technical acceptance. Likewise, a delivery delay should be linked to the affected task and proposed window, with the resulting decision recorded. The real parties must determine any revised scope, timing and commercial terms; this example creates no mobilization promise or operating procedure.
Coordinate the tenant drawing with the provider record_
A tenant rack layout and a facility plan describe different responsibilities. Start the coordination exchange with the actual space, cabinet and demarcation identifiers. Name the provider record governing the facility interface, the tenant rack/equipment layout and the connection or route information relevant to the requested work. Identify their authors, issue dates, revisions and intended uses; a recent file timestamp alone does not identify the governing issue.
Agree how the records refer to the same positions before comparing them: cabinet identifiers, orientation and the stated drawing origin, units or reference grid where applicable. Put an unconfirmed alignment into the questions list. A review overlay may reveal a disagreement, but it should remain a comparison view tied to both source issues rather than silently replacing either author's drawing.
Send each question to the owner of the affected interface. The facility addresses its space and provider-service records; the tenant's appointed design owner addresses tenant equipment, intended connections and dependent drawings. The installer identifies the information needed for its task. Keep the response, scope and source revision together, then have the document owners issue any required correction and identify the documents it affects. A response about one position does not settle an unrelated route or endpoint.
For a concrete operator example, Equinix's Private Cage Provisioning documentation describes aligning the cage spatial layout with the customer and needing design details to complete fit-out. This illustrates the facility/tenant information interface; it is not a universal provider rule, project approval or a claim that Leviathan designs or operates that facility.
Follow a limited layout response into the work package_
Fictional example EX-CO-D14 compares three coordination questions. The document identifiers, responses and states are invented to explain the records, not an actual facility, approved design or released installation. A provider response settles only the stated position question; it does not complete the other two lines.
| Question | Compared source issues | Required owner response | Follow-through and remaining state |
|---|---|---|---|
| D14-01: cabinet identity at the interface | Provider spatial plan F02 identifies C07; tenant rack plan T04 uses an older C06 reference for the same stated position. | The fictional nominated provider contact responds R01 against F02: the position reference is C07. The response says nothing about tenant connection details. | Tenant document owner issues T05 with that reference corrected and links R01/F02. Keep T04 as superseded history; connection and work-release decisions remain separate. |
| D14-02: tenant connection endpoint | Tenant connection schedule S03 identifies a port but the required provider demarcation record is absent from the review package. | Tenant lead requests the identified provider endpoint record and the tenant design owner's reconciliation. R01 is not an endpoint response. | Open. Record the missing source and affected connection line; do not fill the gap from a nearby symbol or the corrected cabinet name. |
| D14-03: route interface | Tenant route review V01 refers to F01, while F02 is the provider plan now listed for the position review. | Actual route owners must identify applicable sources and disposition; the position-only R01 response cannot be extended to the route. | Open. Retain V01's purpose and old source reference; a revised coordinated route package has not been supplied by this example. |
The next tenant package identifies the current document list, the limited response, the corrected issue and the unresolved lines. Separately confirm the actual task authorization, site conditions and work window. This example provides no route dimensions, structural or MEP approval, cabinet fit decision or permission to install.
Separate space, cabinet rating and the cage power allocation_
Empty rack units do not describe all the capacity available to an installation. In Equinix's published Private Cage model, the cage has a power draw cap in kVA, each cabinet has its own rating, and that cabinet rating also identifies the cooling resources needed. The sum of cabinet ratings must remain within the cage cap. Its Cabinet Equivalent, or CabE, includes associated aisle space, so a space allocation is not necessarily an installed cabinet count. These distinct limits explain why a provider may cap a rack even when another position or some cage allocation appears unused; they do not establish a universal limit for traditional colocation.
The provider must confirm the applicable product, site and allocations. Keep its stated units and source issue, the exact equipment configuration and the responsible facility review together. Adding circuit identifiers, renting more U positions or dividing an aggregate budget by the server count does not by itself establish the permitted cabinet load, cooling provision or equipment fit.
| Invented input | Arithmetic or comparison | Decision it cannot settle |
|---|---|---|
| 4 CabE of space; 2 listed cabinets | The space denominator is 4 CabE; the equipment-position list contains 2 cabinets. These are different quantities. | The space record does not prove two more cabinets can be placed or that the listed equipment fits. |
| Cage cap 20 kVA; two cabinet ratings of 6 kVA | 6 + 6 = 12 kVA of listed cabinet ratings; 12 is below 20. The unassigned difference is 8 kVA in this example. | That aggregate difference is not an approved increase to either cabinet rating or evidence of additional cooling. |
| A tenant worksheet proposes 8 kVA for cabinet C1 and 2 kVA for C2 | The proposed total is 10 kVA, below the cage cap, but C1's proposed 8 exceeds its listed rating of 6. | The worksheet cannot establish readiness from the total alone. Return the exact configuration and allocation question to the facility power/cooling owners; no relocation, circuit or loading action is prescribed. |
For a buyer comparing colocation options, request cabinet-specific and aggregate limits separately, together with the provider's configuration-specific disposition. A product name such as “private cage” or a nominal rack size is not a GPU-density commitment. Actual electrical capacity, cooling, structure, liquid interfaces and the selected system's requirements still need their competent owners' applicable review.
Make an A/B record traceable to the actual sources_
Document the intended supply association and the evidence returned, rather than recording only “A/B complete”. Equinix describes its redundant circuit pair as matched circuits supplied by diverse UPS systems. That illustrates why two labels alone do not establish the upstream arrangement. Provider circuit information and an installer's equipment-side record have different authors and coverage; keep both attributable.
A useful documentary line identifies the cabinet and device, the device's exact power-input designation, the governing input schedule and revision, provider circuit reference, PDU and outlet reference where supplied, intended association, evidence reference and observation status. Identify who supplied or observed each fact, the date and the unresolved discrepancy owner. Mark a missing record, a provider-reported state and an actually observed state distinctly. Any image or observation needs the actual agreed permission and scope; this worksheet grants neither.
| Record | Intended input in S2 | Returned document E1 | Bounded disposition |
|---|---|---|---|
| D1 input P1 | Cabinet C1; provider circuit CA; PDU PA; outlet OA17; source label A. | The same CA, PA and OA17 references are transcribed. E1 is a submitted record, not a field observation. | Document references match S2 for P1. No physical or electrical check result is supplied. |
| D1 input P2 | Cabinet C1; provider circuit CB; PDU PB; outlet OB17; source label B. | E1 instead repeats CA, PA and OA17 for P2. The device-side field condition has not been observed in this example. | Open documentary conflict. Ask the responsible record owner for the source and correction or the authorized verification needed; do not silently change the record or infer actual misconnection. |
| Provider basis for CA and CB | The brief requests the provider's applicable source-diversity information. | No such provider record accompanies E1. | Separate open provider dependency. Two named circuits and a corrected P2 transcription would not close it. |
There are two equipment-input lines and one provider-evidence question: one documentary match and two open issues, with zero physical check results. Real systems can have different power-input arrangements. The OEM and responsible facility parties must establish the applicable configuration, electrical limits and verification. This example specifies no connection, switching, isolation, loading or failover procedure, and it does not certify redundant power.
Distinguish cloud availability from physical workmanship_
Buying a GPU-backed cloud instance and installing customer-owned hardware create different buyer evidence. AWS identifies its P5 family as GPU-based EC2 instances. Its separate Amazon Compute SLA, last updated May 25, 2022 on the page reviewed, defines region-level and individual-instance availability measures over a monthly billing cycle, with a service-credit process. That is a named service example, not a promise of GPU application performance, acceptance of a tenant's physical installation, or the terms of another cloud provider.
| Buyer question | Cloud availability record | Physical workmanship record |
|---|---|---|
| What object and period are being reviewed? | Named service, account/resource identity, applicable SLA version, deployment basis and measurement period. The Amazon example distinguishes regional and individual-instance scopes. | Named work package, equipment and connection identities, applicable drawing or schedule issues, agreed physical criteria, and the dated coverage of each observation. |
| What evidence answers the question? | The applicable service definition and incident evidence. The Amazon claim process requests resource identities, incident timing and corroborating logs or other data. | Agreed installation/check records, attributable observations, deviations, correction evidence and unresolved items reviewed by the nominated project owner. |
| Who decides the response? | The cloud service parties follow their actual terms and claim process; a physical installer does not decide the cloud provider's service-credit outcome. | The actual work-package and acceptance parties address the stated physical criteria and exceptions; this does not decide cloud availability or include software commissioning. |
Fictional comparison EX-SL108 contains two independent questions. C01 records an alleged loss of cloud-instance connectivity during a stated month, for review under the applicable cloud terms. W01 records a missing equipment label in a separate customer-owned installation package, for review against that package's agreed criterion. A cloud service credit would not supply W01's missing physical evidence; correcting the label would not establish C01's monthly availability measure. The example makes no claim about either question's actual cause, eligibility, remedy or acceptance. Leviathan's agreed physical installation scope remains separate from cloud service provision and ongoing operations.
Review the supplied system before calling the facility ready_
A colocation readiness questionnaire must join two descriptions: the complete system being delivered and the provider's accepted arrangement for it. An accelerator generation does not identify the shipping assembly, mounting parts, service envelope, cooling interfaces or installation party. Start with the exact manufacturer, model, configuration and applicable document issue, then ask the facility to answer against that same system. Keep physical installation, OEM startup and the customer's operational acceptance as separate releases.
For any of the examples below, resolve the delivery assembly and permitted movement route; installed and service-access geometry; supplied mounting arrangement; cabinet-specific power and cooling interfaces; permitted customer-side connections; and the parties responsible for installation, startup and acceptance. Compare each answer with the actual system requirements, not just a rack-unit total or a family brochure. A missing facility response is an open prerequisite. A field observation is evidence for its stated condition, not proof of every requirement.
| System context | Concrete distinction | Question for the provider and system owner |
|---|---|---|
| Older Hopper equipment | The DGX H100/H200 guide calls for site information to the installation partner and identifies NVIDIA partner-network personnel or NVIDIA field service engineers as installers. Its support registration is a separate purchase-entitlement process. Those statements concern that named DGX system, not every H100 board or OEM server. | Which exact system and installed components are being received, which current requirements apply, and who resolves its condition, support entitlement and installation responsibility? A previous installation or older product label does not establish its present condition, transfer support rights or make the new facility suitable. |
| DGX B200 | NVIDIA lists a 10U complete system, alongside separate mechanical, power and environmental requirements. Its installation section separately identifies the installation-partner condition. | Are the exact cabinet positions, mounting and service envelope, delivery arrangement and facility interfaces accepted for the supplied system, and is its actual installation party established? Ten allocated U does not prove those other conditions or authorize Leviathan as that OEM installer. |
| Rubin rack-scale proposal | NVIDIA presents Vera Rubin NVL72 as a rack-scale system. A platform description is not the supplier's issued delivery drawing, connection schedule or facility installation package. | Which complete supplied assembly and governing issue does the facility evaluate? Resolve external dimensions and service space, delivery/position interfaces, applicable power and cooling boundary, and exact network demarcations before treating a nominal rack reservation as fit. Do not derive installation quantities or site requirements from a projected performance comparison. |
| AMD Instinct complete server | The named Supermicro AS-4126GS-NMR-LCC is described as a 4U MI355X liquid-cooled system; the product page identifies direct-to-chip cold plates and an onsite-service requirement for liquid cooling. That does not describe every Instinct server or assign liquid work to an IT installer. | Is this the ordered model and cooling configuration, and which facility and qualified vendor parties own the actual interfaces and service arrangement? Keep the body, mounting and connected service envelope distinct. An accepted 4U position alone cannot answer the cooling or access questions. |
| Non-NVIDIA vendor system | Cerebras describes CS-4 through Compute, Power and I/O elements, including direct liquid cooling in its compute assembly. A generic server name can hide supplier-specific assembly and service boundaries. | Which supplier personnel, equipment, tools and work areas require access, for which tasks and dates? Have the customer, facility and vendor separately resolved visitor approval, delivery/staging, maintenance space, liquid-side responsibility and any permitted remote support? Vendor support eligibility does not grant facility entry or access to customer data. |
Use these as configuration-specific readiness questions. The responsible parties must establish actual requirements, support and permissions; no performance, availability, operating limit, installation procedure or warranty determination is adopted here.
Use a checklist with a release order and an exception state_
A useful installation checklist tells the next team what can proceed, what input governs it and which missing condition stops a dependent task. Complete each applicable check through its assigned owner. Use separate states for not supplied, supplied but unreviewed, resolved for the stated scope, and completed with attributable evidence. A document being present is not the same state as the work being complete.
| Checkpoint | Review before the dependent task | Return or stop condition |
|---|---|---|
| 1. Establish the job boundary | Identify the customer's authorized space, exact devices and positions, task lines, appointed performers, applicable input issues and receiving party. Separate tenant tasks from provider work. | An unresolved cabinet assignment, task performer or provider prerequisite remains open before that work is released. |
| 2. Resolve entry and delivery | Obtain actual work-window/access decisions; identify the accepted receiving/staging and movement arrangements, equipment population and supplied mounting/cable materials. Route a shortage or incompatible supplied reference to its owner. | Return the received-versus-expected and exception record. A delivery booking does not establish a usable route, handling method or permission to enter. |
| 3. Release the equipment task | Resolve exact system, approved positions, mounting/support and service-access inputs with their responsible parties. The assigned installer follows the applicable authorized method; this page does not replace it. | Record each agreed installed item and any unavailable or changed prerequisite. Do not replace a missing compatibility decision with a matching rack-unit count. |
| 4. Release customer-side IT connections | Use the issued connection/label schedule and permitted pathways. Confirm which endpoints are available and which circuits or cross-connects remain provider dependencies. | Return identified customer-side endpoints and open connections. Provider readiness, electrical work and network configuration remain separate responsibilities. |
| 5. Check and reconcile | Perform only the agreed permitted checks against the applicable criteria. Relate each result, exception and correction to its item and source issue; account for the complete agreed population. | A limited observation remains limited. Missing checks, conflicts and excluded items must be visible rather than represented by an overall complete label. |
| 6. Return the package and its boundaries | Give the nominated recipient the agreed item/endpoint records, check evidence, deviations, open dependencies and required owner decisions. | Physical IT handoff does not release OEM startup, facility services, software commissioning or operational acceptance. Record who owns each remaining decision. |
Fictional EX-CO157 lists two DGX B200 systems and a proposed block of 20U. Two times the named system's 10U allocation equals 20U; that is one dimensional subtotal, not a fit result. The invented provider record resolves the cabinet identity, but the actual mounting arrangement is absent and the requested vendor visit is not approved. The checklist therefore retains two separate open prerequisites. It does not authorize mounting because the arithmetic matches, nor turn a proposed visit into an available installation crew.
Compare the capacity arrangement and the construction boundary separately_
Colocation describes an arrangement for using a provider's space and services. Prefabrication describes how infrastructure is produced and delivered. They are not opposite ownership categories: a colocation facility can itself use prefabricated infrastructure. For a buyer comparing overflow space with a modular expansion project, identify what each option actually includes before comparing cost, timing or rack counts.
Schneider Electric's product descriptions illustrate several different delivery objects: factory-assembled all-in-one infrastructure, an IT pod transported partially assembled, and factory-built IT modules joined on site into a data hall. Those distinctions explain why a module proposal still needs a defined receiving site, external interfaces and responsible parties. They establish no universal deployment duration, installed capacity or savings.
| Buyer trade-off | Existing colocation overflow | Modular expansion proposal |
|---|---|---|
| Object being obtained | Defined positions/space and contracted provider services, with tenant equipment and installation boundaries. | A specified module or assembled facility scope, with explicit included systems, site work and external interfaces. A module count is not a cabinet-space allocation. |
| Readiness and expansion limit | Provider availability, cabinet-specific and aggregate limits, permitted system configuration, cross-connects and actual access/window decisions. | Site rights, applicable approvals, delivery/placement, external power/cooling/network boundaries, commissioning and subsequent expansion interfaces. Factory testing does not establish the finished site. |
| Operating responsibility and continuity | Separate provider facility duties from customer IT operations, support access and movement between the original and overflow locations. | Appoint actual facility operation, maintenance, vendor and IT responsibilities for the completed installation. Product delivery does not by itself supply an operating team or service agreement. |
| Commercial comparison | Identify setup, recurring space/services, connectivity, installation, support and eventual exit/move scope for the chosen period. | Identify module supply, excluded site works/interfaces, transport, installation, commissioning, recurring operations and future changes for the same period and service scope. |
In fictional EX-EX158, both proposals mention capacity for the same customer equipment. C offers two provider cabinets but leaves the required cooling configuration unconfirmed. M offers one prefabricated module but excludes the external utility and network interfaces. Neither proposal is ready merely because its headline says capacity available. Return C's configuration question to the provider and M's excluded interfaces to the site and module owners. Resolve their actual cost, timing and responsibility effects before comparing the offers; two cabinets and one module are not interchangeable quantities. Leviathan's offered work remains the agreed physical IT package, not module construction or facility operation.
Translate a sector label into the actual access boundary_
An airline, hospital or government customer does not supply one universal contractor-access checklist. Determine the actual location, regulated activity or selected control framework, then let the customer and facility identify the applicable requirements. Separate permission for the person to enter, permission to perform the named task, and permission to view, record or remotely access information. Each can have a different owner and boundary.
| Context to establish | Why its scope matters | Question to the actual security/customer owner |
|---|---|---|
| Airport-controlled area | 49 CFR1542.205 addresses the airport operator's SIDA measures, including checks and training before unescorted access. 1542.207 distinguishes access to an entire secured area from a portion. An airline-owned server in an unrelated colocation facility is not automatically in either airport area. | Which actual area and route does the task require, is escorted or unescorted access proposed, and which operator process must be completed? Ask about receiving, tools, photography and task restrictions separately; do not infer authorization from an airline purchase order. |
| Facility housing electronic protected health information | HHS's Security Rule summary describes limiting physical access while allowing properly authorized access, and separate receipt/removal/movement controls for hardware and media containing ePHI. It does not appoint this installer or establish that every hospital equipment task exposes such information. | Which systems or information can the task encounter, who authorizes the role and supervision, and what equipment/media, image and information-handling rules apply? Keep actual patient data and credentials out of the ordinary installation brief. |
| Government/customer-selected security controls | NIST SP800-53 Rev5 PE-2 and PE-3 distinguish authorizing individuals from enforcing access; the catalog also separates facility access from system access and visitor control. Its organization-defined parameters are not a universal badge, clearance or escort rule for every government project. | Which actual controls and contractual instructions were selected, for which facility/system boundary? Identify the sponsor, permitted people/tasks/areas/time, visitor or escort conditions and approved record channel. Do not interpret a public control catalog as a project authorization. |
Fictional EX-AC158 has three independent requests: entry to the authorized equipment room, permission for the specified mounting task, and permission to photograph the result. A stipulated escorted-entry approval settles only the first. The task decision and image decision remain open; an approved visitor is not automatically an approved installer or data recipient. Use the actual secure process for personnel and sensitive details. No credential, exemption, clearance or access-control bypass is supplied by this example.
Turn the agreed brief into a bounded statement of work_
The inquiry fields above gather inputs. A statement of work organizes the resulting agreement: which tasks are included, what each depends on, what will be returned and how the parties review it. The following fictional specimen supplies that structure, not legal terms, an appointment or a ready-to-sign contract. Actual parties must resolve commercial and legal provisions and authorize their own scope.
- 1 / Identified package and governing inputs. EX-SOW158 concerns two stipulated customer devices D1 and D2 in already installed cabinet C1. List the actual customer/provider references, issued elevation E3 and connection schedule S4. This example assumes neither compatibility nor access permission; name their prerequisite decisions and the person able to confirm them.
- 2 / Included task lines. L1 identifies the two device-placement tasks at their stated positions under the applicable authorized method. L2 identifies the agreed customer-side IT connections and labels by S4 entries. L3 identifies the agreed checks and installation-record return. Specify actual material supply and any agreed receiving/staging responsibility; do not silently add cabinet installation, freight, offload or heavy handling.
- 3 / Prerequisites and interfaces. The customer provides the applicable input package and equipment/material decisions. The facility owns its access, permitted window and provider-interface decisions. The assigned system/technical parties own applicable mounting, electrical, liquid, startup and test requirements. Identify unresolved inputs, their owners and the tasks they prevent; an expected completion date is not evidence that a dependency is ready.
- 4 / Deliverables and review basis. State the required item and endpoint records, agreed check criteria/evidence, deviations and open-dependency list, permitted images if any, delivery format and nominated recipient. Link the completed population to L1/L2/L3. Specify how the actual parties review exceptions and corrections. Receipt of a report is not blanket technical or operational acceptance.
- 5 / Exclusions and separate acceptances. Keep the provider cross-connect order and provider-owned work outside L2; identify the customer-side demarcation instead. Explicitly separate facility electrical/mechanical/liquid trades, OEM startup, software/network configuration and service operation. A physical IT completion return does not certify those packages.
- 6 / Change and closure. Name the actual scope/change decision owners and require an affected line, changed input and recorded disposition. For example, replacing D2 with a different supplied model returns its position, materials, interfaces and dependent tasks for review; it does not silently enlarge L1. Keep superseded inputs and the actual revised scope identifiable at handoff.
The specimen contains two device identities, three grouped tenant task lines and a separate provider dependency. Those are different populations. It does not state a price, duration, remedy, liability allocation or legal acceptance mechanism. Use the structure to make a proposed agreement reviewable, then have the authorized parties settle its real terms and decisions.
Obtain facility authorization first_
Before work starts, confirm the work package and permissions, customer inputs and the nominated approval owner. An active customer right to use the cabinets/cage and approval for the proposed work. Facility work rules, contacts, access/escort arrangements and permitted work windows. Confirmed equipment delivery/staging arrangements and an authorized handling method. Approved rack locations, customer-side connection instructions and identified provider dependencies.
Verification covers the agreed checks and records. Verification is tied to the approved work package and available endpoints. The scope can include visual installation checks, cable-ID and label verification, agreed physical-connectivity checks and defect records. A facility-provided cross-connect or circuit is not treated as accepted merely because customer equipment has been installed.
Scope boundary: Colocation space, hosting, transit, connectivity subscriptions and facility cross-connect provision; Unagreed freight, offload or heavy handling; Facility electrical, mechanical or structural trades and all liquid-side installation or commissioning; A promise that provider services, network configuration or software commissioning are complete when the physical work ends.
Project coverage: We support data center projects across the United States, subject to project scope, site requirements and team availability.
Records your remote team can use_
Handoff owner: The customer operations lead receives the installation record and reviews open provider dependencies with the nominated facility contact.
Deliverable boundary: Agree endpoint, label and status records for customer-side work, permitted photographs and the treatment of open provider dependencies. Provider reports remain identified by their source; the installation record does not certify provider-owned services.
Fictional comparison EX-CO-20: Two inquiries both say “deploy two racks,” but describe different deliveries. These are illustrative briefs, not actual customer orders, installed cabinets or an approved design.
Brief A — equipment for existing cabinets: The fictional provider records identify cabinets C01 and C02 as already installed. The customer supplies servers and switches; its request names the equipment positions and customer-side connections. The proposed tenant package concerns device fit-out and physical IT cabling. Cabinet supply and installation are not requested again. Equipment compatibility, permitted work and the actual installation package still require review.
Brief B — customer-supplied cabinets for a cage: The equipment list includes two assembled custom cabinets, but confirmation of the provider-accepted cabinet arrangement and cabinet-installation work has not been supplied. Under the described Equinix product arrangements, cabinet ownership alone does not assign cabinet installation to a tenant installer. Resolve that provider interface before agreeing tenant tasks that depend on the cabinets being installed. A cage reservation alone would not establish the missing approval or completion.
Compare the remaining work: Ask which cabinets the provider will supply or accept and install, then identify the devices and customer-side connections left for the tenant package. Keep the cabinet identifiers and current provider instructions with the inquiry. The same shorthand rack count can conceal a missing provider task or a duplicate installation request; it does not define the scope to book.
Discuss the colocation fit-out_
Share the facility name, authorized space, hardware list and intended work window. We will review the provider interfaces and access requirements before proposing the customer-side installation scope. Tell us about your project, and our team will follow up to discuss the scope, requirements and availability.
Discuss a Project →Colocation Installation FAQ_
Do you provide hosting or colocation space?
No. You contract with the colocation provider for space and facility services. Leviathan's scope is the agreed physical installation of your infrastructure inside that authorized space.
Can you order or install the facility cross-connect?
The facility provider controls its cross-connect process. We can coordinate the agreed customer-side interface and record endpoints, while orders and provider-side work remain with the customer and facility unless expressly arranged otherwise.
Can installation proceed before the provider circuit is ready?
Some physical tasks may be possible, but dependent work and checks must be identified as incomplete. The installation plan records what can proceed and what requires the provider's readiness confirmation.
Does this replace the facility's remote-hands service?
It is a separately scoped installation project. Facility access and any required provider assistance must be approved; ongoing remote hands or operations support are not implied by an installation engagement.
How are customer and facility responsibilities documented?
The work package separates customer-side installation from provider-owned cross-connects, circuits and other facility services. Handoff records identify installed endpoints and open provider dependencies; they do not accept unavailable facility services.
Does owning the cabinet determine who installs it in colocation?
No. Confirm the actual provider product, accepted cabinet and installation responsibility. For example, Equinix’s Private Cages documentation describes customer-procured or Equinix accessory cabinets but assigns cabinet installation to Equinix in either case. That example does not establish your site’s approval or transfer provider work to Leviathan.
Is cabinet installation the same scope as installing equipment in a cabinet?
They are different tasks. State whether cabinets are already installed or require provider acceptance and installation, then identify the tenant devices and physical IT connections to be installed inside them. Agree the actual parties and prerequisites for each package; a request to deploy racks does not resolve those distinctions.
What should a colocation installation scheduling brief include?
Identify the authorized space/provider arrangement, exact equipment and appointed supply/delivery parties, requested tenant tasks, source revisions, provider interfaces, access/work conditions, proposed dates and time zone, decision owners and required handoff. Mark unknowns and their owners. The brief supports a scope/window decision; it does not reserve resources or grant site permission.
Does a requested installation date reserve a work window?
No. Distinguish the customer's requested dates, the provider's permitted or confirmed window and the installer's actual agreed availability. Scope, prerequisites and resources must be reviewed for the engagement. This service page supplies no universal lead time or completion duration based on a cabinet or device count.
How do we separate tenant-owned equipment from provider-controlled work?
For each line, record the item/location, task, proposed performer, prerequisite and confirming owner, applicable provider/customer reference and handoff record. Ownership is one input; it does not by itself assign cabinet installation, provider cross-connect work, facility access or technical acceptance to the tenant installer.
What should change when a delivery or provider dependency slips?
Identify the affected task, source input and proposed window, then ask the actual owner for the revised disposition. Preserve unaffected records and distinguish permitted documentary preparation from unreleased field work. A provider readiness update does not automatically confirm installer availability, an unresolved endpoint or the complete work package.
Which drawings should the tenant and facility coordinate before installation?
Identify the provider spatial layout and demarcation records, the tenant rack and equipment layout, and the connection or route information needed for the agreed task. Bind each to its actual source, issue, purpose and decision owner. Ask the facility to resolve its own space and service interfaces, and the tenant design owner to resolve the tenant package. An overlaid review view helps compare them but does not issue either source or authorize work.
Does a provider layout comment release the tenant installation package?
Only for the exact scope the actual authorized response covers. Keep the response with its drawing issue and affected items, update the dependent tenant documents through their owners, and retain any open route, endpoint, access or readiness questions. A comment on a cabinet position does not approve every connection, the tenant design, a work window or technical acceptance.
How does installation scope differ between a shared rack and a private cage?
Confirm the actual space product first: assigned U positions among other occupants, a dedicated cabinet, or cabinets inside a private cage. Identify the permitted equipment positions, mounting inputs, provider-controlled interfaces and actual task performer. A cage adds spatial and inter-cabinet interfaces; it does not automatically assign cabinet construction, power work or route approval to the tenant installer. Named operator examples illustrate different products and rules, not universal GPU fit or access permission.
Why can a cabinet still be constrained when the cage has unused power allocation?
The aggregate allocation, each cabinet's applicable rating and cooling provision, and the space allocation are different inputs. In the named Equinix Private Cage model, cabinet ratings must fit within the cage cap, but unused aggregate allocation does not increase a cabinet's rating. EX-DN108 shows a proposed 8 kVA in a cabinet listed at 6 kVA even though the proposed cage total is below its fictional cap. This is documentary arithmetic, not a measured load, capacity calculation or site approval.
What should the installer document about A and B feeds?
Within the agreed documentary scope, link the exact device-input designation to the intended provider circuit, PDU and outlet references, governing source issue, evidence author/date and observed or reported status. Preserve missing provider records and conflicting associations explicitly. EX-AB108 has two equipment-input lines plus one separate provider-diversity question; a matching transcription is not a physical check. The records do not authorize electrical work, prove upstream diversity or specify connection, switching or failover methods.
Does a cloud GPU SLA establish acceptance of a physical installation?
No such conclusion follows from the SLA label. Identify the actual service, terms, measurement basis, evidence and responsible parties. The named Amazon Compute example addresses EC2 availability and a service-credit process; a physical work package addresses agreed equipment, connections, workmanship criteria and exceptions. Neither record substitutes for the other's evidence. EX-SL108 keeps a cloud-connectivity allegation separate from a missing physical label, without deciding entitlement, cause, remedy or acceptance.
Related Resources
Plan Your Customer-Side Installation_
Tell us about your project, and our team will follow up to discuss the scope, requirements and availability.
Discuss a ProjectEmail Project Scope