MARITIK XIWO CLOUD SAS sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The strongest evidence about XIWO CLOUD is not a product page. A March 2025 Paris Court of Appeal decision says the company operated mainly in the French Antilles and bought from Orange the civil-infrastructure access, FTTH lines, interconnection, equipment hosting, internet capacity and submarine capacity needed to serve customers.
• The same decision records unpaid Orange invoices, an order for provisional payment of EUR781,131.44 plus a further EUR496,302.92, and Orange's suspension of interconnection services after repeated demands for payment. BODACC records judicial liquidation opening on 11 December 2025, with 23 May 2025 set as the date payments had ceased.
• AS204902 nevertheless remained announced on 12 July 2026. RIPEstat showed six IPv4 announcements covering 1,280 unique addresses, one IPv6 /48, and one observed neighbour, AS202753 GLOBALGRID. A live route proves an operating BGP path, not that XIWO CLOUD still controls a solvent, supported hosting operation.
• PeeringDB lists eight facilities across Paris, the French Caribbean, French Guiana and Miami, plus a 1 Gbps NVIX connection. Those are operator-maintained interconnection claims. They do not disclose rack count, power reservations, server inventory, workloads, contracts, restore tests or whether any XIWO CLOUD customer service remains in those sites.
• The evidence grade is Negative for company-controlled hosted resilience and Medium for current route existence. Customers or counterparties should require written proof of the present service operator, asset custody, data location, support authority, transit diversity, backup access and an executable migration path before relying on the MARITIK name.

A live route and a liquidated company are not the same operating fact

The public record around MARITIK XIWO CLOUD SAS is unusually revealing because two different kinds of evidence point in opposite directions. Internet measurements show a network that was visible at the edge of the global routing table in July 2026. French legal records show that the company named behind that network had entered judicial liquidation seven months earlier. Both can be true at once. They answer different questions.

The routing fact is straightforward. RIPEstat's AS204902 overview identified the holder as "MARITIK XIWO CLOUD SAS" and marked the autonomous system announced at the 12 July 2026 observation time. Its routing-status record showed six IPv4 prefixes, 1,280 unique IPv4 addresses, one IPv6 /48 and one observed neighbour. That is credible evidence that another network could see routes originated with AS204902.

The legal fact is more consequential for a customer. The official BODACC liquidation notice says the Paris Tribunal for Economic Activities opened judicial liquidation for XIWO CLOUD on 11 December 2025. It set 23 May 2025 as the date of cessation of payments and appointed SCP BTSG, represented by Antoine Barti, as liquidator. This is not a vague market rumour or an old directory status. It is the French commercial-notice record for SIREN 908 671 043.

The distinction matters because an autonomous system is not a company continuity certificate. BGP can remain visible while a court-appointed liquidator preserves assets, while a supplier keeps a circuit active, while a buyer or related operator manages network equipment, while registry contacts lag a legal change, or while only a small technical remnant remains. The public material reviewed here does not establish which of those explanations applies. It does not identify the person currently authorised to bind the service, receive a support escalation, release customer data, approve a route change or promise a restoration time.

That uncertainty changes the normal burden of proof. For an ordinary small host, a live route, a customer portal and a facility listing might be the beginning of an operating case. For a company in judicial liquidation, they are not enough. The buyer needs evidence that connects the legal operator, the physical assets and the customer obligation in the present tense. No public document located for this article closes that triangle.

The correct conclusion is therefore neither "the network is dead" nor "the company is operating normally." The first would ignore current routing. The second would ignore the liquidation. The supportable conclusion is narrower: AS204902 remained technically visible, but XIWO CLOUD's public operating status as a company-controlled cloud or hosting provider is negative until the current operator and continuity arrangements are demonstrated.

The court record exposes the real infrastructure underneath the offer

The most useful public description of XIWO's operating surface comes from litigation rather than marketing. The official Court of Cassation publication of the Paris Court of Appeal decision concerns XIWO and Orange and was issued on 21 March 2025. The judgment says XIWO's main activities were internet, telephone and audiovisual access, exercised principally in the Antilles. It says XIWO entered an umbrella agreement with Orange in February 2022 and then signed contracts for the infrastructure and services needed to connect its customers.

