Summary

  • Pegboard Hosting Inc. has a visible, active network identity: ARIN RDAP lists AS62752 and the directly allocated 198.51.75.0/24 block under Pegboard Hosting Inc., while RIPEstat marked AS62752 announced on 2026-07-14.
  • The active routed footprint is narrow. RIPEstat's current routing view showed one IPv4 prefix, 256 IPv4 addresses, no visible IPv6 announcement in the sampled global table and one observed neighbour, AS20473, The Constant Company.
  • Routing hygiene is stronger than the operating disclosure. RIPEstat RPKI validation returned valid status for AS62752 and 198.51.75.0/24, but public records do not disclose facility, power, spare hardware, support coverage or customer recovery terms.
  • PeeringDB lists Pegboard Hosting as an Enterprise network with global scope, open general peering policy, one IPv4 prefix and zero listed facilities or exchange LANs. PCH's MBIX data includes AS62752 in member address records but shows peer false and prefix count zero there, so it is a locality clue, not proof of active exchange capacity.
  • The evidence grade is Weak. Pegboard has enough public routing evidence to be real, but not enough operating evidence to treat it as dependable customer-facing hosted capacity without direct confirmation from the operator.

A tiny routed edge is still infrastructure

Pegboard Hosting Inc. matters because small networks can sit in critical places. A single hosted server can carry a billing system, a community service, a monitoring endpoint, a mail relay, a private application, an edge node, a backup target or a control panel for a much larger business process. Small infrastructure companies often do not look like hyperscale providers; they look like a registration record, a route, a name in a peering database, a personal domain and a few old conference or community traces. That does not make them irrelevant. It makes the diligence job more exacting.

The public starting point is clear enough. ARIN's autonomous-system record at https://rdap.arin.net/registry/autnum/62752 lists AS62752, status active, name PH-285-62752, and registrant Pegboard Hosting Inc. ARIN's organization record at https://rdap.arin.net/registry/entity/PH-285 lists Pegboard Hosting Inc. with Box 62, Argyle, Manitoba, Canada, and shows the related 198.51.75.0/24 IPv4 network. ARIN's network record at https://rdap.arin.net/registry/ip/198.51.75.0 names the block PEGBOARD-HOSTING-01, identifies it as a direct allocation, and shows it active.

Those records put Pegboard in a different category from a company name that appears only in a directory. It has an assigned ASN and directly allocated IPv4 space. RIPEstat's AS overview at https://stat.ripe.net/data/as-overview/data.json?resource=AS62752 labeled the holder PH-285-62752 - Pegboard Hosting Inc. and marked the AS announced in the July 14, 2026 query window. RIPEstat's prefix overview at https://stat.ripe.net/data/prefix-overview/data.json?resource=198.51.75.0%2F24 showed 198.51.75.0/24 announced by AS62752. In other words, there is a live route tied to the name.

But the same evidence also creates the article's central caution. The public route does not show a hosting product. The registry record does not show a rack. The personal website associated with the PeeringDB organization, https://robert.keizer.ca/, is a minimal personal page with contact information and a LinkedIn link; it is not a current Pegboard service catalogue. A 2018 conference speaker page at https://thelongcon.ca/2018/speakers/ describes Robert Keizer as a software developer who had founded a local cloud provider, which helps explain the small-provider context. It does not prove current capacity, customer contracts or recovery controls in 2026.

That is why Pegboard should be analyzed as a thin-footprint infrastructure dependency. The right question is not whether the public record proves a large hosting company. It plainly does not. The better question is what a customer, partner, directory analyst or risk owner should ask once a real but narrow routed edge is visible.

What the public identity proves

The strongest company-specific evidence is the registry chain. ARIN shows Pegboard Hosting Inc. as the registrant for AS62752 and for 198.51.75.0/24. The AS registration event in the ARIN RDAP record is dated 2017-08-28. The Pegboard entity record was registered in 2016 and last changed in 2021. The IPv4 network record was also registered in 2017 and last changed in 2024. The contact entity linked to the records is marked validated and gives an Argyle, Manitoba contact point. None of those details should be stretched into an operational claim, but they are solid identity evidence.

