Summary

  • ARIN records AS20005 under the name SANDHILLS-SA and links it to the organisation SANDHILLS PUBLISHING through handle SANDHI-2. ARIN also exposes a registered network entity containing 63.70.164.0/23. These are strong identity and accountability records. They do not prove that every Sandhills product, brand, customer workload, facility, or private system uses that autonomous system or prefix.
  • Sandhills' public history explains the continuity between Sandhills Publishing and the current Sandhills Global name. This lets the directory entity be connected to current first-party material without silently replacing the exact registry identity. The naming continuity is relevant; it is not a licence to attribute every activity of every related business to AS20005.
  • RIPEstat observed AS20005 as announced and showed 63.70.164.0/23 as its visible IPv4 prefix at the time reviewed on 31 July 2026. The routing-status response represented one prefix and 512 IPv4 addresses, with no IPv6 announcement observed in that particular view. Route collectors provide a time-bounded external observation, not a global inventory, private topology, service-level measurement, or guarantee of reachability.
  • Public BGP observations placed AS20005 at the origin of collected paths and showed AS7029 and AS15108 adjacent in those observations. An observed adjacency is not proof of a current commercial contract, physical diversity, complete upstream design, capacity, or failover. It is evidence that can support a question about path diversity, not the answer to that question.
  • The reviewed RPKI validation response returned unknown and no validating route-origin authorisations for the AS20005 and 63.70.164.0/23 pair at retrieval. That result is metadata requiring careful interpretation. It is not evidence of a hijack, outage, negligence, or insecure operation. It does identify a control-plane question that operators and counterparties may need to reconcile with intended routing policy.
  • Sandhills describes a fortified data centre in Lincoln, Nebraska, and a second data centre in Scottsdale, Arizona. It says the facilities are linked through a direct point-to-point network and use replication and geographic load balancing. These are company-declared design and capability statements. The reviewed sources do not independently measure uptime, recovery time, replication lag, capacity, incident history, or customer outcomes.
  • A dated 2014 Sandhills release provided capacity, storage, media-asset, service-scale, and high-availability descriptions. Those figures are useful as historical evidence of what the company said about the system at that time. They must not be presented as current capacity or current performance.
  • Current careers material identifies work categories including network and systems administration, cloud systems, patching, hardware repair, troubleshooting, database monitoring, and geographically dispersed replication. Job descriptions are useful signals about the kinds of maintenance the operator considers relevant. They do not disclose the deployed topology, staffing level, work quality, or incident record.
  • The principal operational burden lies between the layers. Registry data must remain accurate. Route announcements and route-origin metadata must reflect intended policy. Two facilities require coherent change control and independent failure assumptions. Replication needs consistency, lag, conflict, and recovery controls. Load balancing needs health checks that represent the real service. Monitoring needs owners and closure tests. Maintenance needs rollback. Exceptions need handoffs that reach people with practical authority.
  • Capability, reliability, and customer production results must remain separate. Public records establish a network identity and observed routing state. First-party pages describe capabilities. Product reliability requires repeated measurements with defined scope. Customer results require customer-level evidence and methodology. None of the latter two was established for this article.
  • The featured photograph shows the skyline of Lincoln, Nebraska. It provides headquarters-city context only. It does not depict Sandhills Publishing, Sandhills Global, either company-described data centre, AS20005, network equipment, systems, customers, reliability, or production results.

Sandhills Publishing is most useful as a study of control surfaces rather than as a profile. The public evidence shows a registered network identity, a currently observed route origin, a company-declared two-site operating model, and visible categories of technical work. Those facts make continuity questions concrete. They do not make the answers automatic. A registry can identify an accountable organisation while operational contacts become stale. A route can remain visible while an application fails. Two data centres can exist while a shared dependency defeats the intended separation. Replication can copy good data or bad data.

Load balancing can distribute traffic while masking a deeper failure. The quality of the system therefore depends on records, running configuration, evidence, and recoverable decisions staying aligned.

The Directory Entity and the Current Company Identity

The exact directory entity is SANDHILLS PUBLISHING. That wording matters because it is also the organisation name visible in ARIN records associated with AS20005. Sandhills' own history explains that Sandhills Publishing later became Sandhills Global. A responsible account should preserve both facts: the registered and directory identity is SANDHILLS PUBLISHING, while Sandhills Global is the company's current public operating name.