The list is operationally specific. According to the judgment, the Orange contracts covered access to civil engineering and aerial supports, interconnection services, connections, FTTH lines and the hosting of some equipment. Orange also produced purchase orders for IP internet connection and submarine capacity. Those facts reveal an infrastructure model in which a customer-facing provider assembled service from critical inputs supplied by a much larger carrier.

That model is common and can work well. A provider does not need to own ducts, poles, landing stations, every rack or every long-haul circuit to deliver a reliable service. The important questions are whether contracts remain in force, invoices are paid, capacity is sized correctly, failure responsibilities are explicit, alternatives are available and customers can be moved before a supplier dispute becomes a service interruption. The court record shows that the contractual layer was not an administrative side issue for XIWO. It was part of the production system.

Orange sent demands for payment in June, July and September 2023, according to the decision. A conservative attachment authorised in April 2024 proved unsuccessful. Orange then sought provisional payment, and the July 2024 order required XIWO to pay EUR781,131.44 including tax, with interest. On appeal, Orange produced a further account and invoices, and the court ordered an additional provisional payment of EUR496,302.92. The combined provisional amounts were more than EUR1.27 million before interest and costs.

The failure mechanism is even more important than the amount. The judgment says Orange had sent four demands, including one in March 2024, and eventually suspended interconnection services after the first order was not performed. It also says the contract allowed suspension for non-payment. XIWO argued that Orange's service delivery had been late or disparate and sought compensation, but the court found that XIWO had not produced evidence sufficient for the provisional relief it requested. The court upheld the initial payment order, added the further amount, rejected payment delay and ordered additional costs.

For infrastructure analysis, this is a documented provider-contract failure path. A financial dispute at the wholesale layer reached the network layer. Interconnection was not an abstract account code; it was a service Orange could suspend. Equipment hosting, internet connection and submarine capacity were not wholly controlled resources; they came through contracts with a supplier. Customers downstream of XIWO therefore depended not only on XIWO's routers and technicians but also on XIWO maintaining commercial access to Orange's facilities and transport.

The record does not say every XIWO service failed, how many customers were affected, whether another carrier replaced Orange, or whether AS204902 used the same path after 2025. It would be wrong to extrapolate that far. It does prove the central proposition of this article: hosted and access capacity sold under the XIWO or MARITIK operating surface depended on racks, carrier contracts, long-distance capacity and payment continuity outside the company's direct ownership.

Liquidation turns ordinary hosting questions into custody questions

The corporate timeline sharpens the risk. An official BODACC modification notice, published on 3 April 2025, records the name XIWO CLOUD, a EUR1,000 capital amount, a change of president, and an activity description covering data centres, colocation, server and infrastructure hosting, storage, networks, security, cloud computing, backup, disaster recovery and equipment maintenance. It also lists the Paris address at 34 avenue des Champs-Elysees.

That notice is useful for legal scope, but declared scope is not installed capacity. A company's registered activity can describe what it intends or is authorised to do without showing a single owned cabinet, a megawatt of reserved power, a spare server, a backup repository or an active customer. Here the declared scope expanded the hosting and cloud language shortly before the legal and financial position became unmistakably adverse.

The later BODACC notice is the stronger status signal. Judicial liquidation generally changes who has authority over company assets and how creditor claims are handled. This article does not offer legal advice about any particular contract, and the public notice does not inventory network equipment or customer data. It does mean that a customer cannot safely infer ordinary management authority from an old contact, a registry maintainer or a still-responsive router.

Custody becomes the practical question. Who possesses the servers? Who holds the credentials for hypervisors, storage arrays, backup systems, domain names, route objects and customer accounts? Who can enter the facilities? Who can authorise remote hands? Who is paying for power, cross-connects, transit and replacement hardware? Who can lawfully release a customer image or backup? Who owns an IP address assigned to a customer, and can that address move with the customer? Public records do not answer those questions.

