SiS Distribution Thailand Public Company Limited descr: @Genesis Data Center has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• SiS Distribution (Thailand) is a listed technology distributor that also sells cloud infrastructure, backup, recovery and managed services. Its current cloud site says those services use two Thai data centres, Interlink IDC and Genesis Data Center, connected by high-speed fibre.
• The Genesis name is historical. The facility opened in 2018 under a venture owned equally by Interlink Telecom, Advanced Information Technology and WHA. Etix Everywhere acquired 67 per cent in 2022; Interlink sold the remaining 33.33 per cent in December 2024. The site is now marketed as ETIX Bangkok #1, so SiS should be treated as a cloud operator or customer inside a third-party facility, not as its owner.
• AS135381, whose APNIC description names SiS and Genesis Data Center, was visibly active on 12 July 2026. RIPE observations showed 24 IPv4 prefixes, four IPv6 prefixes and three adjacent networks. Separate interconnection records place two 10 Gbps BKNIX ports for the ASN at ETIX Bangkok #1.
• That routing footprint is strong evidence of an operating network surface. It does not disclose SiS rack count, server utilisation, storage headroom, utility allocation, generator runtime, cooling margin, fibre-route separation, customer workload placement or tested recovery time.
• The evidence grade is Medium. Public records support a real, current SiS network at the renamed facility, but the capacity and resilience sold to customers remain less transparent than the network's existence.

The awkward name contains an important clue

The phrase attached to this company looks like a piece of network shorthand because that is what it is. The APNIC record for AS135381 calls the network SIS-AS-AP, identifies SiS Distribution (Thailand) Public Company Limited as the organisation, and includes the description (@Genesis Data Center). The number was registered in March 2020 and the record was last changed in September 2023. Its administrative and route-maintenance contacts point to Symphony Communication, one of the networks visible upstream from SiS.

This is more useful than a loose claim that SiS is "in the cloud", but it must be read precisely. An autonomous system number identifies a routing policy and administrative domain. It is not a deed to a building, a power contract, a rack inventory or proof that every service sold under the SiS Cloud name uses the same site. The Genesis note locates an important network context. It does not turn SiS into the owner of Genesis, nor does it reveal which customer virtual machines sit behind the announced addresses.

The clue is nevertheless current. The RIPE routing-status observation for 12 July 2026 found 24 IPv4 prefixes, covering 6,144 addresses, and four IPv6 /48 announcements. All full-feed RIPE collectors in that observation saw the routes. The announced-prefix list included address space associated in public allocation descriptions with several Thai connectivity providers, while the neighbour view showed AS132280 Symphony Communication, AS4618 Internet Thailand and AS4750 CS LoxInfo on the upstream side of observed paths.

Those are not the signs of a dormant reservation. IPinfo's AS135381 view independently classifies it as a hosting network, reports the same broad address scale and lists responsive addresses observed from Bangkok. BGP.Tools also records 24 IPv4 and four IPv6 prefixes, with valid route-origin authorisation for the displayed routes. It associates two dual-stack 10 Gbps exchange attachments with BKNIX at ETIX Bangkok #1.

The network evidence therefore deserves more weight than the entity's peculiar name might suggest. The difficult question is no longer whether something routes. It is what that routed surface tells a buyer about the cloud service beneath it. Public BGP can show reachability, path adjacency and change over time. It cannot show CPU contention, storage latency, backup integrity, a failed transfer switch, diesel in a tank or the amount of spare capacity available when a cooling unit is under maintenance.

SiS is the service seller, not the building owner

SiS is a substantial Thai public company, but its centre of gravity is distribution. The Stock Exchange of Thailand factsheet describes a wholesaler of computers, software, peripherals, smartphones and office-automation equipment, representing a long list of technology manufacturers. It gives the company's Bangkok headquarters and records a 2004 listing. The company's own history traces operations to 1999 and the public-company conversion to 2004.