That continuity solves an identity question, but only within limits. It supports using current Sandhills pages to understand the company that stands behind the older name. It does not prove that every present-day subsidiary, marketplace, publication, cloud service, customer application, or office is technically attached to AS20005. Corporate identity and network use are overlapping sets, not identical ones. A large company can use third-party networks, cloud platforms, content delivery services, software-as-a-service systems, and separate business networks alongside its own registered resources.

ARIN's records create a public accountability surface. An autonomous-system registration supplies a unique number, an organisation association, and contact roles. The organisation entity provides a durable handle that can be referenced by other registry records. The network record provides a place to examine the registered IPv4 block. These records matter during provisioning, due diligence, route-policy review, abuse handling, and incident coordination because they give external parties a stable identifier and an expected operator identity.

The registry is a ledger and recordkeeper, not the operator of Sandhills' routers, facilities, servers, databases, or applications. ARIN can maintain the registration framework and accept authorised changes. It cannot make a stale mailbox responsive, correct a router configuration, restore a database, or validate an application deployment. Practical control remains with the organisation and its counterparties. That distinction prevents a common error: treating the existence of a registry record as proof that the running system is correct.

Record accuracy is still operationally important. A stale organisation name can slow legal or technical review. An out-of-date network contact can delay coordination. An incorrect address or role can create ambiguity about authority. A contact path that exists but is not monitored has formal value without practical value. Conversely, a perfectly maintained record cannot guarantee that the named party can resolve a problem within a desired time.

The directory entity should therefore be read as the first link in a chain. It establishes which company entity the article examines. The ARIN subject links that company identity to an autonomous-system number and address record. External routing observations show a current condition around those resources. First-party facility and careers pages describe claimed capabilities and work categories. Each layer adds evidence while retaining its own uncertainty.

This layered identity also helps prevent overclaiming. It would be improper to say that AS20005 is the whole Sandhills Global network. It would be equally improper to ignore the connection merely because the public company name has changed. The defensible position is narrower: SANDHILLS PUBLISHING is the registered organisation associated with AS20005, and Sandhills' own history connects that name to the company now presented as Sandhills Global.

AS20005 and the Registered IPv4 Control Surface

An autonomous-system number identifies a routing domain in the interdomain routing system. It is used to express where a route originates and to construct paths between independently administered networks. The number does not describe a building, a router model, a service portfolio, or a reliability level. Its meaning comes from registry records, routing policy, and the configuration that operators actually run.

ARIN records AS20005 under SANDHILLS-SA and associates it with SANDHILLS PUBLISHING. ARIN's address record covers the network containing 63.70.164.0/23. RIPEstat's announced-prefixes and prefix-overview data then provide an observation that the /23 was visible with AS20005 as origin at retrieval. The registry and observation agree on a narrow point: a Sandhills-linked identity is associated with the number resource, and the prefix was observed in public routing from that origin.

A /23 contains 512 IPv4 addresses. That arithmetic describes address space, not active hosts, customers, servers, capacity, or business scale. Addresses can be unused, reserved, segmented, translated, assigned to infrastructure, or used behind services that are not visible from public routing. The prefix also says nothing about how many physical links carry traffic or how many facilities participate in the service.

RIPEstat reported one visible IPv4 prefix for AS20005 in the reviewed routing-status view. It did not show an observed IPv6 prefix in that result. The absence of IPv6 in one external observation supports only a timestamped statement about that observation. It does not prove that Sandhills has no IPv6 in private networks, third-party environments, separate autonomous systems, customer platforms, test systems, or future deployments.

This is where resource accuracy and operational continuity meet. The organisation needs a clear record of which prefixes should originate from which autonomous systems, who may approve changes, and what external visibility should look like. Counterparties need enough accurate metadata to apply policy. Security and network teams need to distinguish intended announcements from mistakes or unauthorised changes. Incident responders need current contacts and a known escalation path.

The cost is not limited to initial registration. Organisations change names, addresses, staff, suppliers, and infrastructure. Prefixes may be reallocated internally, originated differently, or withdrawn. Maintainers and credentials must remain under appropriate control. Documentation must reflect running policy. Monitoring must compare expected and observed state without turning every planned change into an emergency.

There is also a scope problem. A public autonomous-system record can be central to network identity while representing only a small portion of a company's technology estate. Sandhills describes hosted and cloud applications, but the sources reviewed do not establish which products use 63.70.164.0/23, which services use third-party platforms, or how traffic is divided. Treating the prefix as a complete product map would turn a precise record into a misleading story.

