AS196745 is visible. The Datacenta Hosting counterparty still

Summary

AS196745 is a real, observable network identity. RIPE records connect DATACENTA-AS to ORG-DHL11-RIPE, and a July 2026 RIPEstat snapshot shows originated IPv4 and IPv6 address space with broad route visibility. Those records do not establish who owns a site, invoices a customer, employs support personnel, or accepts a service-level obligation.
The legal and trading identities require separate treatment. SC208801, 15255267 and 03290605 are distinct company numbers; the current company names, recent name changes, Datacenta Hosting trading brand and X-Net (Services) Ltd contracting language cannot safely be treated as one interchangeable identity.
PeeringDB and supplier pages help define questions, but they do not close them. Stale or empty self-reported fields cannot prove absence, while marketing statements about premises, circuits, backup and support require current, service-specific evidence.
The practical control surface is the signed Service Specification. It should identify the counterparty and bind bandwidth, backup, locations, maintenance, access, service levels, escalation, recovery and exit duties to evidence that can be tested throughout the contract.

One brand, several evidence systems

A buyer looking at Datacenta Hosting can find enough public material to feel that the basic picture is settled. There is an autonomous system with a durable identifier. There are company records. There is a customer-facing website describing hosting, connectivity, backup and security. There are managed-services terms. Each item is useful. The mistake is to treat their overlap as proof that they all describe the same legal and operational perimeter.

They do not perform the same function. An internet number registry associates resources and contacts with registry entities. A route-observation service reports what its collectors can see at a point in time. Companies House records legal entities and filing events. A supplier website presents services under a trading identity. Standard terms allocate rights and duties, but often defer the commercially decisive details to an order, schedule or specification. A due-diligence file becomes reliable only when it preserves those boundaries and then documents the links between them.

That distinction matters because a hosting service is not purchased from an ASN. Nor is it purchased from a brand in the abstract. A customer pays a legal counterparty for a defined service, delivered through a combination of network resources, locations, equipment, people, subcontractors and procedures. The customer needs to know which party controls or procures each dependency, which promises are contractual, which evidence is current, and what remedy follows if delivery falls short. Public routing data can strengthen one part of that inquiry without answering the rest.

Datacenta is therefore an identity-and-contract case before it is a capacity case. The public record supports the existence and visibility of AS196745. It also presents several names and company numbers that must not be collapsed. The relevant test is not whether the names look related. It is whether documentary evidence joins the network registrant, the contracting party, the invoicing party, the operating responsibilities and the assets needed for the purchased service.

This is a narrower claim than alleging that any identity is wrong or any service is weak. Public records can legitimately lag commercial changes, and a group can allocate registration, operations and contracting across different entities. Trading names are ordinary commercial tools. None of those arrangements is inherently problematic. The risk arises when a buyer assumes the bridge exists but does not obtain it, leaving accountability ambiguous precisely when a fault, recovery request, security event or exit makes the distinction consequential.

The evidence chain should therefore be read in layers. Start with what AS196745 proves. Separate the companies and their name histories. Identify what the current customer terms say about the provider. Treat marketing statements as attributed descriptions rather than independent verification. Finally, write the missing joins into a customer-specific Service Specification and support them with records that remain testable after signature.

What the routing record proves, and what it does not

The strongest public technical anchor is AS196745. RIPE RDAP records it as the active autonomous system DATACENTA-AS, registered in December 2009, with ORG-DHL11-RIPE shown as the registrant. The corresponding RIPE organisation entity names Datacenta Hosting Ltd, includes company number SC208801, records country GB and gives the Q.20 Dorset Innovation Park address. That organisation entity was last modified on 13 May 2026. Together, these entries support a registry association among the ASN, the organisation handle, the stated name, the company number and the address.

