Sempernet's AS45444 disappeared from RIPE's BGP view in 2021; its websites now use AS63949-originated addresses

Summary

• AS45444 remains registered to Twin-K Computers Pty Ltd, and its abuse contact was validated in June 2026. Registration is current; routing is not. RIPE RIS saw no announced IPv4 or IPv6 space, no neighbours and no route for the autonomous system on 15 July 2026.
• The last globally visible origins associated with AS45444 were the 116.197.144.0/21 IPv4 block and 2406:a000::/32 IPv6 block in early 2021. Those allocations remain active in APNIC records, but allocated addresses are not evidence of powered servers, sellable hosting or reachable service.
• Sempernet and Coherent Cloud are both registered business names of Twin-K Computers. Public filings do not establish Sempernet as a separate legal subsidiary, despite that wording in the historical autonomous-system description.
• Coherent Cloud, Studentnet and Cloudwork still expose products, support and a status page, but their observed public web addresses fall within prefixes originated by AS63949. APNIC names that ASN AKAMAI-LINODE-AP and identifies Akamai Technologies as its registrant; those registry facts do not locate or identify any website server, backend, Cloudwork workload or data.

The silence is in the route table, not on the company website

At 08:00 UTC on 15 July 2026, RIPE's routing collectors were listening through 326 IPv4 peers and 322 IPv6 peers for AS45444. None saw it. The RIPEstat routing-status record counted zero announced prefixes, zero announced addresses, zero observed neighbours and zero peers seeing the autonomous system in either protocol. The companion BGP-state response returned an empty route set.

At almost the same moment, the public-facing business looked alive. Studentnet's homepage promoted a June 2026 webinar about student identity verification, described technical support from local professionals and said Cloudwork was in use at Australian schools. Its status page displayed "All Systems Operational" and a visible 90-day component at 100 per cent uptime. Coherent Cloud's site carried a 2026 copyright line, an Australian telephone number and the same Twin-K Computers ABN that appears in the government register.

Both observations can be true. A business can continue to deliver an application after retiring its own route origin. It can rent virtual machines from another provider, put services behind a third-party network, migrate workloads while retaining old number resources, or leave an autonomous-system registration in place for possible future use. The important error would be to treat the live application page as proof that AS45444 is carrying it, or to treat the dark ASN as proof that the company has ceased trading.

Sempernet's infrastructure question is therefore not simply whether the organisation exists. It does. The question is what remains of the network described in its registry entries, which physical and contractual layers now carry the school identity service, and how much usable capacity survives a provider, rack, power, network or recovery failure. Public evidence is unusually good at showing the gap and unusually weak at filling it.

The name in the ASN is not a reliable corporate chart

The entity label "Sempernet subsidiary of Coherent Cloud" comes directly from the APNIC record for AS45444. It names the autonomous system SEMPERNET-AS-AU, describes it as a network service provider in Sydney and lists websites for Sempernet, Coherent Cloud and Studentnet. The registrant, however, is not a company called Sempernet or Coherent Cloud. It is Twin-K Computers Pty Ltd.

The Australian government's ABN history for Twin-K Computers makes the legal boundary clearer. ABN 90 001 966 892 belongs to an active Australian private company. Sempernet, Coherent Cloud, PPS Internet, PPS Technology, Student Net and Isonet are listed as current business names under that same entity. Sempernet is shown from 14 March 2000 and Coherent Cloud from 21 January 2014. The record does not identify one business name as a corporate parent of another.

That does not prohibit Twin-K from organising its brands internally in a hierarchy. Coherent Cloud calls itself the "parent body" of Cloudwork and Studentnet, and the Studentnet about page calls Studentnet a wholly owned subsidiary of Twin-K. Those are product and brand statements with some corporate context. They do not create a separately filed Sempernet company, and they do not establish a legal shareholding from Coherent Cloud into Sempernet.

This distinction is not pedantry. Contracts, liabilities, number resources, software rights and data-processing duties attach to legal persons. A customer reading the ASN label might assume a company named Coherent Cloud owns a separate subsidiary named Sempernet. The public government record instead points to one legal company using several names. Unless a current contract or corporate filing demonstrates otherwise, the defensible owner and accountable resource holder is Twin-K Computers Pty Ltd.