The more useful interpretation is that AS20005 is one accountable control surface. It can be checked for identity, intended origin, visible prefixes, contact accuracy, and security metadata. It can also be correlated with service symptoms. If a public route changes while an application remains healthy, the observation may be incomplete or the service may use another path. If the route remains stable while the application fails, investigation should move down the stack rather than declaring the network healthy. The identifier helps organise inquiry; it does not eliminate it.

What External Routing Observations Establish

RIPEstat reported AS20005 as announced at the time reviewed. Its routing-status data placed the first observed route history in 2001 and showed current visibility through 31 July 2026. The same response represented the announced IPv4 space as one prefix with 512 addresses and reported visibility from the participating IPv4 RIPE RIS peers in that snapshot. These are useful external facts with a timestamp and an observer boundary.

BGP is distributed. A collector receives routes from participating peers and records the paths visible from those vantage points. It does not sit inside every network, see every policy decision, or measure every user path. A prefix can be visible at the collector while unreachable from a particular access network. Different networks may choose different paths. Maintenance can change a path without creating an outage. A service can fail even while its route remains visible.

The BGP-state data showed collected paths ending at AS20005 and displayed AS7029 and AS15108 adjacent to the origin in the reviewed observations. That is not enough to call either network a current contracted provider. It does not prove independent physical entrances, independent power, separate conduits, reserved capacity, symmetric traffic, or tested failover. It does not show whether other paths exist outside the collector view.

Observed adjacency is nevertheless useful. It can establish a baseline for change detection. If an expected adjacent network disappears, an operator can ask whether maintenance, policy, filtering, measurement limits, or a service event explains the change. If a new origin appears, responders can compare it with approved changes. If visibility narrows, they can test whether the effect is global or local to particular observers.

Routing history adds another layer but requires the same caution. A history of visibility intervals can show that a resource has appeared in public routing over time. It cannot reconstruct private change approvals, maintenance intent, capacity, packet loss, or application performance. Historical presence is not a service-level record.

Running configuration takes precedence when the question is what the system is doing now. Registry data expresses accountable identity and intended association. Collector data expresses what an external observer saw. Router configuration and counterparty policy determine actual route exchange. User experience then depends on links, DNS, firewalls, servers, data, and applications beyond the route. A discrepancy between records and observations is a signal to investigate, not proof that one layer is fraudulent.

Supervising this boundary creates work. Teams need an expected prefix and origin inventory, maintenance context, relevant observers, and a method to suppress known changes without hiding unexpected ones. An alert needs an owner who can inspect router state or contact a provider. It also needs a closure condition. A route alarm should not be closed merely because one chart returns to green; intended policy, multiple observations, and operator confirmation should converge.

The sources reviewed do not reveal Sandhills' upstream contracts, peering agreements, link capacity, router configuration, route-filter design, traffic engineering, or convergence targets. They do not show packet loss, latency, or availability. The public data supports a restrained conclusion: AS20005 and 63.70.164.0/23 had a visible public routing relationship at retrieval, and collected paths exposed adjacent-network context that must not be mistaken for a complete topology.

RPKI Unknown and the Difference Between Metadata and Verdict

The RIPEstat RPKI validation endpoint returned unknown for the AS20005 and 63.70.164.0/23 combination and returned no validating route-origin authorisations at the query time. This is a precise result from a defined service. It is not a general security verdict.

Route-origin validation asks whether a route's origin and prefix relationship is covered by relevant cryptographic authorisation data. A valid result can support an authorised-origin conclusion. An invalid result can identify a mismatch requiring investigation. An unknown or not-found condition generally means the validator cannot establish a covering authorisation from the available data. None of those states alone describes application security or availability.

An unknown result does not mean that the route was hijacked. It does not mean the origin was unauthorised in every operational or contractual sense. It does not prove negligence. It does not show that a network accepted or rejected the route. It cannot establish whether an outage occurred. Those would require additional evidence about intended policy, route-origin authorisations, validator state, routing policy, observed paths, and service impact.

The result still creates a useful question. Is the absence of a validating record intentional? Does the organisation maintain route-origin authorisations elsewhere or under a changed allocation? Are prefix and maximum-length choices aligned with operational announcements? Do relevant counterparties apply route-origin validation, and how do they treat unknown states? Who owns the lifecycle of this metadata?

