Co-location methodology

@@ -15,21 +15,21 @@ paired_with: co-location-methodology.es.md
cites: []
---

The co-location methodology is the structured approach PointSav uses to score and rank physical co-location opportunities for customer deployments. It combines market data, regulatory context, and infrastructure characteristics drawn from the platform's intelligence pipeline and [[compounding-substrate]] to produce a ranked list of candidate sites for a given deployment requirement.
The co-location methodology is the structured approach [[pointsav-overview|PointSav]] uses to score and rank physical co-location opportunities for customer deployments. It combines market data, regulatory context, and infrastructure characteristics drawn from the platform's intelligence pipeline and [[compounding-substrate]] to produce a ranked list of candidate sites for a given deployment requirement.

## What co-location means in this context

Co-location, in the PointSav deployment model, refers to placing customer-owned hardware in a third-party data centre facility rather than on a customer's own premises. The customer retains ownership of the hardware, the software stack, and the data; the facility provides power, cooling, physical security, and network transit.

The methodology addresses the site-selection step: given a deployment requirement — a ToteboxOS node, a MediaKit-class workload, or a GPU-capable inference tier — which facilities across which [[development-regions]] best satisfy the combination of latency, jurisdiction, compliance posture, and cost constraints?
The methodology addresses the site-selection step: given a deployment requirement — a [[totebox-os|ToteboxOS]] node, a [[mediakit-os|MediaKit-class]] workload, or a GPU-capable inference tier — which facilities across which [[development-regions]] best satisfy the combination of latency, jurisdiction, compliance posture, and cost constraints?

## Scoring dimensions

**Jurisdictional fit.** Each co-location candidate is evaluated against the regulatory context of the customer's operating region. For Canadian customers under NI 51-102 or OSC SN 51-721 disclosure obligations, data residency within Canada is a baseline requirement. The methodology encodes jurisdiction-first scoring: a facility outside the required jurisdiction is excluded before other dimensions are evaluated.

**Network transit characteristics.** Latency to the customer's primary users and to the PointSav workspace endpoint is measured at candidate selection time. Facilities are scored on round-trip time, transit provider diversity, and the availability of a WireGuard-compatible BGP peering path to the customer's existing nodes.
**Network transit characteristics.** Latency to the customer's primary users and to the [[pointsav-overview|PointSav]] workspace endpoint is measured at candidate selection time. Facilities are scored on round-trip time, transit provider diversity, and the availability of a WireGuard-compatible BGP peering path to the customer's existing nodes.

**Infrastructure compatibility.** The physical power and cooling envelope of the facility is matched against the node class being placed. ToteboxOS nodes require modest, always-on power profiles; GPU-capable inference tiers require higher burst power and active cooling. Facilities that cannot accommodate the target node class are excluded.
**Infrastructure compatibility.** The physical power and cooling envelope of the facility is matched against the node class being placed. [[totebox-os|ToteboxOS]] nodes require modest, always-on power profiles; GPU-capable inference tiers require higher burst power and active cooling. Facilities that cannot accommodate the target node class are excluded.

**Cost structure.** Monthly colocation fees, cross-connect charges, and bandwidth commitments are normalized to a total cost of ownership over a 36-month horizon. The methodology does not optimize cost in isolation; it minimizes cost within the constraint set defined by the preceding dimensions.