The addresses also need separation. APNIC still carries Suite 1, 89 Jones Street in Ultimo as the organisation and contact address. Coherent Cloud publishes the same address. The ABN record says Twin-K's main business location changed from NSW 2007 to NSW 2065 in May 2024, and Studentnet's contact page gives a postal address at 2 Herbert Street, St Leonards NSW 2065. None of these office or contact details is proof of a server room. They are evidence of administrative presence and address drift, not equipment ownership.

What the registered network was built to do

APNIC's address records describe a more concrete historical operation than the current route table. The 116.197.144.0/21 allocation is registered to Twin-K under the SEMPERNET name. Its description calls the resource a web-server colocation and hosting network combined with custom managed services for Australian corporations and businesses. A /21 contains 2,048 IPv4 addresses before normal network reservations or operational choices are considered.

The 2406:a000::/32 IPv6 allocation describes a production IPv6 network serving commercial and education clients in Australia. It is also registered to Twin-K. Both allocations are marked active in the registry, both date from 2008, and both retain an abuse contact validated on 17 June 2026. The autonomous system itself was registered in September 2008.

These records establish historical intent and continuing resource accountability. They do not establish present utilisation. An RIR status of active means the registration is not marked returned, revoked or otherwise inactive in that database. It does not mean a BGP route is being propagated, a rack is powered, a customer can place an order, or a packet can reach an application. The fresh abuse-contact validation is useful evidence that someone still responds to the resource-maintenance process. It is not a service-health test.

The old routing policy also named three external autonomous systems. AS45444's APNIC entity declared imports from and exports to AS7543, AS18398 and AS2914. In a live network those policies could describe several upstream relationships. Here they are a configuration declaration last modified in 2020, not a current observation. RIPE RIS saw no neighbour at the review time. A declared import line can remain in an internet routing registry long after the session, cross-connect or transit contract behind it has ended.

One residual route object is especially easy to misread. APNIC's IPv4 query contains a 116.197.144.0/22 route object naming AS2914 as origin, updated in April 2023. Yet RIPEstat's current prefix overview says that /22 is not announced, and its BGP-state view finds no path. A route object is a policy authorization or documentation record. It is not a live advertisement. The same caution applies to the old AS45444 policy: paperwork can outlast packets.

The 2021 withdrawal is the operating boundary

The historical route record provides a much stronger date than general statements about an old website or old facility. RIPEstat's routing-history data shows the 116.197.144.0/21 IPv4 aggregate visible from 30 April 2009 through 1 February 2021. The 2406:a000::/32 IPv6 origin was visible from February 2009 to the same end date. Several more-specific IPv4 routes appeared for shorter periods around 2009 and 2010.

The current routing-status view identifies the last-seen event as 116.197.144.0/21 originated by AS45444 on 27 January 2021. The slight difference between that event timestamp and the history interval's end reflects the way the two RIPEstat datasets summarise collector observations. It does not support precision about the hour of withdrawal. The robust conclusion is that the globally observed origin ended in early 2021 and has not returned in the current dataset.

Cloudflare's routing view for AS45444 also identifies the network as SEMPERNET-AS-AU and CoClo, but it presents no current prefix list in the public summary. IPinfo separately classifies the ASN as inactive and reports no prefixes, peers or upstreams. Those commercial summaries are secondary checks. RIPE RIS supplies the measurement that should carry the conclusion.

This is negative evidence with a defined scope. RIS is a large observation system, not every router on earth. It can establish that no route was visible to its hundreds of collectors at the stated time. It cannot rule out an internal private network, a service reached through a different origin ASN, a VPN, a customer-specific route, or equipment kept offline for future reactivation. It also cannot explain why the routes disappeared. No public decommissioning notice, migration announcement, sale record or incident report found in this review gives a cause.

For a customer, however, the external effect is plain. Addresses inside the registered Sempernet blocks were not globally reachable through AS45444 at the cut-off. Any current public service using a different provider has a different routing, facility and support dependency than the historical ASN description implies. Due diligence must follow the current service endpoints rather than stop at the old number-resource record.

Registered address space is not usable hosting capacity

The IPv4 and IPv6 holdings can sound like capacity. They are address scope. The /21 provides 2,048 IPv4 addresses. The /32 provides an enormous IPv6 allocation intended for hierarchical subnetting. Neither number says how many servers exist, how many virtual machines can be placed, how much memory or storage is installed, how many customer identities are processed, or what throughput is available in a failure condition.