RPKI also introduces maintenance cost. Authorisations must match intended prefixes and origins. Changes in routing design may require coordinated updates. Expiration, overly broad maximum lengths, incorrect origins, and emergency announcements can create different risks. Access to the relevant resource authority must be controlled and recoverable. Monitoring must avoid calling every unknown result an incident while still identifying changes that matter.

The public endpoint cannot answer who manages these controls for Sandhills, what approvals exist, whether any route-origin authorisation is planned, or how counterparties respond. It supplies evidence for an operational question, not evidence for a criticism. This distinction matters because exaggerated security claims can be as misleading as ignoring the metadata entirely.

For decision makers, the appropriate action is reconciliation. Record the retrieval time, prefix, origin, result, validator context, and intended state. Ask the accountable operator whether the observed condition is expected. Compare multiple sources if the result changes. Define what evidence closes the question. That approach treats security metadata as part of operational continuity rather than as a public label.

The Declared Lincoln and Scottsdale Data-Centre Model

Sandhills' locations page describes a primary data centre in Lincoln, Nebraska, and another data centre in Scottsdale, Arizona. The company characterises the Lincoln facility as fortified and describes the Scottsdale site as linked through a secure direct point-to-point network. It also says data is replicated and web traffic is geographically load balanced between the two server farms.

These statements establish that Sandhills publicly describes a geographically separated continuity design. They do not independently verify the physical details, current topology, capacity, uptime, recovery time, or operating results. Terms such as secure, reliable, high capacity, and fortified are company descriptions unless tied to independently verifiable measurements.

Geographic separation can reduce exposure to a local event, but distance does not automatically create independence. Two facilities can share carriers, software, identity systems, management tools, change processes, suppliers, or staff. A configuration error can propagate to both. Replication can copy corruption. A control-plane mistake can redirect traffic away from healthy systems. A shared credential compromise can affect both locations. An organisation therefore needs a dependency map, not only two addresses.

The point-to-point link is another control surface. Such a link can support replication, management, and service coordination. It can also become a shared dependency or a path through which failure propagates. Its operational value depends on capacity, routing, encryption, monitoring, failure isolation, and what happens when it is unavailable. The public page does not provide those details, so they should remain questions.

The dated 2014 release described tandem data centres, high-availability servers, load balancing, storage capacity, media-asset volume, hosted-service scale, and staff. Those figures show how Sandhills described its infrastructure at that moment. They should not be used as current specifications in 2026. Hardware changes, service portfolios change, data volumes change, and operating models change. Historical figures can explain design intent without becoming current performance evidence.

Facility continuity includes more than servers. Power, cooling, fire protection, physical access, environmental monitoring, spares, carrier paths, remote hands, and emergency procedures all matter. A facility can remain physically available while an external dependency fails. It can also become inaccessible while systems continue running. Public location descriptions do not reveal the test regime or failure history for these controls.

The two-site model also creates change-control questions. Are changes deployed simultaneously or in stages? Can a failed release be contained to one site? Are configuration and secrets managed consistently? Does failover depend on manual approval? How is data divergence handled when connectivity returns? Does a health check test the real user path or only a local process? These are not claims about Sandhills' internal implementation. They are the minimum questions implied by the declared design.

A continuity design should be judged by recoverable operation, not by topology alone. A second facility is valuable when it can assume a defined service under tested conditions, when data has a known recovery point, when dependencies are available, and when operators have authority to act. Without those elements, redundancy can increase complexity without delivering predictable recovery.

Replication and Load Balancing as Integration Systems

Sandhills says its geographically separate server farms use replication and load balancing. Both capabilities can support continuity. Both also create integration and supervision work that must be counted.

Replication is not one behaviour. It can be synchronous or asynchronous, database-native or storage-level, continuous or scheduled, one-way or bidirectional. Each choice changes latency, consistency, failure tolerance, and recovery. The public sources do not identify Sandhills' mechanism, so this article does not infer one.

The basic questions are universal. What data is replicated? How quickly? What happens when the link fails? How is lag measured? Which site is authoritative? How are conflicts resolved? Can operators stop replication before a logical error spreads? Can they restore a point before corruption? How are schemas, permissions, secrets, scheduled tasks, and application configuration kept compatible?