The French government's company search API result for SIREN 908671043 still returned an administratively active establishment at the Paris address, with data processing and hosting activity, when checked for this article. That does not cancel the BODACC liquidation. Public registers serve different functions and update on different schedules. The apparent conflict is itself a warning against treating a single "active" label as proof of service continuity.

A March 2025 copy of XIWO CLOUD's updated statutes confirms the legal name, EUR1,000 capital, Paris address and SIREN. It does not identify facilities or customer assets. Meanwhile, the current XIWO consumer website's legal notice says that site belongs to XIWO TECHNOLOGIES SASU, SIREN 933 713 323, at a different Paris address. Its retail offers and support statements therefore cannot be treated as current XIWO CLOUD evidence without a document connecting the two legal companies and assigning responsibilities.

This boundary is easy to miss because names persist after operations move. MARITIK appears in the autonomous-system name. XIWO appears in domains, maintainer handles and network records. XIWO CLOUD appears in corporate and RIPE records. XIWO TECHNOLOGIES appears on the current retail site. Similar branding is not enough to transfer liabilities, assets, support promises or customer contracts from one company to another. A buyer must identify the contracting entity by registration number and obtain written confirmation of who now supplies each component.

AS204902 was live in July 2026, but through one visible neighbour

The routing evidence is substantial enough to reject a simplistic claim that nothing remains. The RIPE Database autonomous-system entity names AS204902 as MARITIK, describes it as an enterprise IP backbone and links it to ORG-WA687-RIPE. The linked RIPE organisation entity names XIWO CLOUD SAS, gives SIREN 908 671 043 and the same Champs-Elysees address, and was modified in April 2026, after liquidation opened.

Current visibility is also clear. RIPEstat's announced-prefixes result showed the aggregate 154.7.0.0/22, its four component /24 routes, 162.12.217.0/24 and 2001:978:1b08::/48 in the two-week observation window ending 12 July 2026. The aggregate and its component routes overlap, so six IPv4 route entries should not be multiplied into six independent blocks. RIPEstat calculated 1,280 unique IPv4 addresses: the 1,024 addresses in the /22 plus the separate 256-address 162.12.217.0/24.

The same result showed a break in the displayed timelines between 7 and 9 July for all listed routes. That could reflect withdrawal, collection timing or another visibility event. The data alone does not establish a customer outage, its duration or its cause. It does show why route history matters more than a static registration. A service claim should be tested against continuous measurements and incident records, not only against whether an ASN exists.

The public topology was narrow at the observation time. RIPEstat's ASN-neighbours result showed one unique neighbour, AS202753, on 12 July. Its routing-consistency result showed the import and export relationship with AS202753 both in BGP and in registered routing policy. The MARITIK aut-num entity likewise says it accepts any route from AS202753 and announces AS204902 to it.

AS202753 is identified by RIPEstat's current overview as GLOBALGRID-NETWORK, GLOBALGRID SASU. GLOBALGRID's own neighbour view showed multiple upstream-facing neighbours and five downstream-facing networks, including AS204902. That means AS204902's one visible adjacency can reach a provider with a broader observed topology. It does not give AS204902 independent paths at its own edge.

This distinction is central to resilience. An upstream can be well connected while its customer still has one local handoff, one router, one cross-connect or one contract. If the AS204902-to-AS202753 session fails, if the local port is disabled, if a bill is disputed, or if the equipment originating AS204902 loses power, the diversity inside AS202753 may not help. Public BGP shows the route relationship, not the physical separation of ports, fibres, buildings or commercial agreements.

Nor does one visible neighbour prove there is only one physical circuit. Multiple links can support the same ASN adjacency, and private arrangements may not be visible in this view. The evidence required to claim resilience would include circuit identifiers, handoff locations, carrier names, physical path diversity, router separation, failover behaviour and recent test results. None of that is public for AS204902.

The resulting route grade is Medium. The route origin and current visibility are well supported. The architecture, ownership and operational authority behind the origin are not.

The address space crosses legal and operational boundaries