RIPEstat strengthens the live-network side. Its routing status endpoint at https://stat.ripe.net/data/routing-status/data.json?resource=AS62752 showed the last-seen route as 198.51.75.0/24 originated by AS62752 on 2026-07-14. It reported 325 of 326 RIS IPv4 peers seeing the AS in that sample, one current IPv4 prefix, 256 IPv4 addresses, zero current IPv6 prefixes and one observed neighbour. Its announced-prefixes endpoint at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS62752 listed only 198.51.75.0/24 during the 2026-06-30 to 2026-07-14 window.

That gives the buyer a small but useful map. There is one visible IPv4 block. The block is announced now. The holder and route origin match the Pegboard name in the routing-analysis view. The same AS is not advertising a wide set of regions, customers or product-specific prefixes in the public table. That modest scale may be perfectly intentional. It may support a small number of services, a private hosting footprint, a lab environment, a community-scale customer base or a legacy edge. The public record does not decide which one.

The public identity also does not prove that all Pegboard-linked services, if any are active, ride on the visible /24. A hosting company can use its own addresses for authoritative systems and third-party platforms for customer workloads. It can announce its own space from rented infrastructure. It can colocate a router while servers live somewhere else. It can use an upstream hosting network for some functions and its own ASN for others. A route table proves reachability of the prefix, not the service role of every IP inside it.

The cautious reading is therefore simple: Pegboard is a real network registrant with an active route. Anything beyond that has to be verified directly, including product status, service terms, customer use, physical location, operational staffing and continuity controls.

A one-prefix footprint changes the risk model

Many hosting diligence exercises start by looking for footprint breadth. How many prefixes are announced? Are both IPv4 and IPv6 visible? Are there multiple upstreams? Are there exchange ports? Are there city-specific facilities? Are route objects and RPKI records consistent? Pegboard's public answer is unusually compact. RIPEstat shows one current IPv4 prefix and no current IPv6 announcement. PeeringDB's network API at https://www.peeringdb.com/api/net/6046 also lists one IPv4 prefix and zero IPv6 prefixes for ASN 62752. IP Guide's AS page at https://ip.guide/AS62752 likewise summarizes one IPv4 route and no IPv6 routes.

A one-prefix footprint is not automatically bad. A small provider can run a tidy environment with one well-managed /24, good backups, strict change control and sensible customer boundaries. A sprawling provider can still fail because every visible route depends on one vendor, one building or one support team. The problem is not size by itself. The problem is that size removes inference. With only one visible routed block, an outside analyst cannot infer geographic redundancy, service segmentation, spare address capacity or customer isolation from public routing data.

The practical question is installed versus usable capacity. A /24 contains 256 IPv4 addresses before network design, reserves and service segmentation. Public routing data does not show how many addresses are assigned to production services, management interfaces, customer virtual machines, mail systems, DNS, monitoring, NAT pools, load balancers or idle reserve. It does not show whether the block is routed from one data centre, multiple sites or a virtual-router arrangement behind one upstream. It does not show whether customer services are single-homed inside the block or backed by another provider.

It does not show whether the same hardware supports routing and compute.

For a customer, that uncertainty matters more than the raw address count. If the /24 supports a private application with nightly backups, the resilience problem may be manageable. If it supports a customer portal, mail, DNS and production virtual machines together, a routing or rack event could impair many functions at once. If the visible block is only a management edge while workloads sit elsewhere, the primary risk moves to the undisclosed provider. The public record cannot choose among those patterns.

This is why Pegboard's one-prefix footprint should be treated as a watchpoint. It is enough to support a narrow service. It is not enough to prove a resilient hosting platform.

Transit visibility points to one current public neighbour

RIPEstat's ASN-neighbours endpoint at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS62752 showed one observed neighbour on 2026-07-14: AS20473. RIPEstat's overview for that neighbour at https://stat.ripe.net/data/as-overview/data.json?resource=AS20473 identifies it as AS-VULTR - The Constant Company, LLC. RIPEstat's routing-consistency endpoint at https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS62752 showed the 198.51.75.0/24 prefix in BGP and whois, with imports and exports visible through AS20473 in BGP but not in whois.