The routed surface is also observable. At the stated RIPEstat query time of 20 July 2026 at 16:00 UTC, AS196745 originated six IPv4 prefixes covering 1,536 addresses and ten IPv6 /48s. In that snapshot, RIPE RIS saw the IPv4 routes at 323 of 325 peers and the IPv6 routes at all 320 peers. The RIPE aut-num policy lists imports from AS5511, AS60670 and AS206347, while RIPEstat's observed-neighbour data returns those same three ASNs as observed neighbours.

These are meaningful facts. They show that AS196745 is more than a label on a marketing page. Address space was being originated, the routes were visible to a large share of the relevant collectors, and multiple external adjacencies appeared in both declared policy and observed data. For a buyer, those records can support checks that the ASN named in a proposal exists, that it is active in the routing system, and that the claimed Datacenta network identity has a registry trail.

But visibility is not the same as service assurance. A route collector sees control-plane announcements from its vantage points. It does not inspect the physical route of a circuit, the commercial terms under which upstream service is supplied, the amount of headroom on an interconnection, or the performance experienced by a particular customer. Three recorded neighbours do not automatically mean three independent failure domains. Two paths can share ducts, buildings, equipment, power or operational control. The public data does not resolve those possibilities.

Nor does broad route visibility prove that failover works within a contracted interval. It says nothing by itself about packet loss, latency, congestion, filtering practice, denial-of-service absorption, restoration priorities or support response. The six IPv4 prefixes and ten IPv6 /48s describe observed originations at one query time, not capacity reserved for a customer. The count of addresses does not disclose how they are allocated, whether a buyer receives portable or provider-dependent addressing, or what happens to DNS and network dependencies at exit.

The registry association has a similarly bounded meaning. ORG-DHL11-RIPE connects AS196745 to a named registrant record. It does not establish which entity owns each piece of network or hosting equipment, holds a property interest in any operating location, employs the people answering support requests, or signs the customer's invoice. It does not assign liability for a missed service level. Those are legal and operational facts that require different evidence.

A sound diligence memo should preserve both sides of this result. It should state positively that the network identity is public and observable, with a dated snapshot of originations, visibility and neighbours. It should also mark every conclusion that remains open: circuit diversity, upstream contracts, capacity, path quality, failover, security controls, location ownership, staffing and contractual responsibility. This prevents two opposite errors, dismissing useful routing evidence because it is incomplete, or promoting it into a guarantee it was never designed to provide.

The dated nature of the snapshot matters as well. Routing changes. Prefixes can be added or withdrawn, adjacencies can change, and registry entities can be updated. Procurement should retain the query date and the exact resource identifiers, then decide which signals need periodic monitoring. A pre-signature observation can establish a baseline. It cannot substitute for ongoing service reporting or for a contractual duty to notify the customer when a material dependency changes.

The company numbers do not collapse into one identity

The legal-name trail is where an apparently simple provider identity becomes a verification problem. The RIPE organisation entity associates Datacenta Hosting Ltd with SC208801. Companies House, however, currently records SC208801 as Datacenta Hosting (Scotland) Ltd, an active company incorporated in July 2000 with data-processing and hosting SIC 63110. Its overview records that DATACENTA HOSTING LIMITED was the company's name from September 2003 until 17 September 2024.

A different company carries the exact current Companies House name DATACENTA HOSTING LTD. Its number is 15255267. It was incorporated in November 2023 as PBL 200 LTD, adopted the Datacenta name on 23 September 2024, and filed dormant-company accounts for the period ending in November 2024. That sequence places the Scottish company's name change and the English company's adoption of the name six days apart.

The timing invites an obvious question about coordinated restructuring. It does not answer it. The filings reviewed for this source package do not prove a transfer of customers, assets, intellectual property resources, contracts or liabilities between SC208801 and 15255267. A name becoming available and another company adopting it can be consistent with a planned group change, but consistency is not evidence of the transaction terms. The buyer needs the bridge document rather than an inference from dates.