Replication can reduce data-loss exposure when one system becomes unavailable. It can also replicate deletion, corruption, or malicious changes. A green replication job may prove that bytes moved without proving that the resulting application is usable. Recovery evidence therefore needs more than job completion. It should include consistency checks and a test that a defined service can start from the replica.

Load balancing also needs a defined meaning. Geographic traffic distribution can reduce concentration and route users toward available capacity. A health check can remove a failed endpoint. Yet a health check that tests only a process or static page can leave a site marked healthy when database writes, authentication, DNS, mail, or an external dependency is failing.

Health checks can fail in the other direction. An overly sensitive threshold can remove a functioning site and concentrate traffic on the remaining site. A flapping endpoint can move users repeatedly. Session state or cached data can make one site behave differently. A load balancer can become a shared control point whose own configuration error affects both facilities.

Integration cost includes version compatibility, deployment order, rollback, certificates, DNS, observability, capacity assumptions, and incident authority. A software change that works in Lincoln but fails in Scottsdale can produce partial results that are harder to diagnose than a complete outage. A database change can require sequence and compatibility across both sites. A certificate or secret can expire in one location. A firewall rule can block replication while public health checks remain green.

The most important metric is not the existence of replication or load balancing. It is whether the organisation can detect divergence, identify the authoritative state, take a reversible action, and verify recovery. This requires baselines, thresholds, logs, ownership, and practice.

First-party careers material adds a useful but bounded signal. Sandhills lists work involving database monitoring, replication, troubleshooting, network and systems administration, patching, and hardware repair. This indicates that the company publicly recognises categories of work relevant to the declared design. It does not prove how those jobs are organised, how many people perform them, or whether a specific control succeeds.

Automation can assist with replication checks, deployment, health probes, and failover. Its capability should not be confused with product reliability. An automated failover may act quickly and still choose the wrong state. A monitoring model may classify anomalies and still miss the dependency that matters. The production result depends on inputs, thresholds, integration, human authority, and recovery design.

The Supervision Cost Across Layers

A two-site network and application environment generates signals at several layers. Registry records change slowly but can become stale. BGP changes quickly and can differ by vantage point. Facility systems report power, cooling, access, and hardware conditions. Servers report operating-system and component state. Databases report replication, locks, storage, and query health. Applications report errors and business transactions. User-facing monitoring reports what an external path can reach.

Supervision begins with expected state. Which prefixes should AS20005 originate? Which facilities should serve which workloads? Which datasets should replicate? Which health checks define service availability? Which software versions are approved? Which certificate and domain dates matter? Without a baseline, monitoring becomes a stream of observations with no decision context.

The next cost is signal quality. A route collector may report a path change that has no user impact. A server may report healthy while the application is broken. A replication process may be running while lag grows. A facility alarm may be transient. A synthetic check may fail because the monitoring network is impaired. Every signal needs corroboration and a classification path.

Alert volume is not resilience. More alerts can reduce detection time or overwhelm the people who must decide. Duplicate alarms from network, server, database, and application layers can describe one event. If each has a different owner and no common incident view, triage becomes the dominant cost.

Ownership must follow practical control. A registry discrepancy may require an authorised resource contact. A routing change may require a network engineer or external carrier. A failed server may require system administration or remote hands. Replication divergence may require database and application expertise. A customer-visible error may require support to collect context and communicate.

Handoffs are themselves failure points. An alert can be assigned to a team that lacks access. A provider can report the network healthy while the customer sees an application failure. A database team can restore data while DNS still directs users elsewhere. An incident can be declared closed before external monitoring confirms recovery.

Closure evidence should therefore be defined in advance. For a routing exception, expected origin and multi-vantage visibility may need to agree. For a replication exception, lag and consistency checks may need to pass. For a facility failover, the user path and critical transactions may need validation. For a patch issue, rollback or forward repair should be followed by application tests.

The reviewed sources do not reveal Sandhills' monitoring systems, thresholds, staffing, escalation policy, or mean repair time. Those facts remain unknown. The public evidence supports only the operating principle: the declared network, facilities, replication, and hosted services create multiple layers that require coordinated supervision. Any economic analysis that counts hardware but omits this work understates the cost of continuity.

Maintenance and Lifecycle Work

Sandhills' current careers pages describe work categories including cloud systems, network and systems administration, patching, troubleshooting, hardware repair, database monitoring, and replication. These descriptions are not an architecture diagram. They are evidence that the operator publicly recruits for recurring lifecycle tasks.