This is strong evidence for the public routing shape, but it is not a carrier contract. An observed neighbour is a collector view of BGP adjacency or AS-path relationship. It does not say whether Pegboard buys transit, uses a virtual server provider, peers through a route server, keeps a backup link offline, or announces from infrastructure operated by another party. It also does not say where the physical cross-connect is located, whether the route shares power and switch domains with the servers, or whether failover capacity exists.

The single-neighbour public view matters because it constrains the buyer's recovery questions. If AS20473 is the only currently visible public path, then an issue in that upstream relationship, the interconnect, the customer account, the host location or the routing session could affect reachability to the whole visible /24. There may be private backup arrangements that do not appear in the public sample. There may be intentionally hidden or on-demand recovery paths.

But those would need direct proof: a second upstream, a tested failover route, a written escalation path, a contact who can change routing under pressure and an explanation of what happens to hosted workloads if the main path is withdrawn.

The BGP-update record at https://stat.ripe.net/data/bgp-update-activity/data.json?resource=AS62752 also deserves cautious handling. The July 7 to July 14, 2026 sample showed repeated announcement counts in six-hour periods, with no withdrawal values returned in the view. That does not by itself indicate instability. Small ASNs can show update activity for normal reasons, including route refreshes, upstream policy changes or collector behavior. It does mean that customers should monitor the specific prefix and not rely only on a brand claim.

Transit is the part of hosted capacity that disappears from the invoice until something breaks. Pegboard's public route is reachable. The public route does not yet prove path diversity.

PeeringDB narrows the commercial posture but leaves the facility blank

PeeringDB is often useful because operators use it to declare peering policy, facilities, exchanges and traffic notes. Pegboard's profile at https://www.peeringdb.com/net/6046 and the API response at https://www.peeringdb.com/api/net/6046 identify Pegboard Hosting, ASN 62752, website https://robert.keizer.ca/, information type Enterprise, one IPv4 prefix, zero IPv6 prefixes, global scope, unicast enabled, general peering policy Open, policy locations Not Required and contracts Not Required. The same API response shows zero listed facilities and zero listed exchange LANs.

That profile helps in two ways. First, it confirms that the ASN is not only present in ARIN and RIPEstat; it is also represented in a peering registry used by operators. Second, it shows a self-described posture that is not a mass-market hosting catalogue. "Enterprise" is a broad label, but it is materially different from presenting public cloud regions, many exchange ports or a retail network footprint. The profile's global scope should be read as a PeeringDB field, not as proof of globally distributed infrastructure.

The empty facility and exchange sets are as important as the fields that are filled. PeeringDB API calls for Pegboard facilities at https://www.peeringdb.com/api/netfac?net_id=6046 and exchange LAN entries at https://www.peeringdb.com/api/netixlan?net_id=6046 returned empty data. That does not prove Pegboard has no racks or exchange connections. PeeringDB is operator-maintained and not complete for every network. But it does mean public diligence cannot point to a verified data centre or an exchange port from PeeringDB alone.

For a hosted-capacity buyer, the missing facility list changes the procurement conversation. Ask whether services are hosted in owned racks, leased colocation, bare-metal provider space, virtual instances, a partner platform or a mixture. Ask which party controls reboots, disk replacement, remote hands, switch ports and upstream tickets. Ask whether the provider has a named facility contract, a cabinet inventory, an out-of-band path and a tested migration path. A public profile that has an ASN but no facilities is a starting point, not assurance.

Pegboard may be entirely appropriate for a narrow, known-use relationship. The public PeeringDB record simply does not support claims about broad hosted capacity, multi-site resilience or current sales scale.

The Manitoba exchange trace is useful but weak