This distinction is easy to lose because names are cognitively stronger than numbers. A procurement team sees Datacenta Hosting Ltd in a RIPE record, DATACENTA HOSTING LTD at Companies House and Datacenta Hosting on a website, then treats the shared words as a stable identifier. Company numbers are the safer anchors. SC208801, 15255267 and 03290605 remain distinct even when names and trading styles move. Every diligence table, approval memo and contract draft should therefore pair a name with its number and role.

The role column is as important as the number. One entity may be a registry holder, another an asset owner, another an employer, and another a contracting company. The public materials do not establish that allocation here. A buyer should ask for a current legal-entity chart identifying the registered holder of AS196745, the party controlling relevant address resources, the owner or lessee of each service location, the owner of customer-facing equipment, the employer of operational staff, the invoicing entity and the party accepting service-level liability.

The response should be documentary. If the arrangement relies on intra-group licences, service agreements, asset transfers or agency authority, the supplier can provide a suitable confirmation or extract without disclosing irrelevant confidential terms. If X-Net (Services) Ltd contracts for a service that depends on resources registered to SC208801, the customer needs to know what gives the contracting party continuing access to those resources for the contract term. If 15255267 plays no role in delivery despite holding the current exact Datacenta name, that too should be stated to prevent misdirected notices, credit checks or claims.

Dormant-company accounts require care. The filing by 15255267 for the period ending November 2024 is a fact about that reporting period and entity. It is not, by itself, proof of the company's later role, the wider trading operation or the financial position of another company. The correct use of the filing is to sharpen the question: what does 15255267 do now, if anything, and why does it hold the name? It would be an overreach to infer the operational status of the Datacenta Hosting service from that filing alone.

The RIPE entity's May 2026 modification date should likewise not be used as a broad validation stamp. It indicates that the entity was modified, not that every legal and commercial relationship implied by its fields was independently re-underwritten on that date. A current-looking registry entity and recent company-name changes can coexist without being fully reconciled in public. That is precisely why the customer should request an explicit statement linking the identifiers.

There is also a practical incident-management reason to resolve the chain. During an outage or security event, a notice addressed to a brand may not satisfy a contractual notice clause. During exit, a customer may need cooperation from the party controlling an IP dependency or physical equipment even if a different company issued invoices. During a claim, the party named in the Service Specification and the evidence of its authority will matter more than the visual consistency of websites and registry labels.

Identity diligence is therefore not administrative neatness. It determines where obligations land. The minimum acceptable result is a one-page schedule that maps each protected identifier and operating role to a legal entity, with discrepancies explained. That schedule should be incorporated into or expressly referenced by the contract so it cannot drift away from the commercial bargain.

The published terms point to the contracting surface

The third company number in the chain is 03290605. Companies House records X-Net (Services) Ltd as active and as formerly KIMCELL LIMITED until April 2024. X-Net's current contact page says X-Net is the new name for Kimcell, which also traded as Datacenta Hosting, and it lists Datacenta support at the Dorset location. More importantly for customer obligations, X-Net's managed-services terms identify the provider as X-Net (Services) Ltd trading as Datacenta Hosting.

That language changes the centre of gravity. The RIPE registrant association is still relevant to network-resource diligence, but a prospective customer reading the published terms has a concrete reason to ask whether 03290605 will be the legal counterparty. The answer should come from the quotation, order form, Service Specification and invoice details, not from assumptions based on the website domain or the exact Companies House name of another entity.

The phrase "trading as" does useful work but not unlimited work. It explains how one legal company can present a customer-facing brand. It does not merge X-Net (Services) Ltd with SC208801 or 15255267. It does not transfer registry resources, property or liabilities by itself. It does not show which company owns equipment or certifications. A buyer should preserve the legal name and number in the signature block, notices clause, payment instructions, insurance evidence and any service-credit mechanism, while treating Datacenta Hosting as the trading identity.