IP addresses can look like assets on a network map, but their registration history shows another layer of dependency. ARIN's RDAP record for 154.7.0.0 identifies a larger 154.7.0.0 to 154.7.63.255 allocation named XIWO-TECHNOLOGIES and registered to an organisation at 60 rue Francois 1er in Paris. Within it, the more specific RDAP record for 154.7.1.0 identifies 154.7.1.0/24 as XIWO-CLOUD, registered to XIWO at 34 avenue des Champs-Elysees.

The route picture therefore includes space whose parent allocation is associated with a different legal address and company identity from XIWO CLOUD, even though AS204902 announces the aggregate and specifics. That is not proof of impropriety. Address space is routinely suballocated or routed by agreement. It is proof that route origination and legal resource custody are not identical.

The separate ARIN RDAP record for 162.12.217.0/24 also names XIWO-TECHNOLOGIES. RIPEstat's RPKI validation result showed AS204902's origin as valid for that prefix on review. By contrast, its validation results for the 154.7.0.0/22 aggregate, 154.7.1.0/24 and the IPv6 /48 returned "unknown," meaning no validating route-origin authorisation was found by that validator. Unknown is not invalid, but it offers less cryptographic assurance about intended origin.

IPv6 adds another supplier trace. A RIPE Database search for 2001:978:1b08::/48 names Xiwo-SAS, links the assignment to the XIWO CLOUD organisation and shows Cogent maintainer references. The route6 object names AS204902 as origin. Again, the public record supports a real route while showing that the resource sits inside a broader allocation and administrative structure.

For a hosting customer, these distinctions become important during migration. Provider-assigned addresses normally do not move automatically with a server. If a customer uses hard-coded addresses, access-control lists, allowlists, DNS records with long time-to-live values or partner integrations bound to an old address, changing providers can be disruptive. If the address is controlled through another company or upstream allocation, the customer may have even less leverage to retain it.

An exit plan should therefore assume renumbering unless a portable assignment and transfer mechanism are documented. It should inventory DNS, certificates, mail reputation, firewall rules, VPN peers, monitoring targets and third-party allowlists. It should also identify who can change reverse DNS and route objects during a transition. AS204902's live routes do not answer those customer-specific questions.

Eight facility listings do not equal eight recoverable cloud regions

PeeringDB presents a wider footprint than the current BGP edge. The operator-maintained AS204902 network profile calls the network MARITIK INFRAS, classifies it as network services, claims global scope, IPv4 and IPv6 support, traffic in the 20 to 50 Gbps range, one exchange and eight facilities. It also lists a MARITIK website, a looking glass, selective peering and standard network-operations hours from 7:00 a.m. to 11:00 p.m. EST.

Those fields are useful leads, not audited capacity. The listed maritik.com website and looking-glass host did not resolve in a direct DNS check on 13 July 2026. The profile's main network record was last updated in December 2025, and the facility associations were created in April 2024. A stale or unreachable public endpoint does not prove the network is down, but it weakens the case that customers can independently inspect current performance or find a current service authority.

The PeeringDB facility associations place local ASN 204902 at Equinix MI1 in Miami; Telehouse Paris 2; Equinix PA3 in Saint-Denis; MCN Le Lamentin in Martinique; GNU Cayenne Collery in French Guiana; GCN Galisbay in Saint Martin; GCN Baillif in Guadeloupe; and NRO de Lorient in Saint-Barthelemy. The geography coheres with the court's statement that XIWO operated mainly in the Antilles and with a network that connected French territories to Paris and Miami.

But a facility association says very little about installed or usable capacity. It does not reveal whether XIWO CLOUD leased a full cabinet, a partial rack, a cross-connect, a virtual port or only maintained a planned presence. It does not disclose power draw, redundant feeds, cooling limits, access rights, remote-hands terms, hardware serial numbers, spare inventory or customer workload. It also does not show whether the listed presence survived the Orange interconnection suspension or the liquidation.

The current PeeringDB exchange record lists one operational 1 Gbps connection at NVIX, with IPv4 and IPv6 addresses and route-server participation. It was updated in March 2026. That is a post-liquidation technical signal. It may indicate that someone was maintaining at least part of the interconnection record. It still does not identify that operator or prove customer hosting continuity.