Cloud services extend that distribution business rather than replacing it. SiS can combine hardware and software relationships, a reseller channel, technical support and rented facility capacity into a local infrastructure service. Its current cloud-services site offers virtual infrastructure, backup, disaster recovery and managed support. A shared-responsibility explanation says SiS manages the layers from the hypervisor down to the data-centre physical security for its Data Center on Cloud service, while the customer manages the guest operating system, updates and applications.

That statement describes customer accountability. It does not mean SiS owns the concrete, switchgear or chillers. A cloud provider can be contractually responsible to its customer for a facility layer that is physically operated by another company. In that arrangement, SiS must select the host, buy enough protected power and connectivity, monitor performance, escalate incidents and translate the host's maintenance and failure terms into its own service commitment.

The 2018 launch account made this boundary relatively clear. It described SiS joining Interlink Telecom to introduce SiS Cloud Services on two Interlink data centres, Interlink IDC and Genesis Data Center. The offer targeted property, retail, insurance, government and independent software vendors, with more than 30 organisational customers reported at launch. It also said both sites were connected by high-speed fibre and supported backup and recovery if the primary site was damaged.

The public wording sometimes slides from "the data centre we use" to "our data centre", a common marketing compression. The legal and investment history resolves the ambiguity. SiS was the cloud-service provider. Genesis was a separate facility venture. Customers evaluating SiS should therefore ask for two linked assurance packages: one covering the host facility and one covering SiS equipment, network, software, staffing and recovery procedures inside it.

Genesis changed identity and control

Genesis Data Center opened in 2018 as a collaboration among Interlink Telecom, Advanced Information Technology and WHA Corporation. Interlink's company history says the venture had registered capital of 210 million baht, with each party holding 33.33 per cent. It described more than 1,038 racks of service area and said more than 30 per cent was in service at the time. It also referred to Tier III design and constructed-facility certification.

That 1,038-rack figure is best understood as a build-out or service-area ambition, not a verified count of powered SiS racks. In January 2022, Data Center Dynamics reported that Etix Everywhere bought the 67 per cent held by AIT and WHA. The report described the live site in Bang Chalong, near Bangkok, as having 2.4 MW of capacity, and said it was renamed ETIX Bangkok #1. Other transaction material distinguished 600 kW of installed IT capacity at acquisition from a 2.4 MW expansion target. The terms were measuring different stages, and that difference matters.

Interlink retained one-third until late 2024. Its audited 2024 financial statements say the board approved disposal of the 33.33 per cent stake on 8 November and completed the sale to an unrelated French company on 19 December. The statements also say the joint venture changed its name to ETIX ITEL Bangkok 1 Co., Ltd. on 20 December. Interlink's 2024 annual account presents the divestment as a decision to concentrate on connectivity and cloud implementation.

The consequence is simple but easy to miss. As of the publication date, old SiS language still names Genesis and Interlink IDC, while the former Genesis building is marketed and controlled as ETIX Bangkok #1. A historical service page may remain operationally accurate if SiS continued to occupy the same rooms under amended contracts. It may also conceal changes in the contracting chain, cross-connect ordering, remote-hands responsibility, maintenance notification, insurance or exit rights.

None of that implies a service failure. Ownership transitions are normal in the data-centre market. They become an availability issue when responsibilities are assumed rather than re-documented. A current SiS customer should know which legal entity invoices or hosts the space, who can approve emergency work, which party owns the rack equipment, whether the service survived the transfer without redesign, and what happens if the facility contract ends.

The network offers a useful bridge across the name change. BGP.Tools locates two BKNIX ports for AS135381 at ETIX Bangkok #1 in current data. That suggests the SiS routing presence remained at the site after the Etix transactions. It does not reveal whether all compute stayed there, whether a secondary site remained ready, or whether the two exchange ports and transit circuits are part of the same customer service.

Capacity claims have to be put on one timeline