The relationship between contracting authority and operational control is the key join. If X-Net (Services) Ltd promises availability that depends on AS196745, the customer should obtain confirmation that it controls, or has enforceable access to, the network resources and upstream arrangements needed to perform. If another entity operates a location, provides support staff or owns equipment, the agreement should explain whether that entity is a subcontractor, affiliate or supplier and whether X-Net (Services) Ltd remains fully responsible for performance.

This is not a demand that every dependency be owned by the contracting party. Modern managed services commonly rely on affiliates and third parties. The due-diligence objective is accountability, not vertical integration. A clear contract can make one counterparty responsible for a multi-party delivery chain, impose flow-down obligations, require notice of material changes and preserve remedies. An unclear contract can leave the customer trying to reconstruct that chain after a failure.

Invoicing should be checked separately because payment practice can silently reinforce the wrong assumption. The entity issuing an invoice, the bank-account beneficiary and the VAT details should match the agreed counterparty or an expressly documented collection arrangement. Credit and insurance review should be performed on the entity bearing the obligation. Where supplier evidence names different companies, the approval record should show why each appears and which one the customer can enforce against.

The naming history also affects change control. A contract lasting several years may outlive another rebrand or internal reorganisation. The Service Specification should require advance notice of a change to the contracting entity, trading style, ownership or control of material service resources where that change could affect performance or enforcement. Assignment and novation should require the agreed process. Registry updates should not be treated as a substitute for contractual notice.

This approach converts the public discrepancy into a manageable control. The buyer does not need to prove a hidden corporate story from open records. It needs the supplier to state the present arrangement, evidence its authority, and commit that the named counterparty remains responsible. Once those points are written down, the different registry and company identities become monitorable facts rather than unresolved ambiguity.

PeeringDB shows the limit of self-disclosure

PeeringDB adds another identity for AS196745: Datacenta Hosting, with an open peering policy. Yet the profile leaves traffic and geographic scope undisclosed, shows zero IPv4 and IPv6 prefixes, lists no public exchange or facility presence, and was last updated in July 2022. The zero-prefix fields conflict with the July 2026 RIPEstat observation of six IPv4 prefixes and ten IPv6 /48s.

The conflict is valuable because it demonstrates why evidence must be ranked by purpose and freshness. RIPEstat reports observed routing at a stated query time. PeeringDB is a self-maintained interconnection profile whose fields may be incomplete or stale. For current prefix visibility, the dated observation is stronger. For understanding what the network chooses to disclose to potential peers, the PeeringDB profile remains informative, including through its omissions.

Those omissions are not proof of absence. No listed public exchange or facility does not establish that AS196745 has no physical presence, private interconnection or purchased transit at a location. Zero prefix fields do not erase routes observed by RIPE RIS. Undisclosed traffic does not mean zero traffic. A buyer should describe the profile as limited public evidence for a current facility, port or capacity map, not as evidence that the network lacks those things.

The diligence response is straightforward: ask for a current network schedule. It should identify relevant production and backup locations, circuit providers, logical upstreams, physical diversity claims, handoff points, capacity commitments and failover design for the purchased service. Sensitive details can be handled under confidentiality. The schedule should distinguish supplier-owned components from third-party services and state how material changes are notified.

PeeringDB should then be used as a consistency check, not as a service guarantee. If the supplier's schedule explains private interconnection or facilities absent from the public profile, the absence is reconciled. If the supplier relies on the open peering policy as evidence of resilience, the buyer should ask for the specific paths and controls that affect its service. A broad policy label cannot replace a customer-specific architecture.

Marketing pages define claims to verify

Datacenta's supplier pages describe a broader service surface than the public routing records. The pages market Dorset-based colocation, managed hosting, managed applications, environmental controls, UPS, monitoring and 24/7 support capability. The network page offers broadband, point-to-point links, selected peering and IP transit under AS196745. The backup material says backups can run locally within each data centre and remotely between centres, describes encrypted data stored in the UK and says a secondary site can be offered.

