Hardware co-location methodology

The co-location methodology is a planned structured approach for scoring and ranking physical co-location opportunities for customer hardware deployments — jurisdiction, network transit, infrastructure fit, and cost, in that priority order. No automated scoring pipeline exists yet; the methodology below states the intended design, not a shipped system. (This is a distinct concept from the platform's real-estate co-location scoring, used for commercial-property site selection — a different domain with its own, separately-implemented methodology.)

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?

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 CSA National Policy 51-201 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.

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.

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.

Integration with development regions

Co-location scoring operates within the development-regions taxonomy. A development region defines the geographic and jurisdictional envelope within which co-location candidates are considered. The methodology does not search globally; it searches within the region declared by the deployment requirement, then scores candidates within that region against the four dimensions above.

This scoped approach reflects the platform's deployment philosophy: sovereignty and regulatory compliance are architectural constraints, not post-selection considerations. Candidate sets are bounded before scoring begins.

Status

No facility-scoring pipeline or structured facility-profile data store exists today. The dimensions above describe the intended design; a candidate list is currently assembled and scored by an operator manually, not generated by an automated pipeline.

See also

• Development regions — geographic and jurisdictional zone taxonomy
• Three-ring architecture — platform data and compute substrate model
• Compounding substrate — substrate mechanism that accumulates market intelligence over time
• Leapfrog 2030 architecture — strategic architecture within which co-location decisions are made