Packet Clearing House's MBIX page at https://www.pch.net/ixp/details/1316 identifies the Manitoba Internet Exchange in Winnipeg and lists active IPv4 and IPv6 subnets. The PCH subnet API at https://www.pch.net/api/ixp/subnets/1316 returned 206.72.208.0/24 as the active IPv4 subnet with 28 entities and 2001:504:26::/64 as the active IPv6 subnet with 25 entities. The same page lists exchange locations in Winnipeg, including Global Server Center, LES.NET sites and Manitoba Hydro Telecom.

The Pegboard-specific part is narrower. The PCH subnet detail API for the IPv4 subnet, https://www.pch.net/api/ixp/subnet_details/1316?subnet=206.72.208.0/24, includes 206.72.208.16 with ASN 62752, organization PEGBOARD HOSTING INC., peer:false, an empty peering policy and prefix count 0. The public page also shows Pegboard entries in the MBIX member address data. This is a locality clue: Pegboard is represented in MBIX address records. It is not evidence that Pegboard is currently exchanging production traffic there.

That distinction is important. An exchange address can be reserved, inactive, administratively present, partially configured or not visible as a public route source. A PCH member table can lag actual state. A PeeringDB profile can omit an exchange that exists. A BGP collector can miss local peering. Public evidence from one registry should not be forced to resolve every conflict. The honest conclusion is that Manitoba is relevant to Pegboard's visible identity, while active exchange-based capacity remains unproven.

The Manitoba clue still shapes the due-diligence questions. If Pegboard operates equipment in or near Winnipeg, which site holds the router and which site holds customer workloads? Is the exchange presence used for management, local peering, backup transit, community routing or legacy configuration? Is there a live route server session? Is any customer traffic dependent on MBIX? Does an outage at a Winnipeg exchange site affect the /24, or is the public route carried entirely through AS20473 elsewhere?

Locality is not a problem by itself. It can be a strength when the customer needs a known Canadian operator, low-latency regional hosting or a provider that understands local networks. It becomes a risk only when locality is assumed instead of documented.

RPKI is the cleanest public control

The strongest technical control in the public record is route-origin authorization. RIPEstat's RPKI validation endpoint at https://stat.ripe.net/data/rpki-validation/data.json?resource=62752&prefix=198.51.75.0%2F24 returned valid status for AS62752 and 198.51.75.0/24, with max length 24. That is exactly the public routing hygiene one wants to see for the single currently visible prefix. It means the public route-origin data authorizes AS62752 for that prefix in the validation view.

RPKI should not be oversold. RFC 6811 at https://www.rfc-editor.org/rfc/rfc6811 explains BGP prefix origin validation. It validates an origin relationship; it does not validate a data centre, a service-level agreement, a backup, a firewall, a support team or a customer database. RFC 7454 at https://www.rfc-editor.org/rfc/rfc7454 provides broader BGP operations and security guidance, including route filtering practices. ARIN's RPKI resource page at https://www.arin.net/resources/manage/rpki/ explains resource certification for ARIN-managed resources.

For Pegboard, the meaning is narrower and positive: the one public IPv4 route has a valid origin authorization in the RIPEstat view. That lowers one routing-risk category. It does not lower the risks created by single-neighbour visibility, undisclosed facility placement, unknown support hours or unclear data portability. A buyer should thank the operator for keeping the /24 cleanly authorized and then keep asking the rest of the infrastructure questions.

The route object consistency is also better than a purely marketing-only provider would show. RIPEstat's routing-consistency endpoint lists the prefix in both BGP and whois, with ARIN as authority. That supports the identity chain from registry to live route. It does not show whether the hosted service, if any, is monitored, backed up or recoverable.

In small-network diligence, good RPKI is necessary but limited public evidence. It is a sign of care at the routing layer. It is not an operating-resilience certificate.

Facility, power and hardware are the open questions

The article title deliberately names racks, transit and repair windows because those are the dependencies that public evidence does not resolve. Pegboard's visible route has to originate from equipment or a hosted routing service somewhere. Customer-facing hosting, if active, has to run on compute, storage, network interfaces, power, cooling, remote access and operational hands. None of the public company-specific records reviewed here identifies the facility, cabinet, cloud region, hardware inventory, power domain, maintenance window, remote-hands provider or spare-parts model.