The PeeringDB profile for AS45444 adds an old self-reported operating scale. It labels the network CoClo (Coherent Cloud), lists Sempernet, Studentnet, Isonet and PPS Internet as alternate names, classifies it as a content network, and reports eight IPv4 prefixes, no IPv6 prefixes, traffic of 20-100 Mbps, heavy outbound ratio and Asia-Pacific scope. The network profile was last updated in July 2022.

Those fields are not current metering. The "eight prefixes" entry does not match a present route table with zero origins. It may describe an earlier arrangement, count more-specific announcements, or simply be a profile value that was not corrected after withdrawal. The 20-100 Mbps band is broad, old and self-selected. It is not a committed information rate, a 95th-percentile bill, a port speed or a guarantee of spare capacity.

No public product catalogue found here sells a Sempernet virtual private server, bare-metal host, colocation cabinet, transit circuit or storage tier. There is no server count, rack-unit inventory, CPU and RAM pool, disk capacity, network commit, customer allocation, utilisation graph, waiting list, hardware stock or price. There is also no split between designed, installed, powered, operational, sold, reserved and actually available capacity.

The honest capacity statement is therefore austere. Twin-K retains registered internet number resources with historical hosting descriptions. AS45444 currently makes none of those resources globally visible. Coherent Cloud markets an identity-management application, but its public materials do not disclose the compute and storage units behind it. Capacity cannot be calculated from either the address allocation or the PeeringDB profile.

One old Sydney facility association cannot locate today's service

PeeringDB associates AS45444 with one facility: DigiCo Sydney SYD1, formerly Global Switch Australia, at 400 Harris Street in Ultimo. The network-facility association was created in 2011 and last updated in March 2016. AS45444 has no listed internet-exchange attachment. That history is consistent with a customer taking transit inside a carrier-neutral data centre rather than peering publicly at an exchange.

The facility itself is real and current. DigiCo describes a Sydney SYD1 site in its portfolio, with redundant power, cooling, security and round-the-clock on-site operations across its data-centre estate. The facility received Australian government Hosting Certification Framework strategic status in 2025. None of those facility-level claims says AS45444 remains a tenant.

The NSW planning record makes the ownership and capacity boundary even more important. The DigiCo SYD1 expansion application covers an existing data-centre campus at 392-422 Harris Street, two additional levels, conversion of floor space to plant and electrical use, and an increase in power consumption of 47.5 MW. It was approved in December 2025. Engineering material describes an intended 88 MW facility after intensification.

Not one watt of that 47.5 MW increase, nor any fraction of the planned 88 MW, can be assigned to Sempernet. Those are site-development figures for DigiCo. They do not show a Twin-K lease, a cabinet, a cross-connect, a breaker, a reservation or a power bill. A customer network can occupy a small part of a large facility, leave it, or buy a service from another tenant without appearing in planning documents.

The Cloudwork FAQ still says its central Identity Access Manager runs as a single virtual machine on dedicated server hardware at Coherent Cloud's "GlobalSwitch DC". That statement links the application architecture to the former facility name, but the page supplies no date for the paragraph and no rack or contract detail. The use of the old brand after the facility became DigiCo is a reason to seek confirmation, not a reason to assume the hardware disappeared. Current evidence settles the facility's existence; it does not settle Sempernet's current presence inside it.

The visible edge is outside AS45444

The public web layer gives a direct example of addresses reached outside the old network. On 15 July 2026, Google Public DNS returned 173.255.242.216 for coherentcloud.com and coclo.co. It returned 172.105.255.107 for studentnet.net. RIPE's network information maps both covering prefixes to AS63949 rather than AS45444. The APNIC registration for AS63949 names it AKAMAI-LINODE-AP, identifies Akamai Technologies, Inc. as registrant and describes Akamai Connected Cloud. That attribution belongs to the ASN registration, not to any particular website workload.

The DNS response for coherentcloud.com and the network record for its address demonstrate the public-edge chain. The equivalent Studentnet DNS response and network record show the same origin ASN through a different prefix. ARIN's registration records name LINODE for the assignments covering 173.255.242.216 and 172.105.255.107.

Together, those sources establish a DNS-to-address-to-origin-AS chain and the registry names attached to the ASN and address assignments. They do not prove who owns or operates any virtual machine or server, where a backend runs, whether the public site shares infrastructure with Cloudwork, or where any application data is stored. DNS and routing state can also change after the observation.