Patching illustrates the difference between a task and a system. Installing an update can remove a known vulnerability or correct a defect. It can also break compatibility, restart a service, change performance, or interact differently across two sites. Safe patching requires inventory, dependency knowledge, testing, maintenance authority, rollback, and post-change validation.

Hardware repair has similar hidden dependencies. Replacing a failed component may require spares, physical access, compatible firmware, data protection, and enough remaining capacity to take a system offline. A repaired server still needs to rejoin the correct configuration and replication state. The public job description identifies the work category; it does not establish repair times or outcomes.

Database maintenance combines availability and integrity. Storage pressure, index changes, schema changes, backup operations, replication lag, and failed jobs can affect performance and recovery. A database can be reachable while serving stale or inconsistent data. Maintenance therefore needs application-level validation as well as process-level health.

Network maintenance can affect both public routing and inter-site communication. Policy changes, filters, firmware, addressing, firewalls, and link work may have different effects at each facility. A change plan should state the intended route and service behaviour, how external visibility will be checked, and when to roll back.

Lifecycle drift is a particular risk in redundant environments. If sites are maintained at different times, temporary version differences may be intentional. If the difference persists, failover can expose incompatibility. If sites are changed simultaneously, one defective change can remove the separation that redundancy was meant to provide. Staging must balance consistency against common-mode risk.

Documentation is part of maintenance. Registry records, topology diagrams, dependency inventories, restoration steps, credentials, and supplier contacts change as the system changes. A runbook that describes an older service can be more dangerous than no runbook because it creates misplaced confidence.

Maintenance also competes with delivery work. New features, migrations, security fixes, capacity changes, and incident repair draw from the same engineering attention. The cost is not only labour hours. It includes scheduled disruption, review, testing, rollback readiness, and the opportunity cost of keeping specialists available.

Automation can reduce repetitive effort but adds software lifecycle work of its own. Scripts, orchestration, configuration systems, and monitoring rules need versioning, testing, credentials, and failure handling. A successful automated task needs evidence that the intended service condition was achieved, not merely that the command returned success.

The public evidence cannot show whether Sandhills performs any specific maintenance practice well or poorly. It does show that the declared operating surface requires sustained work. Continuity is not purchased once with a second facility; it is maintained through repeated, evidenced changes.

Exception Handling Across Routing, Facilities, Data, and Applications

Normal operation follows known paths. Continuity is tested when those paths disagree. An external route may disappear while internal systems remain healthy. A facility may be available while replication falls behind. Both sites may answer health checks while users cannot complete a transaction. A patch may succeed at the operating-system level while an application dependency fails.

Exception handling starts with classification. Is the symptom caused by measurement limits, planned maintenance, a routing change, a facility event, a server failure, data inconsistency, application deployment, external dependency, or user-specific condition? Classification determines who has authority and what evidence matters.

A routing exception should compare the registered prefix and origin, intended policy, router state, multiple external observations, and counterparty information. The appearance of AS7029 or AS15108 in collector paths is context, not a substitute for operator confirmation. An RPKI unknown result should be recorded without labelling it an attack.

A facility exception should separate power, cooling, physical access, local network, inter-site link, compute, storage, and application state. Moving traffic away from one site can protect users or overload the other. Operators need capacity assumptions and a threshold for reversing a failover.

A replication exception should preserve data integrity before chasing availability. If lag is increasing, forcing a role change may lose acknowledged data. If corruption is replicating, keeping the link active may destroy the recovery copy. The correct action depends on the replication model, which is not public in this case.

An application exception should test the complete service path. A process can be alive while authentication, database writes, search, media delivery, DNS, or a third-party service is failing. Geographic load balancing can cause only part of the user population to see the issue. Logs and transaction probes need enough context to identify the site and dependency.

Authority is as important as diagnosis. The person who detects a problem may not be allowed to change routing, stop replication, disable a release, or shift traffic. Emergency authority should be narrow, documented, and reversible. A delay caused by unclear approval can be longer than the technical repair.

Communication is another control. Internal teams, counterparties, support staff, and affected users may need different information. An early statement should distinguish known facts from hypotheses. Updates should not turn an observed route, facility description, or monitoring signal into a claim that has not been verified.

Evidence preservation matters because urgent changes can erase the conditions needed for diagnosis. Route snapshots, configuration versions, logs, replication positions, health-check results, and decision times can help distinguish cause from consequence. The purpose is not to create paperwork during an outage; it is to keep recovery from depending on memory.