The security page says the operator owns its hosting premises, does not resell floor or rack space to other hosting providers, and uses diverse-routed circuits.

These statements matter because they identify the operating model the supplier wants customers to consider. They can guide a request for evidence and help detect whether a proposal quietly omits a capability presented publicly. They remain supplier assertions, however. The pages in this source package do not disclose current spare capacity, customer allocations, test results, circuit contracts or certificate scope. They do not prove that every advertised option is included in every service.

Attribution is therefore essential. A diligence note can say that Datacenta Hosting markets UK-stored encrypted backup and an optional secondary site. It should not convert that into a finding that a particular customer's data has an immutable off-site copy or that restoration has succeeded within a target time. It can record a claim of diverse-routed circuits. It should not infer physically independent paths without diagrams, provider records and a test. It can note a claim of owned premises. It should not identify the legal owner without property or corporate evidence connecting the premises to a named company.

The wording around support deserves the same care. A stated 24/7 capability can refer to monitoring, alert intake, remote response, on-call escalation or staffed physical access, and those are not equivalent. The managed-services terms place boundaries around physical access and support hours. The Service Specification needs to define which events are monitored continuously, who can act, how quickly acknowledgement and intervention must occur, and whether physical attendance is included.

Backup language is particularly prone to category errors. "Remote" does not necessarily mean a failure-independent copy. Two centres can share a risk, and an encrypted copy can still be mutable or inaccessible during an account compromise. A secondary site being available does not mean it has been selected, configured or reserved. The customer should request copy locations, administrative separation, retention, immutability, restore-test results, recovery-point objective, recovery-time objective and the capacity needed to restore the full service.

The same principle applies to power, cooling and environmental controls. Product pages can establish the claimed feature set, but resilience depends on design, maintenance, test history, loading, fault response and the precise service boundary. The buyer does not need to publish sensitive infrastructure details. It does need enough evidence to understand the failure domains relevant to its workload and to test whether contractual promises are operationally plausible.

Marketing and contract documents should also be compared for exclusions. If a product page suggests a capability but the terms make it optional, the option must appear in the signed specification with a price, scope and service level. If a proposal uses an expansive phrase such as managed backup, the schedule should divide supplier duties from customer duties. The test is not whether the marketing statement is true in some general sense. It is whether the purchased configuration makes the statement enforceable for this customer.

The Service Specification is the control surface

The published managed-services terms explain why the Service Specification carries so much weight. They place maximum server space, internet service levels, inclusive traffic, firewall rules and other performance details in that customer-specific document. In other words, the standard terms create a framework, while the specification determines much of the actual service. A buyer that reviews only the website and boilerplate has not yet reviewed the bargain.

Bandwidth is a clear example. The terms provide no minimum transfer rate unless guaranteed bandwidth is selected. Public BGP visibility cannot fill that gap. A customer that requires predictable throughput should state committed bandwidth, measurement points, directionality, burst treatment, contention assumptions, exclusions and remedies. It should also distinguish internet access from private links, cross-connects or point-to-point services. Inclusive traffic allowances and overage treatment should be explicit.

The network schedule should identify whether customer addressing depends on AS196745 and what happens at migration. If the service uses provider-assigned addresses, the exit plan may require DNS changes, firewall updates, allow-list changes and coordination with external parties. The customer should know whether any address portability is promised, how much notice is required, and what assistance is included. The routing record proves that the ASN originates space; it does not define a customer's rights in that space.

Backup is another contractual fork. The terms make backup the customer's responsibility unless a backup option is requested and agreed. This allocation must not be obscured by a general backup page. The specification should name protected systems and data, copy frequency, retention, locations, encryption, administrative controls, immutability, monitoring, failure notification and deletion rules. It should assign responsibility for application consistency and credentials. Most importantly, it should require restore testing and state the RPO and RTO that the selected design is intended to support.