Several public capacity numbers surround the facility: 1,038 racks, 600 kW, 2.4 MW, 4 MW, 4.7 MW, 5 MW, 850 racks and more than 1,000 racks. They are not necessarily contradictory. They may describe different dates, modules, physical fit-out assumptions, sold area or electrical boundaries. They cannot responsibly be added together or treated as interchangeable.

The original Interlink account used 1,038 racks as total service area and said over 30 per cent was serving customers. Transaction reporting around the 2022 acquisition described 600 kW installed and a route to 2.4 MW. An Etix release about expansion said a 2023 investment added a module with 400 racks and 1,500 kW of IT capacity. A September 2024 BKNIX point-of-presence announcement described 4 MW of IT capacity and more than 1,000 racks. Current Etix Bangkok facility marketing lists 5 MW and 850 racks for BKK1.

These figures show continuing investment at the host site. They do not state SiS's share. A 5 MW building can contain only a modest SiS deployment. An 850-rack layout can deliver more useful compute than a 1,038-rack layout if cabinets are denser, but only if the cooling and power design supports that density. A rack count without average and maximum kilowatts says little about computing capacity. A megawatt figure without a definition of delivered IT load can include planned modules or exclude conversion and cooling losses.

Installed capacity is also not the same as customer-available capacity. Some power must remain as redundancy margin. Some cabinets may be reserved, incomplete or constrained by cooling. A module can be energised but waiting for network equipment. A cloud cluster can have electrical headroom while storage or licensing is exhausted. The amount SiS can safely sell is the minimum remaining headroom across servers, memory, storage performance, rack power, cooling, switching, security devices and upstream bandwidth, calculated again after one required component has failed.

That last phrase is the important one. A provider may have 100 units available in normal conditions and only 20 after one power train or storage node is removed. Selling 90 would look efficient until maintenance or failure arrives. Capacity should therefore be reported in normal and degraded states. For SiS, a useful disclosure would show allocated and used compute, storage and network capacity at each site, then show the same measures with the largest relevant component unavailable.

Public material provides no such schedule. The current Flex Cloud offer is evidence that SiS still actively sells infrastructure, including high-availability claims, onsite and offsite backup copies and 24-hour support. It is not evidence of the remaining inventory at Genesis/ETIX Bangkok #1. Package sizes tell a buyer what can be ordered, not how many packages the platform can sustain during a fault.

Power resilience has three separate owners

Power assurance for this service spans the utility, the facility and SiS. At facility level, Etix publishes unusually specific claims. Its technical page for Bangkok #1 says the site has 7,000 kVA of incoming power to deliver 4,000 kW of IT capacity, two diverse substations and two diverse power cable routes, 2N UPS and switchboards, and N+1 generator sets. These are operator statements, and the 4 MW on that page should be reconciled with the 5 MW on newer Etix pages.

At SiS level, the unanswered question is how much of that topology reaches each critical device. Two utility routes do not help a server connected through one rack power strip. A 2N UPS system does not make a single-corded firewall fault tolerant. An N+1 generator fleet can still be weakened by a shared fuel system, controls, maintenance state or a contract that allocates less protected load to a tenant than the building headline suggests.

The proof should begin with a current one-line electrical diagram extending from facility handoff to SiS equipment. It should identify A and B feeds, cabinet power-distribution units, dual-corded devices and transfer arrangements for anything with one power input. It should give normal load and degraded-state load by feed. It should show that management, monitoring and console equipment remains powered when the production path it supervises is removed.

Generator endurance is another missing number. A claim of N+1 says that one generating unit can be unavailable while the required load is served, assuming the design and load figures are accurate. It does not say how many hours the site can operate, how quickly fuel is replenished during a regional disruption, whether fuel quality is tested, or whether pumps and controls have redundant supplies. Customers need the tested runtime at a defined load, the refill assumptions and the date and result of the latest full-path transfer test.