Closure must include the user path and the underlying control. Restoring a web page is limited public evidence if replication remains unsafe. Restoring a route is limited public evidence if the application is still broken. Closing an RPKI alert is limited public evidence if the intended policy is still unclear. A service can be stable while follow-up work remains, but the residual risk should be explicitly owned.

Failure Modes and the Evidence Needed to Distinguish Them

The following failure modes are analytical scenarios, not claims that Sandhills experienced them.

Stale registry metadata. An organisation name, address, or contact can become outdated while the route continues to work. Evidence should compare the ARIN record with authorised company information and operator confirmation. The repair is a controlled record update, not a route change.

Route-policy drift. Running announcements can diverge from intended policy after maintenance, supplier change, or configuration error. Evidence should include intended prefix and origin records, router configuration, multiple external observations, and counterparties. One collector is limited public evidence to prove global impact.

Single-stack exposure. The reviewed RIPEstat result did not show an IPv6 prefix for AS20005. This can raise a roadmap or dependency question, but it does not prove that every Sandhills service lacks IPv6. Evidence requires product- and path-specific testing plus operator documentation.

RPKI misinterpretation. An unknown result can be treated as an attack or as irrelevant. Both reactions can be wrong. Evidence should identify the exact prefix, origin, validation data, intended authorisation state, and counterparty policy before assigning severity.

Inter-site link failure. A direct point-to-point link can fail or degrade while both facilities remain otherwise available. Evidence should separate link state, replication state, management access, and public service paths. A decision to fail over should account for data and capacity.

Shared upstream or control dependency. Geographic separation can be defeated by common carriers, DNS, identity, configuration, or management systems. Evidence requires a dependency map and failure-domain tests. Public facility descriptions do not prove independence.

Replication lag. A replica can be available but behind. Evidence should include transaction position, lag, workload impact, and recovery-point objectives. A process-health indicator alone is not enough.

Replicated corruption. Logical deletion, application error, or malicious change can reach both sites. Evidence should preserve immutable backups or point-in-time history and identify when the bad state entered the system. More copies are not sufficient when every copy reflects the same error.

Split authority or conflict. Bidirectional operation can create divergent writes or ambiguous leadership. Evidence should show the replication model, authoritative state, conflict rules, and application behaviour. The public sources do not identify Sandhills' model.

Misleading health checks. A load balancer can mark an endpoint healthy while a critical transaction fails. Evidence should compare local process checks, dependency checks, and external user-path tests.

Capacity concentration after failover. Moving all traffic to one site can exceed compute, storage, link, or database capacity. Evidence requires tested headroom and load behaviour. Two facilities do not automatically mean each can carry the full service.

Common-mode deployment error. The same defective configuration or release can affect both sites. Evidence should include version history, deployment sequence, change approval, and rollback state. Staged rollout can reduce this risk when dependencies allow it.

Patching and lifecycle drift. Different software versions can accumulate across locations or components. Evidence should compare approved baselines, actual versions, vulnerabilities, compatibility, and maintenance exceptions.

Facility event. Power, cooling, fire protection, physical access, or hardware can impair one location. Evidence should correlate environmental systems, local network, host state, and external service behaviour. A facility alarm does not automatically mean customer impact.

Monitoring noise. Multiple systems can produce overlapping or false alerts. Evidence should identify the original symptom, correlated signals, and a closure test. More dashboards do not resolve unclear ownership.

Handoff failure. Network, database, application, facility, supplier, and support teams can each see a partial problem without one owner assembling the chain. Evidence should record assignment, authority, decisions, and unresolved dependencies.

Contact failure. A technically correct escalation can stall because a mailbox, phone, credential, or approval path is unavailable. Evidence should include periodic contact tests and alternate authorised routes.

The purpose of this catalogue is not to create suspicion. It is to show why a topology statement cannot be equated with reliability. Each scenario needs a different evidence set and a different owner. Treating every symptom as "the network" delays the repair that actually matters.

Capability, Product Reliability, and Customer Results

The public sources support capability claims. ARIN supplies registry records. RIPEstat supplies observed routing and validation metadata. Sandhills describes two facilities, replication, load balancing, hosted and cloud applications, and technical work categories. A 2014 release supplies historical company claims about scale and infrastructure.