A 1 Gbps exchange port is also not the same thing as upstream transit or server capacity. An exchange can provide paths to participating networks; a transit provider provides broad reachability. PeeringDB showed the exchange, while RIPEstat showed AS202753 as the sole observed neighbour. Whether NVIX traffic was visible, material or physically diverse from the AS202753 handoff cannot be determined from the published material.

Calling the eight entries "regions" would therefore overstate the evidence. A cloud region normally implies deployed compute and storage, customer provisioning, failure isolation, support, capacity management and a recovery design. The public record supports eight claimed network presences. It does not support eight active compute sites, eight backup repositories or automatic customer failover among them.

Installed capacity is not the same as usable capacity

The difference between installed and usable capacity is where many small-provider assessments go wrong. A server in a rack is installed capacity. It becomes usable customer capacity only when power, cooling, network ports, address space, software licences, storage protection, monitoring, support and replacement parts are all available under enforceable arrangements.

The court decision proves that Orange hosted some XIWO equipment. It does not identify the model, quantity, age or present custody of that equipment. PeeringDB proves claimed network presence at named facilities. It does not inventory servers. The corporate activity description includes data centres, cloud, backup and disaster recovery. It does not prove that XIWO CLOUD owned a data centre or operated a tested recovery service.

Power is the first missing measure. There is no public XIWO CLOUD figure for contracted kilowatts, rack density, redundant feeds, UPS topology, generator coverage or fuel arrangements. Even if the underlying facility has strong power systems, the customer service depends on the power product actually bought and the equipment's connection to it. A single-corded server in a premium facility remains single-corded.

Hardware is the second. No public inventory shows spare routers, optics, power supplies, disks, controllers or complete replacement servers. In a liquidation, ordinary purchasing authority can change, supplier credit can tighten and replacement lead times can become decisive. A provider may have empty rack space but no ability to restore a failed storage controller quickly. That is why advertised rack or traffic scale cannot be read as recoverable capacity.

Support labour is the third. PeeringDB's stated operations hours are broad but not round-the-clock, and the profile does not publish a status page. Facility remote hands may be available, but remote hands need authorised instructions, access lists, diagrams and replacement parts. The public record does not identify the team currently watching AS204902, the escalation path outside the stated hours or the person authorised to approve emergency work after liquidation.

Storage and backup are the fourth. The legal activity description mentions backup and disaster recovery, but no public document gives replication topology, backup frequency, immutability, retention, encryption ownership, restore time or restore-test results. A backup can exist and still be unusable if credentials are lost, billing is suspended, keys are unavailable, data is in the same failure domain or no one has rehearsed restoration.

Usable capacity is thus a chain of simultaneous conditions. The route data proves one link. The court and insolvency records show that commercial access to other links has failed before. No current public evidence proves the complete chain.

The most important failure path has already happened once

Infrastructure reviews often imagine dramatic failures: a fire, flood, cable cut or router fault. XIWO's record points to a quieter and more common mechanism. A provider can lose a critical service because the wholesale contract behind it is unpaid or disputed.

The Orange dispute is not merely a financial footnote. Orange's services included interconnection, FTTH access, equipment hosting and long-distance capacity. The court records that Orange suspended interconnection after unpaid demands and an unperformed court order. That is a demonstrated link between accounts payable and network availability.

For customers, the lesson is that supplier-contract resilience should be treated like technical redundancy. A second router on the same unpaid service is not independent. A backup server in a rack whose cross-connect can be suspended by the same counterparty is not a complete recovery design. A second site reached through the same wholesale agreement may not protect against contractual termination.

The present AS204902 path raises a similar question. RIPEstat saw one neighbour, AS202753. The route can be globally visible through that neighbour, but the public record does not show the contract term, account status, port ownership or right to continue after a change in control. It also does not show a second current transit contract that AS204902 itself could use if AS202753 service stopped.