The domain evidence is nevertheless decisive against one shortcut: neither public website demonstrates AS45444 hosting. Coherent Cloud and PPS Internet resolve to the same external address; coclo.co redirects to coherentcloud.com. Studentnet resolves to another AS63949 prefix. The former Sempernet domain is weaker still: semper.net redirects to a domain-sale page. A parked brand domain is not an operating portal.

There is a protocol difference as well. Studentnet serves a current HTTPS site. The Coherent Cloud host responded over plain HTTP during review and did not negotiate a modern TLS connection with the review client. Its response advertised old Apache and PHP version strings, although server headers can be inaccurate or deliberately fixed. This is a public-edge maintenance signal, not evidence about the protected Cloudwork service and not proof of an exploitable flaw.

Cloudwork is an application dependency, not generic cloud capacity

The live offer is more specific than the assigned category might suggest. Studentnet's product page describes Cloudwork as identity and access management for school communities. It manages students, staff, parents, alumni and visitors, synchronises data from school-management systems, and integrates with more than 110 education applications and services. Modules cover identity control, validation, provisioning, authentication and device integration.

This is not a public infrastructure-as-a-service catalogue. The customer is not selecting arbitrary virtual-machine sizes or bare-metal inventory. It is buying an application and managed support. The infrastructure still matters, but it should be measured in successful identity transactions, directory synchronisation, authentication latency, recovery objectives and supported schools rather than advertised CPU cores alone.

The Cloudwork FAQ describes a two-part architecture. A Cloudwork Identity Node, or CwIN, is a Windows virtual machine deployed at the customer organisation. It contains Cloudwork code and Microsoft ADFS. Coherent Cloud maintains and manages it, while the organisation is responsible for backing up the CwIN image. Coherent Cloud says it keeps configuration files for bare-metal recovery.

The central Cloudwork Identity Access Manager, or CwIM, is described as a single Linux virtual machine on dedicated server hardware at the GlobalSwitch data centre. Studentnet says it backs up that machine and keeps a full recovery copy at an offsite recovery facility. This architecture creates at least three operating surfaces: the school's local or cloud-hosted node, the central manager, and the recovery copy.

Each surface has a different owner and failure path. A school's failure to back up its CwIN image can obstruct local recovery even when Coherent Cloud retains configuration files. A failure of the central manager can affect authentication or management functions shared across customers. A recovery copy can reduce data-loss exposure but only if it is sufficiently current, isolated, compatible and capable of being started with the required network and dependencies. The public description does not provide those test results.

Calling Cloudwork "cloud" therefore does not erase hardware. Its identity service depends on server hosts, storage, operating systems, ADFS, network paths, certificates, DNS, staff and the third-party applications to which it brokers access. The public architecture is useful precisely because it shows responsibility is distributed. It does not turn that responsibility into quantified resilience.

Public status is evidence of service activity, not a topology diagram

The Studentnet status page is one of the strongest current signals that a service operation continues. It exposes a subscription mechanism for incident notifications and, at review time, reported all systems operational. The support page directs users to current system status and incident reports. Those are behaviours of an operating service rather than a dormant brand.

The status page is also self-published. Its green state means the operator had no open issue represented there at that moment. A 100 per cent 90-day display means no downtime was recorded for the visible component under the site's own measurement and incident rules. It does not reveal probe location, transaction depth, customer-specific errors, planned-maintenance treatment or the relationship between a component and AS45444.

Most importantly, the status page does not restore the old network origin. A service monitor can report healthy while the reviewed public website addresses are visible through AS63949. The status page does not disclose the origin network, facilities or paths used by the monitored application transactions, so it cannot turn the PeeringDB association, APNIC import policies or historical Sempernet prefixes into a current dependency map.

The public support page adds a human response path. It offers tickets and email for routine problems and an Operations Centre number for critical or emergency outages outside normal business hours. Genuine outage reports are not charged; non-emergency use of that number can attract an hourly charge. This shows an escalation channel. It does not disclose a staffed roster, response-time objective, restoration target, severity matrix or substitute if the telephone path or named personnel are unavailable.

There is no contradiction between active support and unknown infrastructure. Small managed-service companies often sell expertise and responsiveness while renting physical capacity. The diligence issue is whether a buyer knows the chain of responsibility and has contractual remedies at each layer. Public pages answer who to call. They do not answer how much spare hardware exists or how quickly a failed central host can be rebuilt.

Data locality stops at the words "GlobalSwitch" and "offsite"