Capacity should be bound to those recovery duties. A backup can exist while the compute, storage, network or licensed software needed for restoration is unavailable. If the customer requires recovery at a secondary site, the agreement should state whether resources are dedicated, reserved, preconfigured or procured after an event. It should define the order in which shared capacity is allocated and how frequently recovery assumptions are tested. The supplier pages do not disclose those details.

Maintenance terms need similar precision. The published terms allow scheduled and emergency maintenance. The Service Specification should define notice for scheduled work, permitted windows, emergency-notification procedure, expected service impact, change-risk controls and post-incident reporting. It should state how maintenance is treated in availability calculations and whether repeated or extended maintenance triggers credits or termination rights. An emergency exception should permit necessary action without becoming an unlimited exclusion from accountability.

Service levels should be written as measurable obligations rather than broad assurances. Availability needs a defined service boundary, measurement source, calculation period and exclusion set. Response time should distinguish acknowledgement, technical engagement, workaround and resolution. Escalation should name roles and channels without depending on a single person. Credits should be automatic or easy to claim, but credits alone may be limited public evidence for chronic failure. The customer should retain stronger remedies for repeated misses, material security failures or inability to recover.

Monitoring and support coverage should reflect the workload. If 24/7 monitoring is purchased, the specification should list monitored components, alert thresholds, responsibility for triage and the actions permitted without customer approval. It should distinguish a continuously watched alarm from a continuously staffed engineering function. Escalation timing, on-call arrangements and physical intervention should be clear. Public claims of support capability do not establish these service-specific details.

Physical access is another point where assumptions can fail. The terms require notice and bound access by support hours. A colocating customer should document authorised-person procedures, notice periods, emergency access, identity checks, escort requirements, tooling, deliveries, remote-hands availability and charges. It should define what happens when urgent access is needed outside ordinary support arrangements. A general statement that premises are owned or monitored does not answer those questions.

Firewall and security duties belong in the same schedule. If firewall rules are a service parameter, the specification should identify who approves changes, how urgent rules are handled, what is logged and how configuration is exported at exit. Security evidence should name the exact legal entity, service, location and period within scope. A generic certificate reference would not prove coverage of the purchased service, and this source set does not establish any certificate scope.

The contract should also manage dependency change. If an upstream, location, backup design, contracting entity or operating affiliate changes materially, the customer needs notice and, for high-impact changes, a right to assess the revised risk. The threshold should be tied to service effect rather than every routine engineering adjustment. This preserves operational flexibility while preventing the evidence basis approved at signature from disappearing without review.

Exit is where identity, network and physical control converge. The published terms require a customer to remove its server at its own cost within seven days after termination, with storage and later disposal provisions for uncollected equipment. A serious exit plan should begin before termination. It should inventory equipment ownership, data, virtual machines, configuration, credentials, logs, DNS, certificates, IP dependencies and third-party licences. It should assign export formats, transfer channels, validation, deletion evidence, cooperation hours and charges.

Seven days may be workable for a simple collection, but the customer should test it against its actual migration sequence. Data transfer can take time, external DNS and allow lists may need coordination, and replacement infrastructure may not be ready on the same day. The specification should state whether access continues during an orderly transition, what assistance is available, and when data or equipment can be disposed of. It should also identify the entity that has custody and authority to release physical assets.

The counterparty mapping belongs directly in this document. The signature and notices sections should name X-Net (Services) Ltd or whichever legal entity actually contracts, with company number and registered details. A schedule should explain the roles of SC208801, 15255267 and any other delivery entity relevant to the service. If AS196745 is a material dependency, the supplier should confirm the contractual party's right to use it and its responsibility for services delivered through it.