The Thailand Board of Investment's 2025 guide is useful as a national benchmark, not as proof of SiS compliance. Its data-centre conditions call for continuous-rated generation able to support the whole electrical requirement, backup generation if one unit fails, UPS and cooling backup, independent distribution paths, efficient air conditioning, whole-area fire protection and 24-hour security. Its cloud-service conditions also contemplate at least two ISO/IEC 27001-certified Thai data centres and primary and backup links of at least 10 Gbps between them.

Those conditions expose what a serious two-site claim should contain. SiS says it uses two sites and high-speed fibre, but its public material does not give the current inter-site speed, route diversity, reserve capacity or power allocation. A customer should not assume that a facility's investment promotion, certification or electrical design automatically certifies the tenant cloud architecture.

Thailand's rapid data-centre growth adds a wider constraint. A National Energy Policy Council account discussed a 2,000 MW direct renewable-power pilot and cited around 1,700 MW of demand among eight large data-centre investors considering or pursuing Thai projects. That does not indicate a shortage at ETIX Bangkok #1. It does show why an old nameplate capacity cannot settle a current power question. Grid connection, contracted supply, expansion timing and clean-energy procurement now affect how quickly marketed space can become usable IT load.

Cooling claims need the same degraded-state test

Etix says Bangkok #1 uses an N+2 cooling design, air-handling units and fan walls, hot corridors and no raised floor. It gives a water-use figure below 0.01 litre per kilowatt-hour and a 1.35 power-usage effectiveness figure for module three. These claims describe a modern air-cooled design and, if measured consistently, an efficient one. They still do not show the thermal conditions of the SiS racks.

Cooling availability depends on where equipment sits, how dense it is and what happens after components are taken out. The average hall can be within limits while one cabinet has a hot inlet. A module may be N+2 at its design load but have less margin after denser equipment is installed. Air handling can remain available while a control fault, blocked path, fan failure or poor containment raises local temperature.

The relevant customer evidence is measured, not adjectival. SiS should be able to provide inlet temperatures and humidity for its cabinets, alert thresholds, sensor coverage, response times and trend data across hot periods. It should state the maximum supported rack density and the density actually installed. It should also provide a cooling-failure exercise showing how long equipment remains within limits after the largest expected cooling loss and what automatic workload or power actions occur if temperature continues to rise.

The expansion history makes this more important. A facility that grows from 600 kW to several megawatts changes the interaction among modules, electrical plant, airflow, controls and maintenance. New capacity may be better than the original rooms, but "same campus" does not mean identical design. If SiS equipment spans old and new modules, the customer needs to know which specification applies to each cluster. If it remains in the original module, a new 5 MW campus headline may have little bearing on its cooling envelope.

PUE is likewise not an availability guarantee. It is a ratio of total facility energy to IT energy over a stated boundary and period. A low PUE can reflect efficient operation, but it does not show whether a backup fan starts, whether a sensor is calibrated or whether the service survives a maintenance overlap. Efficiency and resilience can reinforce each other through modern equipment, yet each needs its own evidence.

Three upstreams and an exchange are meaningful, but not sufficient

The carrier picture is the strongest part of the public case. RIPE observed three adjacent networks for AS135381 on 12 July 2026. Symphony and Internet Thailand appeared for both IPv4 and IPv6; CS LoxInfo appeared on the IPv6 side of the observation. BGP.Tools and Hurricane Electric's BGP view report the same three providers and list the route set. That gives SiS more than a single visible path to the public internet.

The exchange evidence is more specific still. Euro-IX's BKNIX entity record lists AS135381 with two IPv4 and two IPv6 exchange addresses. BGP.Tools labels both attachments as 10 Gbps and locates them on separate BKNIX devices at ETIX Bangkok #1. The facility operator says BKNIX chose the site as its sixth point of presence and that four redundant fibre paths reach the building.