Cloudwork processes identity-related information. Studentnet's privacy policy says it uses names, email and contact information to create accounts, authenticates users, logs requests including source IP addresses, encrypts data in transit and at rest, and maintains regular backups for operations and disaster recovery. It says retained personal information is kept only as long as necessary to provide a reliable service.

Those statements describe handling practices, not a complete data map. The FAQ locates the central manager at a Sydney data centre under its former brand. It locates each CwIN at the customer organisation. It describes the recovery copy only as offsite. It does not name the recovery facility, country, legal entity, cloud provider, replication route or storage medium.

The public web edge adds another jurisdictional question. AS63949 is the observed third-party origin for the two website prefixes, and its registration country and resource-holder names do not locate the underlying server. IP geolocation can suggest a region but is not documentary evidence of where disks, backups or administrators sit. A customer needs a current data-processing schedule, subprocessor list and architecture document to establish locality.

Studentnet's security page says its credentials document covers data subprocessors, their purpose, category, location and security measures. A security-credentials PDF dated March 2026 is publicly linked. That is a useful route to more detailed diligence, but a changing vendor list should be read directly in the current contractual pack. A general assertion of Australian ownership and development is not the same as an Australian-only processing commitment.

Data sovereignty also depends on operations. If a recovery copy is outside the primary facility but inside the same metro power or carrier failure domain, it may be geographically separate without being operationally independent. If it is in another jurisdiction, recovery may improve while legal exposure changes. The word "offsite" leaves both possibilities open.

The defensible locality statement is narrow: the company publicly associates its central Cloudwork manager with the Sydney Global Switch/DigiCo facility, places a node at each participating organisation, and says a full manager image exists at an unnamed offsite recovery facility. The present location of the central workload, its public web edge and the recovery copy are not fully reconciled in public evidence.

Logical multi-upstream history is not physical redundancy

AS45444's registry entity declared three external routing relationships. That looks like multi-upstream design. PeeringDB lists a carrier-neutral Sydney facility whose current page names many networks and local exchange fabrics. Together they describe an environment in which diverse transit could have been bought.

They do not prove three disjoint paths. BGP policy names autonomous systems, not conduits. Two carriers can enter through the same building meet-me room, the same street trench, the same cross-connect panel or the same customer router. They can share power, optical transport or an upstream farther away. A third route can improve policy choice while adding no protection against a rack, chassis or local fibre failure.

Today the question is more basic because RIPE RIS observes zero neighbours for AS45444. There is no current logical multi-upstream visibility to analyse for that ASN. The two reviewed website addresses share AS63949 as their observed origin, which establishes a third-party public-edge dependency but no path, facility, power or failover diversity. Their visibility after the old ASN withdrawal is not evidence that the identity platform migrated or that Cloudwork can fail over.

The first-party architecture mentions one central virtual machine on dedicated server hardware. A single VM can be backed up and quickly restored, but it is not inherently highly available. Dedicated hardware can isolate workload from noisy neighbours while still creating a host failure point. The phrase says nothing about a hypervisor cluster, live migration, second active instance, database replication, load balancing, spare server or automatic failover.

Similarly, a recovery image is not operating capacity. It may be cold, warm or hot. It may require new hardware, network changes, DNS updates, certificate restoration and manual validation before customers can authenticate. Without an RTO, RPO, last-test date and measured recovery time, the usable capacity under failure is unknown.

Real redundancy evidence would name the current primary and recovery sites, show independent power and carrier paths, document active versus standby state, disclose the replication interval, and provide the result of a recent failover exercise. None of those facts is available in the public material reviewed here. Multi-upstream and offsite language should remain hypotheses until that evidence is produced.

Power, cooling and hardware sit behind a contractual boundary

Data-centre marketing can make rented infrastructure sound like a customer asset. DigiCo describes redundant power, advanced cooling, physical security, monitoring and on-site teams. The planning record shows an expansion measured in tens of megawatts. These are meaningful attributes of the facility operator's platform.

Sempernet's usable share depends on its contract and deployment. A tenant might have one rack or part of a cabinet, one or two power feeds, a fixed breaker allocation, shared remote hands and cross-connects to selected carriers. It might instead buy a managed server from another tenant. Public sources do not identify the arrangement.

The distinction controls failure behaviour. A facility-wide utility event can be covered by generators, yet a customer can still fail because its rack has one power supply, one distribution unit, one top-of-rack switch or no tested spare. A carrier-neutral building can contain many carriers, yet a customer can buy only one circuit. A site can have available megawatts while a particular hall, breaker or rack has no headroom.