That omission is common for small providers. Some keep facility details private for security reasons. Some operate from provider-owned bare metal and do not publish the site. Some use virtual routers or hosted BGP products. Some have a legacy ASN supporting a narrow customer set and see no need for a public product page. The absence of detail is not a wrongdoing signal. It is a boundary on what can be concluded.

The practical effect is that every resilience claim needs a component-level answer. Where is the router or route origin service? Where are customer workloads? Are compute and routing in the same facility? Is storage local, replicated or backed up to a separate provider? How are disks replaced? Who can access the console if the main network path is down? What happens if the upstream account is suspended, the provider host fails, a remote-hands ticket waits overnight, a power event affects one rack, or a billing issue blocks support?

The recovery clock is the hardest missing number. Hosted capacity is useful only if customers know how long they can tolerate loss of reachability, data, control-panel access or migration ability. Pegboard's public records do not publish an uptime target, incident status page, support schedule, escalation policy, maintenance calendar or backup restore objective. That may be fine for a private or relationship-driven service. It is not enough for a customer that has business-critical workloads.

Hardware stock is another hidden dependency. A provider can have a working route and still be fragile if it relies on one router, one switch, one server, one storage node or one person. Conversely, a small provider can be robust if it has clear spares, tested rebuilds, documented restore procedures and a second person able to execute them. Public routing data cannot tell the difference.

The right verdict is not suspicion. It is verification required.

Data locality requires more than a Canadian address

Pegboard's registry and PeeringDB records point to Canada, and specifically Manitoba. ARIN lists Box 62, Argyle, Manitoba, Canada for Pegboard Hosting Inc. PeeringDB's organization API at https://www.peeringdb.com/api/org/8393 lists PO Box 62, Argyle MB R0C 0B0, Canada, with latitude and longitude for Argyle. PCH's MBIX page points to Winnipeg exchange infrastructure. Those facts are meaningful for identity and locality signals. They are not a data-residency guarantee.

Data sovereignty and locality depend on where systems run, where backups sit, who can access them, what law governs the provider contract, what subcontractors are used, where logs are stored and how data is exported or deleted. A Canadian registry address does not prove that customer workloads or backups are in Canada. A Winnipeg exchange trace does not prove that application data is stored in Winnipeg. A PeeringDB global-scope field does not prove global capacity. It says how the network presents itself in a registry.

For some customers, the right answer may be simple: the service is not intended for sensitive data, or it is used only for public-facing endpoints. For others, especially organizations with privacy, public-sector, health, education or customer-record obligations, the address-space record is only the first document. They should ask for service location, subcontractor names, backup jurisdiction, log retention, access controls, export format and deletion procedure.

Data portability belongs in the same discussion. A small hosting provider can be excellent at personal support and still create migration risk if customers cannot export images, DNS zones, mailboxes, databases, backups or configuration quickly. Public Pegboard records do not publish a customer portal, export method, supported hypervisor, backup format, cancellation policy or number of days that data remains retrievable after termination. That does not mean such terms do not exist. It means they must be obtained before the customer treats the service as recoverable.

Local infrastructure can be valuable precisely because it is not abstract. But the value appears only when the location and operating boundaries are specific.

Who is affected when the edge fails

The public evidence does not identify Pegboard customers. It does not prove a live product catalogue or a current hosting offer. Still, the failure modes are clear for any organization relying on the visible edge or on Pegboard-managed capacity. If 198.51.75.0/24 becomes unreachable, any public services hosted in that block could lose inbound access. If the single visible upstream path fails and no alternate route is ready, the effect is prefix-wide. If a router, virtual router or account configuration breaks, the public route can vanish even if servers are powered on.

The affected parties would depend on what the block actually carries. If it carries websites, the pain is public reachability and reputation. If it carries mail, the pain is delayed delivery and trust degradation. If it carries DNS, the pain can spread beyond systems physically hosted there. If it carries remote administration, the outage can make repair slower. If it carries monitoring, customers may lose visibility just when they need it. If it carries backups, the first outage can weaken the recovery path for a second outage.