This is solid evidence of interconnection opportunity and likely physical presence. It is not a complete diversity map. Two 10 Gbps ports can terminate on two exchange switches but still pass through one SiS router, one optical shelf or one building meet-me room. Three upstream names can lease underlying fibre from the same carrier or share a duct outside the campus. IPv4 and IPv6 can have different failure behaviour, as the third observed adjacency already suggests. An exchange port can be provisioned while traffic policy leaves most external reachability dependent on paid transit.

The facility's current technical page claims four diverse points of entry and two redundant meet-me rooms. A customer should ask which of those SiS actually uses. The answer should name each carrier, physical entry, meet-me room, cross-connect, edge router and capacity commitment. It should show whether routes are accepted and advertised on both sides, and whether either side alone can carry peak demand plus recovery traffic.

BKNIX's route-server filtering policy says its default mode checks internet-routing records and route-origin authorisation, along with prefix length, next hop and peer ASN. The valid origin status reported for the SiS prefixes is good routing hygiene. Route-origin validation protects against some erroneous or unauthorised origins. It does not establish path diversity, prevent every leak, detect an overloaded circuit or guarantee that a customer's application is healthy.

There is also no public SiS entry in PeeringDB. That absence is not a fault; many networks do not maintain one. It limits the amount of operator-declared information available about policy, traffic scale and facility presence. In this case, BKNIX and routing observations provide stronger location evidence than a generic directory listing would, but a current SiS network map would still resolve important ambiguity.

The practical test is a controlled withdrawal. SiS should demonstrate loss of each transit circuit, exchange port and edge router while measuring packet loss, route convergence and application response. The test should be repeated during the busiest relevant period or with equivalent synthetic load. A list of carrier logos is only an inventory; a withdrawal result shows whether the design works.

The two-site promise needs geography, capacity and a clock

SiS's current general-information FAQ still says its cloud service operates from Interlink IDC and Genesis Data Center, offers a 99.90 per cent monthly uptime commitment and provides 24-hour technical support. Its main cloud page says the sites are linked by high-speed fibre and can support backup and recovery when the primary location is damaged.

That is a meaningful architecture claim, but not yet a recovery plan. Two site names do not reveal the distance between them, flood and utility correlation, fibre route or which workloads are duplicated. "Backup" can mean an offsite copy that takes hours or days to restore. "Disaster recovery" can mean a prepared virtual environment. It can also mean active capacity with near-real-time replication. Each has a different cost and outage outcome.

The SiS service-scope document says the 99.90 per cent monthly commitment covers the data centre, the network within it and relevant equipment and software. At 99.90 per cent, a 30-day month permits about 43 minutes and 49 seconds outside the promised availability before exclusions and measurement rules are considered. That is much less demanding than Etix's marketing of availability up to 99.995 per cent, which would imply about two minutes and 11 seconds in the same month. The numbers apply to different services and must not be blended.

The customer needs the actual service definition: what endpoint is measured, from where, at what interval, and which planned maintenance or external dependencies are excluded. A service credit is financial compensation, not restoration. It may be small compared with the cost of an ERP, payment or public-service outage. The contract should therefore pair the availability percentage with a recovery-time objective, recovery-point objective, escalation timetable and tested procedure.

Capacity at the recovery site is often the hidden limitation. If every primary workload is replicated but only a fraction can run simultaneously at the second site, the service has backup copies rather than full failover. SiS should disclose whether secondary compute and storage are dedicated, reserved or obtained on demand. It should show network headroom for replication during ordinary operation and for user traffic after failover. It should also explain priority if several customers invoke recovery after the same regional event.

Fibre between the sites must be tested as two paths, not described as one fast link. The diagram should show separate ducts, carriers and building entries where claimed. If two logical circuits share one bridge, road crossing or carrier backbone, a civil-works incident can remove both. Encryption, replication lag and failure detection also matter. A link can remain technically up while delay or packet loss makes synchronous replication unsafe.