Hardware replacement is equally opaque. There is no published stock of compatible servers, disks, network cards or power supplies for Coherent Cloud. There is no statement of vendor support, lifecycle, patch window or time to replace the dedicated CwIM host. The FAQ's single-VM description and backup claim make these questions material rather than speculative.

The central manager's true capacity is not the data centre's planned MW figure. It is the lower of compute, storage, database, network, software and support constraints for the workload, after reserving enough headroom to absorb a failure or restore. Public material supplies none of those quantities. The only safe value for current sellable or failure-condition capacity is unknown.

Who is affected when the chain breaks

Cloudwork's customers are schools, and the product sits in front of identity-dependent systems. Studentnet says it synchronises school information systems and brokers access to services including Microsoft 365, Google applications, learning platforms, libraries, content tools and administrative systems. A central or local identity failure can therefore propagate beyond one login page.

The impact depends on which layer fails. If a school's CwIN fails but existing application sessions remain valid, already signed-in users may continue while new logins, provisioning or directory changes stall. If the central manager fails, shared authentication and administration functions may be affected across more than one organisation. If DNS, certificate or public network paths fail, users may not reach the authentication endpoint even when the virtual machine is healthy.

A bad synchronisation can be as disruptive as a server outage. Identity systems can create, disable, rename or regroup accounts. Delay can leave new students and staff without access; an incorrect update can remove access from existing users or preserve access that should have ended. Recovery must restore both service and a trustworthy directory state.

Third-party dependency creates another class of failure. Cloudwork may be healthy while Microsoft, Google, an education application, SMS provider or customer directory is not. Conversely, a third-party application may be reachable but reject Cloudwork assertions because of certificate, metadata, clock or policy mismatch. An infrastructure map needs these protocol and administrative edges, not only server addresses.

The users affected include students, teachers, school administrators, IT staff, parents, alumni and visitors. The severity can vary sharply by time: a short interruption during a quiet period is different from an authentication outage at the start of classes, during examinations or while staff are responding to a safety incident. Public evidence does not disclose customer counts, concurrent transaction peaks or critical calendars, so aggregate impact cannot be quantified.

Backup responsibility is divided, and migration remains unclear

The FAQ allocates part of recovery to the customer. Each organisation is responsible for backing up its CwIN virtual-machine image, while Coherent Cloud retains configuration files for bare-metal recovery. That division should be explicit in a contract because configuration files and a complete runnable image are not interchangeable.

If the customer image is missing or stale, Coherent Cloud may be able to rebuild configuration on a clean operating system, but the time and completeness depend on software packages, ADFS state, certificates, secrets, patches and local integrations. If the provider's configuration copy is unavailable, the customer image may still run but be harder to repair or migrate. A recovery exercise must test both halves.

For the central CwIM, Studentnet says it keeps backups and a full offsite image. No public material states the backup frequency, retention period, immutability, encryption key custody, recovery point objective or recovery time objective. The privacy policy says backups are retained only as long as necessary, but does not publish the schedule.

Customer exit is another recovery path. No public document reviewed here explains how a school exports identity configuration, logs, mapping rules and metadata in a provider-neutral form, or how long assistance continues after termination. The terms document identifies Twin-K as the owner of Cloudwork and describes the service relationship, but it does not establish a publicly measurable migration capacity.

Data portability matters because an identity provider is embedded in many application connections. Replacing it can require new SAML metadata, certificates, DNS, device settings, application registrations, directory connectors and user communications. A theoretically available competitor does not create an immediate restore path. The migration time may exceed the time to repair the original service.

The strongest resilience plan would combine tested local-node backups, an independently recoverable central manager, current configuration exports, documented certificate custody and a rehearsed route to temporary authentication. Public evidence shows pieces of that design, not a tested end-to-end result.

What a buyer can believe today

Several facts are strong. Twin-K Computers is an active Australian private company. Sempernet and Coherent Cloud are current business names attached to it. Twin-K remains the registrant of AS45444 and the 116.197.144.0/21 and 2406:a000::/32 resources. The abuse contact was validated in June 2026. Studentnet and Cloudwork expose current product, support and status surfaces.