The commercial failure path is just as important as the technical one. A small provider may depend on one upstream account, one facility contract, one owner-operator, one payment method or one support relationship. If any of those breaks, customers may face delays that do not appear in BGP data. Can the provider open a high-priority ticket with AS20473? Can it move the /24 to another upstream quickly? Does it have another router configuration ready? Are customers allowed to move data out immediately? Are credentials held by more than one person? Are invoices and domain records separated from the hosting environment?

These questions are not hostile. They are the normal economics of hosted dependency. Customers outsource hosting because running infrastructure is difficult. The outsourcing works when the provider's physical and commercial controls are clearer than the customer's own. With Pegboard, the public record shows a real edge, but it does not yet show that control system.

What a customer should verify before relying on Pegboard

The first verification is service status. Is Pegboard currently selling or operating customer-facing hosting, managed services, virtual servers, bare-metal services, DNS, mail, storage, monitoring, transit-adjacent services or private hosting for known customers? If the answer is no, the network should be treated as a directory and routing artifact rather than an active hosting dependency. If the answer is yes, the customer should map each service to a facility, upstream, storage layer, backup path and support owner.

The second verification is route diversity. Is 198.51.75.0/24 intentionally single-homed through AS20473, or is a second path available but not visible in the public sample? If there is a second path, has Pegboard tested it recently? Can it be activated without waiting for a long carrier or provider ticket? Are route filters and RPKI records ready for the failover path? Does the customer know whether failover changes latency, DDoS exposure, firewall state or reverse DNS?

The third verification is facility and hardware control. Does Pegboard own servers, lease colocation, rent bare metal, use virtual infrastructure or operate a mix? Who owns the router? Who owns the switch? Who replaces a disk? Who power-cycles failed equipment? What are the remote-hands hours? Is there an out-of-band management path? Are backups off the same physical host and provider account? How often is restore tested?

The fourth verification is support. A small provider can deliver excellent support, but only if the customer knows the contact model. Is there after-hours coverage? Is there a phone bridge? What is the severity definition? Who can make routing changes? Who can approve emergency migration? How is the customer notified if the /24 is withdrawn, the upstream changes, a facility maintenance window is scheduled or a support contact changes?

The fifth verification is exit. Can the customer export data, images, DNS zones, logs, mailboxes, databases and backups without a special negotiation? How long does export take? What formats are used? What happens if the customer wants to leave during an incident? Are there termination holds, unpaid-invoice restrictions or provider-owned tooling that could delay migration?

Without those answers, Pegboard may still be a real operator, but the customer is buying a relationship rather than a measurable infrastructure service.

Monitoring should match the narrowness

Pegboard's public footprint is small enough that customer monitoring can be specific. A buyer does not need a generic global cloud dashboard to watch the public edge. It needs direct tests for 198.51.75.0/24, route-origin validity, upstream path changes, DNS dependencies, reachable service ports, backup retrieval and support response. If the service depends on a small number of IP addresses inside the /24, those addresses should be monitored from more than one external network. If the service depends on DNS hosted elsewhere, that dependency should be monitored separately from the Pegboard route. If backups sit outside the /24, restore checks should prove that they remain available when the Pegboard prefix is unreachable.

The same narrowness should shape incident language. A provider can say "the route is up" while a hosted server is down. It can say "the host is up" while an upstream path is impaired. It can say "backups exist" while restore access depends on the same account or network that failed. The customer should define the service it actually needs: public reachability, administration, data access, mail delivery, name resolution, database recovery, log access or migration. Each one has a different test.

Monitoring also protects the provider. Small operators can be unfairly judged by broad assumptions. If Pegboard is operating a limited, well-known service, a precise customer monitor can distinguish an upstream BGP issue from an application fault, a DNS issue from a storage issue, and a support delay from a facility delay. That makes conversations cleaner during an outage and reduces the temptation to infer capacity or negligence from one public signal. The public evidence is thin; the customer's monitoring should therefore be concrete.