Most importantly, SiS should publish or provide a recent customer-level exercise. It should record the trigger, workloads moved, data loss observed, time to service, peak link use, manual steps, failed steps and return to the primary site. The customer testimonials offer useful signs that enterprises have run ERP-related workloads on SiS Cloud and valued its support. Testimonials cannot replace measured failover evidence because they do not define the failure tested or the recovery achieved.

Maintenance is where separate redundancies meet

The most revealing availability test is often not a disaster but planned work. A facility can be designed for concurrent maintenance, a cloud cluster can have spare nodes, and a network can have multiple carriers, yet the service can still become fragile when maintenance occurs in two layers at once.

Consider a generator unavailable for service while one utility route trips. Or a storage node being rebuilt while a rack power feed is transferred. Or one transit circuit under maintenance when an exchange router reloads. Each layer may remain within its own stated redundancy, but their overlap can leave the customer without a complete path from electricity to application.

The old Genesis certification claims help frame the question but do not settle it. Uptime Institute distinguishes design-document certification, constructed-facility certification and operational sustainability. Its Tier overview defines Tier III around concurrent maintainability and Tier IV around fault tolerance. A certification belongs to a named scope and time; it does not automatically certify SiS servers, network architecture or operating practice. The current Thailand awards page should be used to verify the current project name and award scope rather than relying on a historical badge.

The ownership and expansion changes create additional maintenance boundaries. Etix operates the site, BKNIX operates exchange equipment, carriers operate fibre and SiS operates its cloud stack. Each can schedule work. Customers need to know who coordinates the calendar and which party can veto an unsafe overlap. They also need proof that notification from the facility reaches SiS and then reaches affected customers with enough time to act.

A mature change record would show risk, rollback, dependencies and observed result for each significant maintenance window. Repeated near misses are useful evidence if they lead to correction. Silence is not evidence that maintenance has always been harmless. The strongest assurance is a history of planned removals completed while customer service stayed within defined limits.

Fire, flood and control failures cross the contract boundary

Etix says Bangkok #1 has very early smoke detection, double detection through building volumes, inert-gas suppression and 24-hour monitoring. Those are relevant controls. A customer still needs to know whether SiS cabinets are in the protected scope, whether shutdown logic protects equipment, how staff re-enter after discharge and how data is recovered if a room remains inaccessible.

Fire resilience is not only suppression. It includes cable segregation, battery and electrical fault detection, compartmentation, emergency power-off design and a remote operating path. A localised event can spare servers but remove both network paths if cross-connects share the affected room. It can also preserve customer data while preventing access long enough to breach recovery targets.

Flood exposure deserves equally precise treatment because the site is in Bang Chalong, Samut Prakan. The World Bank's assessment of Thailand's 2011 floods emphasised the need for hazard mapping, retention, forecasting and early warning after a nationally severe event. That history does not prove ETIX Bangkok #1 is flood-prone or that it has ever flooded. It establishes that regional flood planning, access and utility continuity are reasonable diligence questions.

The facility package should show site elevation, design flood level, drainage, barriers, pump redundancy, location of fuel and switchgear, and access plans if surrounding roads are impassable. The recovery design should show whether Interlink IDC shares the same weather, utility or transport exposure. Two sites can be far enough apart for a building fire but too correlated for a regional flood or grid event.

Control systems create another shared failure path. A building-management fault can affect cooling commands. A cloud control-plane problem can prevent recovery even while virtual machines continue running. An identity or network-management outage can lock operators out of the equipment needed for repair. Out-of-band access, offline procedures and privileged-access recovery should therefore be included in resilience tests.

No public evidence reviewed here identifies a SiS outage caused by fire, flood, power, cooling or carrier failure at the facility. These are failure paths to test, not incidents to attribute. That distinction matters. Serious diligence examines plausible mechanisms without converting them into allegations.

Who bears the impact

SiS launched the service for sectors that feel infrastructure failure quickly: property groups with distributed sites, retailers, insurers, government bodies and software vendors. Its current offers include virtual infrastructure, managed security, backup, disaster recovery and application-related services. An outage can therefore affect much more than a public website.