This makes the Service Specification more than a product checklist. It becomes the place where public evidence is converted into enforceable accountability. Registry data supplies stable identifiers. Observed routing supplies a dated technical baseline. Company filings separate legal persons. Supplier pages supply claimed capabilities. The specification joins those layers, selects the options actually purchased, allocates duties and defines proof. Without that join, a thick diligence file can still leave the central question unanswered: who owes what to the customer when the service is tested?

Build a proof chain, not a document pile

The most efficient review is an evidence matrix organised by obligation. Its first column should name the customer outcome: connectivity, availability, backup, recovery, security response, physical access or exit. The second should identify the legal counterparty. The third should list the resources and other entities needed for delivery. The fourth should point to current evidence. The fifth should record the contractual measure and remedy. The final column should assign an owner and review date.

For connectivity, the matrix can include AS196745, DATACENTA-AS, ORG-DHL11-RIPE, the July 2026 RIPEstat baseline, relevant upstreams and the customer architecture. The public data establishes the first part. The supplier must provide the customer-specific circuit and failover evidence. The contract must then define the service level. Keeping these in separate cells makes it difficult for a route-visibility figure to be mistaken for a performance commitment.

For legal identity, the matrix should list Datacenta Hosting Ltd as the RIPE organisation name, Datacenta Hosting (Scotland) Ltd with SC208801, DATACENTA HOSTING LTD with 15255267, and X-Net (Services) Ltd with 03290605. It should record KIMCELL LIMITED and PBL 200 LTD only as relevant name-history anchors, not as present interchangeable providers. The supplier's legal-entity statement should explain the operational and contractual roles.

For location claims, the Q.20 Dorset Innovation Park address can be recorded as the address in the RIPE organisation entity and as the Dorset support location described by X-Net. It should not automatically be labelled the owner, sole production site or backup site. The supplier can identify exact service locations, the legal basis for access and control, and the components delivered at each. If sensitive information is redacted, an independent assurance report or contractual representation can cover the necessary point.

For backup and recovery, marketing pages are evidence that options are presented, while the terms establish that backup must be requested and agreed. The proof chain is complete only when the Service Specification selects the option and a current test demonstrates the agreed process. A screenshot of a successful job is weaker than a restore record showing scope, date, result, exceptions and recovery time. A test of one file is not necessarily evidence of full-service recovery.

For support, the matrix should separate monitoring, alert receipt, remote engineering, physical intervention and management escalation. Each can have different hours and targets. The supplier should identify the team or entity performing each function and the contract should keep the primary counterparty responsible. This avoids the common situation in which "24/7" appears in an approval memo but no one can say which action is available at 03:00.

Evidence should have owners and expiry dates. Route observations can be refreshed automatically or on a scheduled basis. Company names and filing status can be checked before renewal. Insurance, certifications and test reports have defined periods. Circuit maps and recovery designs should be reviewed after material changes. The supplier should be obliged to notify, but the customer should not depend entirely on notification for facts that can be independently monitored.

Discrepancies should be logged rather than smoothed away. The zero-prefix PeeringDB fields and the current RIPEstat route observations are not a reason to discard either source. They are a prompt to record that the PeeringDB profile is stale or incomplete for that purpose and to request a current network disclosure. The different Datacenta company names are not solved by choosing the most familiar one. They require a role mapping.

The matrix should also distinguish evidence of design from evidence of operation. A diagram can show intended diversity; a circuit order can show purchased services; a test can show whether failover occurred under stated conditions. A backup policy can describe retention; a restore report can show execution. A contract can allocate responsibility; an incident record can show performance. Strong diligence uses more than one type where the risk justifies it.

This method keeps the review proportionate. A low-impact service may need a concise identity confirmation, specification and exit plan. A service supporting critical workloads may justify deeper circuit, recovery, security and financial evidence. The public source set does not determine the customer's risk appetite. It does reveal exactly where a customer-specific decision is required.

Test the joins before signing

Scenario testing can expose weak joins faster than another round of generic questionnaires. The scenarios need not assert that any failure has occurred. They ask whether the proposed documents would produce an unambiguous response if it did.