Rack failure is another path. A power supply, top-of-rack switch, storage controller or fibre optic can fail without affecting the rest of a facility. Recovery then depends on spares and access. Because no XIWO CLOUD inventory or service response history is public, customers cannot estimate repair time from the facility list.

Support failure can extend a small incident. If monitoring alerts go to former employees, if access lists are outdated, if the liquidator must approve expenditure, or if the technician lacks current diagrams, a repair that should take minutes can take hours or days. These are possibilities, not reported facts about a particular 2026 incident. They are the controls that need evidence in light of the legal status.

Billing and identity failure can be just as damaging. A domain, certificate, software subscription, cloud backup account or facility badge can expire even while routers continue forwarding traffic. The non-resolving MARITIK website illustrates the difference between a functioning route and a maintained customer-facing identity. A network may carry packets while its public operating surface decays.

Finally, migration itself can fail. A customer may discover that its only recent backup is controlled by the provider, that export bandwidth is limited, that a proprietary image cannot boot elsewhere, that IP addresses cannot move or that no authorised person can release data. A recovery plan that has never produced a working copy outside the provider is only an intention.

Data locality is unresolved across Paris, the Caribbean and Miami

The planned topic of data sovereignty is supported, but only as an unresolved operating question. The public network footprint spans jurisdictions. PeeringDB lists facilities in mainland France, Guadeloupe, Martinique, French Guiana, Saint Martin, Saint-Barthelemy and the United States. The court describes activity principally in the Antilles. The route registry identifies a French company. None of those facts tells a customer where a particular virtual machine, backup or log file is stored.

Network presence and data residence are different. A provider can peer in Miami while hosting data in Paris. It can route through Paris while storing a backup in Martinique. It can use a facility only for transport equipment. Without a service-specific architecture or contract, a map of points of presence cannot answer locality.

The ownership boundary is equally important. The Orange judgment shows that some equipment was hosted by Orange and that submarine capacity was purchased. PeeringDB names other facilities. ARIN records place some address resources under XIWO TECHNOLOGIES. AS204902 now reaches the internet through GLOBALGRID. A customer needs to know which entity processes data, which entity possesses media, which entity holds encryption keys and which jurisdiction governs access to each copy.

Liquidation adds a further layer. The customer may have contractual rights against XIWO CLOUD while physical equipment sits in a supplier facility and technical access is exercised by another operator. If the contract, asset and credentials are separated, retrieving data can depend on coordination among parties with different incentives and legal duties.

The minimum credible locality evidence would be a workload-level site list, named legal operators, subprocessors, backup locations, cross-border transfer terms, encryption-key custody and deletion procedures. It would also distinguish primary data, replicas, backups, logs and support telemetry. No such public document was found for XIWO CLOUD or MARITIK.

This absence does not prove that data was moved improperly. It means customers should not infer sovereignty from a French registration, a Caribbean sales history or a facility map. Locality must be demonstrated at the service and dataset level.

Who bears the impact when the service boundary breaks

The court describes XIWO as a provider of internet, telephone and audiovisual access, primarily in the Antilles. That gives the impact analysis a wider scope than a conventional web-hosting outage. A failure could affect households or businesses using access services, while hosted customers could lose applications, websites, backups or management access.

The exact 2026 customer population is not public. It would be irresponsible to claim a current subscriber count or to attribute the present XIWO retail customer base to XIWO CLOUD. The current retail site's legal notice belongs to XIWO TECHNOLOGIES. What can be said is that the historical XIWO service model placed a smaller provider between end users and wholesale infrastructure supplied by Orange.

For an access customer, an interconnection suspension can mean loss of reachability even when the local fibre remains physically intact. The optical link to the premises may show light, but traffic cannot reach the wider internet. Telephone and television services may share parts of the same access and account relationship. The impact can therefore be simultaneous across services.

For a hosted customer, route withdrawal can make servers unreachable while leaving disks powered. A rack power failure can do the reverse: the route remains visible while the customer's machine is down. A billing or control-plane failure can prevent account access without a network outage. Each symptom points to a different repair authority, which is why customers need current contact and ownership information.