An ERP interruption can stop orders, inventory changes and invoicing. A retailer can lose branch connectivity or central data access. An insurer can lose claims and policy processes. A software vendor can pass the outage to many client organisations. A government workload can delay services whose users have no contractual relationship with SiS. If backup and production share a failure domain, a ransomware or storage event can turn an availability problem into a recovery crisis.

The broad AS135381 route set also means network failure may not look uniform. A lost upstream can affect some destinations more than others. IPv6 can behave differently from IPv4. Private MPLS access, site-to-site VPN and public internet access can follow different providers. SiS's Data Center on Cloud FAQ says customers may connect by SSL VPN, site-to-site VPN or private MPLS. Each method needs its own failure and recovery result.

Customers should map business services to technical dependencies rather than asking for one uptime percentage. Which applications require continuous operation? Which can wait for restore? Where are identity, DNS, keys and backups? Does the customer office have a diverse path to both data centres? Can staff work if the SiS management surface is unavailable? The answers determine whether facility redundancy produces business continuity.

What would move the evidence grade higher

The public case reaches Medium because multiple independent observations agree on the core fact: SiS has a live, well-visible routed network associated with the former Genesis site, and current exchange data places substantial BKNIX attachments at ETIX Bangkok #1. Current SiS pages also continue to sell cloud and two-site recovery services. This is far more than a name without operations.

Moving to Strong requires evidence that joins the layers. First, SiS should identify its current contracted host and exact service locations, acknowledging the Genesis-to-ETIX name and ownership transition. Second, it should provide current installed, used and degraded-state capacity for compute, storage, rack power and connectivity at each site. Third, it should map A/B power, cooling zones, carriers, entries, meet-me rooms, edge routers and inter-site fibre to the customer service.

Fourth, the provider should supply recent test results: utility-to-generator transfer, loss of a power feed, cooling component removal, transit withdrawal, exchange-port failure, edge-router failure, storage-node failure and full site failover. The results should include timestamps, packet loss, replication lag, workload recovery, exceptions and corrective action. Fifth, the contract should align the measured endpoint, exclusions, recovery time, recovery point, support escalation and service credits.

Facility documents should be current and named. Certification should specify holder, site, module, award type and validity. Capacity should specify whether it is designed, installed, energised, sold, available or recoverable after a fault. Carrier diversity should specify physical route, not only provider count. Sustainability claims should specify measurement boundary and period. These definitions turn reassuring nouns into testable commitments.

The answer may be good. Etix publishes credible ingredients: separate power routes, redundant electrical and cooling systems, multiple fibre entries, redundant meet-me rooms and an exchange point. SiS has a multihomed, dual-stack network and a long-running cloud offer. The missing part is not necessarily infrastructure. It is public evidence that SiS bought, configured and tested enough of those ingredients for its own service.

The decisive question is what survives together

This company should not be judged by the odd wording of an internet-number description, nor should it receive the full benefit of every number advertised for the host campus. The responsible position sits between those extremes.

The active routes show that AS135381 is real and current. The BKNIX attachments place meaningful SiS connectivity at ETIX Bangkok #1. The cloud site shows a continuing service with two named locations and a monthly availability promise. The host facility's expansion shows that the physical platform has grown beyond the original Genesis venture.

But a customer does not consume an ASN, a rack headline or a campus megawatt. It consumes a chain: utility supply, generators, switchgear, cooling, cabinet power, servers, storage, edge routers, cross-connects, carriers, inter-site replication, support and recovery authority. Availability is set by the weakest part of that chain and by the way failures overlap.

SiS Distribution (Thailand) can raise confidence by showing that chain under stress. Until it does, marketed capacity should be treated as host-site potential, and the live routing footprint as evidence of network operation, not proof of recoverable customer capacity. The present evidence supports a functioning service surface. It stops short of proving that the surface remains intact when power, cooling, carrier access or an entire site is removed.