First, suppose AS196745 remains visible globally but the customer's application is unreachable. The incident process should not stop at evidence that routes exist. It should identify the measurement point for the customer's service, the responsible support team, the escalation target, the relevant upstream or internal dependency and the service-level clock. The contract should determine whether the event is covered even when BGP announcements remain present.

Second, suppose a network or operating resource registered to SC208801 becomes unavailable to the contracting party. The customer should not have to establish the internal group arrangement. X-Net (Services) Ltd, if it is the counterparty, should remain responsible under the agreement and should have documented rights or alternatives sufficient to continue delivery. Change-notification and continuity clauses should address a transfer or loss of control.

Third, suppose a primary service location is unavailable and the customer invokes recovery. The specification should identify the backup copies, the secondary-site arrangement actually purchased, reserved or obtainable capacity, activation authority, target RPO and RTO, and the evidence from the last restore or recovery exercise. Supplier pages describing remote backup or an offered secondary site are not enough to run the procedure.

Fourth, suppose the customer terminates and needs data, virtual machines, DNS changes, firewall configuration and physical equipment. The exit schedule should identify export formats, dependencies on AS196745 addresses, cooperation duties, access arrangements, fees, custody and the seven-day removal requirement. It should make clear which legal entity can release equipment and which party certifies deletion. Waiting until notice is served would convert every unresolved identity question into a deadline risk.

Fifth, suppose a scheduled change overruns or emergency maintenance causes extended disruption. The contract should define notice, status updates, incident review, availability treatment, credits and escalation. It should not rely on a general statement of support capability. The buyer should know when an emergency exclusion ends and ordinary accountability resumes.

Each scenario tests a different bridge: routing to customer performance, registrant to counterparty, backup claim to recoverability, service operation to exit, and maintenance right to remedy. If the documents produce a clear owner, action, time and evidence path, the chain is becoming credible. If the answer is merely that Datacenta Hosting will handle it, the identity and obligation mapping remains incomplete.

The output of scenario testing should be amendments to the Service Specification, not speculative conclusions about the supplier. Missing evidence can be requested. Unclear roles can be mapped. Optional services can be selected or rejected consciously. An unmeasurable promise can be replaced with a metric. The process turns uncertainty into an explicit commercial decision.

What can be concluded now

The public record supports a definite but bounded conclusion. AS196745 is an active and visible network identity associated in RIPE with DATACENTA-AS and ORG-DHL11-RIPE. The July 2026 routing snapshot records originated IPv4 and IPv6 space and three observed neighbours that align with the listed import policy. A buyer can use that evidence as a network baseline.

The same record does not identify a complete provider perimeter. SC208801, 15255267 and 03290605 are distinct legal identifiers with different current names and histories. The current managed-services terms point to X-Net (Services) Ltd trading as Datacenta Hosting as the provider named in that document. Public filings and registry records do not prove the asset, customer, contract or liability transfers that would make every Datacenta label interchangeable.

The supplier pages and PeeringDB profile add context, not closure. They describe capabilities and a peering posture, while also revealing gaps in freshness and service specificity. They should shape the diligence request, but the buyer should not infer current capacity, physical diversity, recovery performance, premises ownership, certificate scope or customer outcomes from them.

The decisive evidence is consequently customer-specific. It is the signed Service Specification, supported by a legal-entity map, network and location schedule, test records, service metrics and an executable exit plan. That package should say which company is accountable, what resources support the service, how performance is measured, what happens when dependencies change, and how the customer leaves.

Visible routes are valuable because they make one layer of the service independently testable. They become misleading only when asked to prove another layer. Datacenta Hosting due diligence is strongest when it keeps the layers separate, documents the joins and makes the contracting party answer for the whole agreed service.

AS196745 is visible. The Datacenta Hosting counterparty still needs proof