For partners, the risk is propagation. A managed-service provider, reseller or business customer may have promised availability to its own users based on XIWO capacity. If it has no independent backup or export, a supplier event becomes its own incident. The smallest visible network can therefore sit inside a larger chain of dependent services.

Creditors and facilities also face operational choices. They may need to preserve equipment and records while limiting unpaid exposure. A facility cannot simply assume that every person with an old badge remains authorised. A carrier cannot assume a disputed service should continue indefinitely. Those protections are rational, but they can conflict with a customer's expectation of immediate access.

The way to reduce harm is to settle authority before an incident. Customers need named contacts for technical support, legal notices, data release and emergency migration. They need their own credentials, backups and documentation. They need to know which obligations belong to XIWO CLOUD, which belong to another XIWO-branded company, and which belong to a facility or carrier.

What would establish recoverable service now

Because the public evidence grade is negative, recovery claims need direct, current proof. The first item is operator identity: a dated document naming the legal entity currently providing service, its authority to use AS204902, and its authority over customer contracts and assets. A familiar brand name or maintainer handle is not enough.

The second is asset custody. The operator should identify each active facility, rack or cage; the owner of the hardware; the party paying for power and cross-connects; and the people authorised for access. Serial-numbered inventories and current facility confirmations would distinguish deployed equipment from historical profile entries.

The third is network design. A credible package would show AS204902's current upstream contracts, physical handoff sites, routers, port speeds and diverse paths. It would explain the role of AS202753, the NVIX connection and any other private links. It would include a recent failover test and clarify whether the single observed neighbour represents multiple physical circuits or one dependency.

The fourth is capacity. Customers should see current port utilisation, rack power headroom, storage reserve, hardware spares and replacement lead times. PeeringDB's 20 to 50 Gbps traffic band and eight facilities are too coarse. Capacity must be connected to the actual service and its recovery target.

The fifth is support. The operator should publish a reachable status surface, incident contacts, escalation authority, support hours and remote-hands arrangements. It should show that monitoring, facility access and emergency purchasing survive staff or ownership changes.

The sixth is data recovery. A customer should be able to restore a recent backup into an environment outside the MARITIK/XIWO failure domain. The test should cover encryption keys, application configuration, identity systems, DNS, certificates and external integrations, not just a raw disk copy. Recovery time should be measured, not estimated from marketing language.

The seventh is portability. Contract terms should state export formats, bandwidth limits, fees, time windows, account access after termination, data deletion and assistance with migration. They should also explain whether IP addresses can move and who controls reverse DNS during transition.

The eighth is insolvency-specific authority. Customers should obtain appropriate confirmation from the party legally entitled to act for XIWO CLOUD or from a clearly documented successor. Technical staff can keep systems running, but only an authorised party can reliably settle ownership, payment and release obligations.

Evidence at that level could improve the grade. Without it, the route data remains a sign of technical life detached from a proven customer service.

The honest grade is negative for resilience, not for route existence

MARITIK XIWO CLOUD SAS is not an empty registry name. AS204902 was visible, carried both IPv4 and IPv6 announcements, had a valid RPKI state for at least 162.12.217.0/24 and maintained a post-liquidation exchange record. The court record also proves that XIWO once assembled real access and hosting inputs from Orange. Those facts justify continued observation.

They do not justify treating the company as an ordinary operating cloud provider. The legal entity is in judicial liquidation. A major supplier dispute led to interconnection suspension. The current route had one observed neighbour. The listed facilities do not reveal active racks or workloads. The corporate and retail brand boundaries have changed. No public evidence identifies the present service authority, backup custody, spare hardware, restore performance or customer exit terms.

The final assessment is therefore split deliberately. Current network existence is Medium: multiple independent routing and registry views support it. Company-controlled hosted resilience is Negative: the strongest legal evidence contradicts an assumption of normal continuity, and the technical evidence does not bridge the gap.

That split is more useful than declaring the network simply alive or dead. A customer does not buy an ASN. It buys a recoverable service. Until MARITIK's present operator can connect legal authority, physical assets, paid supplier contracts, support labour and portable customer data, the live route should be treated as a narrow observation, not a promise.