Several historical facts are also strong. AS45444 originated the IPv4 and IPv6 aggregates for roughly twelve years. Its records describe Sydney hosting and managed services. PeeringDB associated it with the former Global Switch Sydney facility. The network stopped appearing in RIPE's global collectors in early 2021.

The current physical facts are weak. No source identifies a present Sempernet rack, cabinet, server, cross-connect, power allocation or facility contract. The Cloudwork FAQ names the former Global Switch site for one central VM, but does not date or independently corroborate the deployment. DigiCo's facility expansion proves that the building operates and is growing, not that Twin-K occupies it.

The current route facts are negative. AS45444 has no visible prefix or neighbour in the observation. Its old address blocks are not announced, including the /22 with a later AS2914 route object. The reviewed Coherent Cloud and Studentnet website addresses fall within prefixes originated by AS63949. The registered ASN therefore cannot be used as current evidence of traffic carriage, upstream diversity or failover.

The capacity facts are unknown. There is no public quantity for compute, storage, rack, power, bandwidth, support labour, sold capacity, reserved capacity or spare capacity. PeeringDB's old 20-100 Mbps range is not a current measurement. DigiCo's MW figures belong to the facility, not Sempernet.

The recovery facts are partial. The company describes customer-held local-node images, provider-held configuration files, central backups and an offsite recovery image. It publishes an emergency contact and a status page. It does not publish RTO, RPO, recovery-site location, replication mode, spare hardware, test date, failover result or exit timetable.

The questions that would turn an old network record into current assurance

A customer does not need to guess. A compact evidence request could settle most of the uncertainty:

1. Identify the legal contracting entity and explain how Sempernet, Coherent Cloud, Studentnet and Cloudwork are used in contracts, invoices, privacy notices and service support.
2. State whether AS45444 is intentionally retired, dormant or planned for reactivation, and identify the current origin ASN for each production endpoint.
3. Provide a current architecture showing where CwIN, CwIM, databases, logs, DNS, certificates, backups and monitoring run, with owners at each boundary.
4. Name the primary and recovery facilities, regions and subprocessors, and identify which workloads and data classes each one holds.
5. Provide rack or cloud tenancy evidence, power-feed design, carrier connections and physical diversity, without relying on a facility's general marketing claims.
6. Quantify installed and usable compute, storage and network capacity, current utilisation, reserved headroom and the capacity available after loss of one host, rack, carrier or site.
7. Disclose the central manager's high-availability design, the recovery image's hot, warm or cold state, and the most recent successful failover or rebuild time.
8. Define backup frequency, retention, encryption, immutability, RPO and RTO separately for customer nodes, central services and logs.
9. Document support coverage, severity targets, hardware replacement arrangements, maintenance notice and escalation beyond a single telephone number.
10. Provide an exit plan covering configuration export, logs, credentials, certificates, data deletion, transition support and the time required to move schools to another identity path.

Answers should be current, dated and tied to specific assets or contracts. A diagram that labels three upstreams is limited public evidence unless the physical routes are independent. A facility certificate is limited public evidence unless the contracted deployment is in scope. A backup screenshot is limited public evidence unless a restore has been tested. An ASN registration is limited public evidence unless its routes are visible.

A live service can outgrow its original network identity

Sempernet began with the recognisable infrastructure of a small Sydney hosting and managed-services network: portable address blocks, an autonomous system, several declared transit providers and a data-centre association. That footprint was real. The route history shows years of global operation rather than a merely reserved ASN.

The public evidence now describes a different shape. The company's products are visible, the legal entity is active, support channels exist and a status surface reports service health. But the original ASN has been absent from global routing observations since 2021. Its brand domain is parked. Its other reviewed public domains resolve to addresses in prefixes originated by AS63949. Its Sydney facility association is old, while its application description still refers to that facility by a former name.

That is not proof of failure. It shows that the old network identity no longer explains the reviewed public website delivery. Public evidence does not establish whether production workloads migrated, remained on dedicated Sydney hardware or use other origin networks and facilities. Twin-K may also retain the old number resources for legacy, private or future use. Public records do not choose among those scenarios.

The infrastructure conclusion must therefore stay exact. Sempernet's legal and historical identity is verifiable. AS45444's current global routing is negative. Coherent Cloud's public web delivery is external to that ASN. One central-VM claim and one stale facility association do not establish present rack ownership, power, network diversity or recovery capacity. Anyone depending on Cloudwork should evaluate the current application chain and its contracts, not assume that a still-active registry entry represents a still-active hosting network.