Product reliability is a separate question. It would require measurements such as availability, latency, packet loss, convergence, replication lag, restore success, transaction success, incident frequency, and repair time, each with a defined scope and period. The reviewed sources do not provide a verified dataset sufficient to score those outcomes.

Customer production results are narrower still. A named customer's outcome depends on its application, data, configuration, users, integrations, suppliers, operating team, and business process as well as Sandhills' services. No customer deployment, benchmark, interview, or controlled production study was verified for this article.

This separation also applies to automation and models. A system may have the capability to detect route changes, classify alerts, automate failover, or predict capacity. Reliability asks how often that system acts correctly under operating conditions. Customer result asks whether its action preserved a defined business service. Neither follows from capability alone.

Supervision cost can increase when automation is added. Someone must define the intended state, review thresholds, handle false positives, manage credentials, test changes, and override unsafe actions. Integration cost appears at the boundaries between network, facility, database, and application systems. Maintenance cost applies to the automation itself. Exception cost appears when an event does not fit the expected model.

First-party statements can be accurate descriptions of intent and still be limited public evidence reliability evidence. Independent routing data can be accurate within its observation scope and still miss an application problem. A historical capacity figure can be correct for 2014 and irrelevant to current performance. The analytical discipline is to label each evidence class and resist combining them into a stronger claim than any source supports.

The result is not a negative judgement about Sandhills. It is a defensible account of what can be established. Sandhills Publishing has an accountable network identity and an externally observed route. Sandhills Global publicly describes a geographically separated operating design and relevant technical work. Reliability and customer outcomes remain unmeasured in the reviewed public record.

What the Public Evidence Does Not Establish

The sources do not reveal Sandhills' complete private topology, every address used by its services, upstream contracts, peering agreements, link diversity, capacity, router configuration, route filters, traffic volume, data-centre floor plan, power design, cooling design, physical security controls, server inventory, storage architecture, replication protocol, consistency model, load-balancer implementation, monitoring stack, staffing level, or incident procedures.

They do not establish that every Sandhills brand or application uses AS20005 or 63.70.164.0/23. They do not establish present IPv6 capability across every environment. They do not establish current storage capacity, media volume, customer count, uptime, latency, recovery time, replication lag, patch compliance, security maturity, support quality, or customer satisfaction.

The RPKI unknown result does not establish a hijack or outage. The observed AS7029 and AS15108 adjacencies do not establish contracts or complete redundancy. The two-site description does not independently prove availability. The job descriptions do not prove a deployed architecture or maintenance outcome. The Lincoln skyline photograph does not depict company infrastructure.

No private test, benchmark, customer interview, employee interview, facility inspection, or production experiment was conducted for this article. These limits are part of the result. They preserve the difference between public evidence and speculation.

A Reality-Layer Control Checklist

  1. Identity: Confirm that AS20005, SANDHILLS-SA, SANDHI-2, organisation names, addresses, and contact roles remain authorised and accurate.
  2. Prefix intent: Maintain an approved record of which prefixes should originate from AS20005 and how changes are authorised.
  3. External observation: Compare expected state with multiple routing observations while preserving timestamps and collector limits.
  4. Route-origin metadata: Record the exact RPKI result and intended policy without treating unknown as a general security verdict.
  5. Facility dependencies: Map power, cooling, access, carriers, management systems, DNS, identity, suppliers, and staff shared across Lincoln and Scottsdale.
  6. Inter-site behaviour: Define what the point-to-point link carries, how failure is detected, and how service continues safely without it.
  7. Replication integrity: Measure lag, define authority and conflict handling, preserve point-in-time recovery, and test application usability from a replica.
  8. Load-balancer truth: Make health checks represent critical user transactions and dependencies, not only process availability.
  9. Change safety: Stage changes where appropriate, preserve rollback, and verify both sites after network, database, application, or security work.
  10. Alert ownership: Give registry, routing, facility, systems, database, application, and support exceptions named owners and closure tests.
  11. Capacity after failure: Verify that the remaining facility and dependencies can carry the defined service during a degraded condition.
  12. Evidence discipline: Keep capability, product reliability, and customer production results in separate records and approval standards.

The checklist does not score Sandhills. It converts the visible control surfaces into questions that can be answered with operating evidence. The central principle is coherence: public records, intended policy, running systems, and accountable decisions must agree closely enough that an exception can be detected, classified, repaired, and verified.

Public Sources