Recovery depends on authority as much as reachability

The public records make Pegboard easiest to verify at the registry and route layer, not at the repair layer. ARIN's autonomous-system record at https://rdap.arin.net/registry/autnum/62752 and the ARIN network record for https://rdap.arin.net/registry/ip/198.51.75.0 establish who is associated with the numbered resources. RIPEstat's overview at https://stat.ripe.net/data/as-overview/data.json?resource=AS62752 and routing-status view at https://stat.ripe.net/data/routing-status/data.json?resource=AS62752 show the visible route. Those are necessary pieces of infrastructure identity. They do not answer who can enter the room, replace a failed optic, open an upstream ticket, approve a route change, retrieve a backup, or release customer data during a dispute.

That distinction is where the repair window begins. If Pegboard controls the router directly, a routing fault may be corrected by configuration, replacement hardware or a call to the upstream. If the route is originated from a virtual or hosted environment, the repair path may pass through another provider's customer queue. If the service sits behind AS20473, the practical question is not only whether AS20473 is a visible neighbour in https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS62752, but whether Pegboard has an urgent escalation channel, a second account path, a spare router configuration and the authority to move the prefix without a long approval chain.

The Manitoba exchange trace adds another authority question. PCH's MBIX page at https://www.pch.net/ixp/details/1316 and subnet detail API at https://www.pch.net/api/ixp/subnet_details/1316?subnet=206.72.208.0/24 place Pegboard in exchange address data, but the peer:false and prefix-count fields do not prove active restoration capacity. If MBIX is only a historic or administrative trace, it will not help a customer during a current upstream failure. If it can be activated, the customer still needs to know whether filters, route objects, RPKI authorization and operational contacts are ready before the incident.

The valid RPKI result at https://stat.ripe.net/data/rpki-validation/data.json?resource=62752&prefix=198.51.75.0%2F24 helps because it lowers the chance that a well-filtered network rejects the legitimate origin. It does not guarantee that an alternate origin path is usable. A clean route object is a control-plane prerequisite; it is not a spare switch, a spare server, a generator, a remote-hands contract or a tested data export.

Customers should therefore treat recovery authority as a contract item. The question is not just "is the route visible today?" It is "who can change the path, who can touch the equipment, who can restore the data, and how long does each party take when the public route stops working?" Without those answers, a real ASN can still leave the customer waiting on someone else's cabinet, ticket queue, account status or maintenance window.

The evidence grade is Weak, not negative

Weak evidence is not the same as negative evidence. Pegboard has public registry records, an active ASN, a directly allocated IPv4 /24, a current BGP route, valid RPKI for that route, a PeeringDB profile and a Manitoba exchange clue. That is more than a placeholder name. It is enough to identify an operating network surface and to justify continued monitoring.

The downgrade comes from what is missing. There is no public Pegboard product page showing current hosting plans or managed-service terms. There is no public facility declaration. There is no public support clock. There is no public status page. There is no public customer migration method. There is no public evidence of multi-site capacity. There is no visible IPv6 announcement. The public BGP view shows one prefix and one observed neighbour. PeeringDB lists no facilities and no exchange LANs. PCH shows Pegboard in MBIX member address data, but with peer false and prefix count zero in the IPv4 detail.

That combination is enough for a specific editorial conclusion: Pegboard Hosting Inc. should be treated as a real, narrow, Canadian routed edge whose hosting dependency profile remains mostly unproven in public. The company may have private evidence that changes the grade. It may have direct customer relationships, a solid facility arrangement, strong backups and responsive support. But public buyers and analysts cannot assume those controls from the current record.

The safest procurement stance is to separate identity from resilience. Identity is reasonably supported. Resilience is not yet publicly demonstrated. The next useful evidence would be a current service description, a facility or provider statement, a support and escalation model, a route-diversity explanation, backup and restore terms, a data-location statement and an exit procedure. Until then, Pegboard belongs in the category of infrastructure names that deserve verification before reliance.