White Cloud Technologies LLC sells hosted capacity that still

Summary

White Cloud Technologies LLC is tied in ARIN records to organisation handle WCTL-3, a Twin Falls, Idaho address, AS395341, one IPv6 allocation and several IPv4 network registrations.
RIPE Stat's routing-status view for AS395341 showed 12 visible IPv4 prefixes, 5,888 announced IPv4 addresses, three observed neighbours and no visible IPv6 prefixes at the 2026-07-12T16:00:00 query time.
The public evidence supports a live routed network edge. It does not prove the location of customer servers, rack ownership, spare hardware, backup capacity, customer data placement, or recovery commitments.
The visible neighbouring ASNs are Project Mutual Telephone Cooperative Association, Level 3 Parent and Zayo Bandwidth in the RIPE Stat neighbour view. That is useful route evidence, not a complete map of commercial transit contracts or fibre diversity.
The evidence grade is Medium. Registry and BGP evidence are strong enough to profile the network surface, while facility, hosted-product, support and migration evidence remain thin.

The cloud clue is the route table, not a product slogan

White Cloud Technologies LLC is a useful reminder that hosted capacity begins as an internet and facility problem before it becomes a user-facing product. A buyer may see a service name, a recurring charge and an address block. The hidden part is the stack below the invoice: routing rights, transit contracts, power, racks, radios or fibre paths, spares, remote-hands access, backup copies, ticket queues and the person allowed to change the router when a bad path appears.

The public record for White Cloud starts with ARIN organisation handle WCTL-3, which names White Cloud Technologies LLC and lists a 663 Main Ave. East address in Twin Falls, Idaho. The same ARIN organisation page lists AS395341, registered in July 2016, along with registered IPv4 and IPv6 resources. A related public service surface appears under White Cloud Communications branding at whitecloudcom.com, where structured metadata gives the same Twin Falls street address and phone number and describes a communications business focused on two-way radio services. The services page metadata describes "Two-Way Radios, DAS, BDA, and FCC Licensing" rather than a conventional public cloud catalogue.

That combination matters. It means the outside evidence is not a clean hyperscale-cloud story. It is a regional communications and network story with routed number resources. The planned article title says White Cloud sells hosted capacity; the evidence says the public claim should be downgraded unless the operator supplies product, site and recovery detail. There is a real network edge to analyse, but public evidence does not show whether the capacity is virtual machines, fixed-wireless customer access, managed connectivity, colocation, business internet, hosted voice, internal service infrastructure, or some mix of those.

The current route evidence is still meaningful. The RIPE Stat routing-status view showed AS395341 with 12 IPv4 prefixes and 5,888 announced IPv4 addresses at 2026-07-12T16:00:00. It also showed IPv4 visibility from all 327 RIS peers in that view and zero visible IPv6 prefixes from 322 IPv6 peers. The same record listed the first observed route as 209.206.120.0/22 on 2016-10-27 and the last observed route at the query time. The route table therefore says White Cloud is not merely a stale registry entry. It says the network is visible in IPv4, while IPv6 and the physical service layer remain unproven from public data.

What ARIN actually ties to White Cloud

The strongest identity evidence is the ARIN organisation page. It names White Cloud Technologies LLC, provides the Twin Falls address, lists the organisation registration date as 2016-06-17, and shows a last-changed date of 2024-11-25. It also lists a validated contact record for Jerry Gonterman under the whitecloudcom.com email domain, with roles including abuse, administrative, network operations and technical contact. That contact alignment is relevant because the public communications site uses the same brand family and phone surface.

It is not enough to assume every product on either site is legally identical, but it is enough to connect the network record to the White Cloud public operating surface.

There is a small naming wrinkle. The ARIN autnum record for AS395341 uses the ASName value WCT-16. The ARIN organisation page for WCTL-3, however, lists that same AS395341 under White Cloud Technologies LLC. RIPE Stat's AS overview also describes the holder as WCT-16 - White Cloud Technologies LLC. The safest reading is that WCT-16 is an ASName or registry label attached to the autonomous-system resource, while the WCTL-3 organisation page is the public record that names the company, address and resource set.

That distinction may sound clerical, but it is central to infrastructure due diligence. Hosted services often carry names that differ across invoices, number-resource records, domain contacts and service pages. A customer who cares about recovery should not stop at the marketing name. It should ask which legal party owns or controls the number resources, which party signs the service contract, which party holds the facility agreement, and which party can authorize routing and repair changes under pressure.

The ARIN page also shows the public address portfolio. White Cloud Technologies LLC has an IPv6 allocation, 2604:ab40::/32, and eight IPv4 network registrations: 141.193.8.0/22, 147.160.6.0/24, 161.38.44.0/22, 207.135.218.0/23, 208.64.8.0/22, 209.206.120.0/22, 216.180.115.0/24, and 74.205.204.0/22. Registered address space is not the same as active service capacity, but it defines the pool from which service capacity can be originated, delegated, routed or held in reserve.

The public lesson is not "White Cloud has a cloud platform." The lesson is narrower and more useful: White Cloud has a public number-resource footprint with active IPv4 origination. Anyone depending on the company should ask how that footprint maps to actual customer services, physical sites and restoration options.

The address pool is bigger than the live prefix set

The difference between registered and announced address space is one of the best places to look for capacity risk. ARIN's WCTL-3 page lists roughly 6,144 registered IPv4 addresses across the eight IPv4 network registrations above. RIPE Stat's announced-prefixes view showed 5,888 announced IPv4 addresses at the 2026-07-12 query time. The missing portion is not automatically a problem. It may be reserved, filtered, unused, routed elsewhere, or split differently than the parent registration. But it does mean that a registry block should not be quoted as current usable capacity without checking live route state.

The RIPE Stat routing-consistency view makes this split visible. It showed several registered less-specific networks that were not announced in their parent form, such as 74.205.204.0/22, 141.193.8.0/22 and 207.135.218.0/23. It also showed more-specific announcements that were visible in BGP but did not exactly match those parent registration rows, including 74.205.204.0/23, 74.205.206.0/23, 141.193.8.0/24, 141.193.11.0/24, 207.135.218.0/24 and 207.135.219.0/24. That pattern can be entirely normal; operators often announce more specifics for traffic engineering, upstream policy, customer segmentation or regional routing. It is still a sign that the public address portfolio must be read at the prefix level, not as one simple capacity number.

For hosted or managed service customers, the difference matters because a routed prefix is a dependency. If customer services sit in a /24, the failover and abuse-management plan should be written for that /24, not for the larger parent block. If a customer depends on addresses from 141.193.8.0/22, the fact that 141.193.10.0/24 was not in the current announced-prefix list matters less than where the customer actually sits. If the provider needs to move a customer between ranges during repair, the customer should know what DNS, firewall, allow-list and reputation consequences follow.

The address pool also reveals a useful timeline. The 209.206.120.0/22 registration dates to July 2016 and was the first prefix RIPE Stat observed for AS395341 in October 2016. Later ARIN registrations appear across 2017, 2018, 2019 and 2020. That expansion suggests a network footprint that grew over several years rather than a single one-time resource record. It does not identify the sites or customers behind the growth. It does establish that White Cloud's routed surface has enough history to deserve a proper resilience review.

The safest conclusion is therefore measured: White Cloud's IPv4 edge is live and externally visible; public evidence does not prove how much spare capacity is available after a rack, upstream, facility or hardware failure.

IPv6 exists in the registry but not in the current public route view

White Cloud Technologies LLC has an ARIN IPv6 allocation at 2604:ab40::/32. That is a large resource by ordinary customer standards, and it gives the operator room to number access networks, customer services, infrastructure loopbacks, management interfaces or hosted systems. The ARIN network page shows the allocation registered on 2018-03-02.

The current public route view tells a different story. RIPE Stat's routing-status response for AS395341 showed zero IPv6 prefixes and zero IPv6 address space announced at 2026-07-12T16:00:00. Its visibility line showed no IPv6 RIS peers seeing an originated IPv6 route. The routing-consistency view also included a 2001:470:29e::/48 entry in registry-derived data, but again no active IPv6 BGP visibility for AS395341 in the current route snapshot. That makes IPv6 an evidence gap, not an established customer feature.

This matters for dependency analysis. Dual-stack service can improve resilience when IPv4 and IPv6 are both engineered, monitored and supported. It can also create a false sense of maturity when one address family exists only on paper. A customer that needs IPv6 should not ask only whether White Cloud has an allocation. It should ask which prefixes are currently announced, which services are reachable over IPv6, whether reverse DNS and route-origin authorization are in place, whether help-desk playbooks include IPv6 faults, and whether the failover path preserves IPv6 reachability.

IPv6 also changes data-locality assumptions. An IPv6 allocation does not prove where traffic terminates or where customer data is stored. It only proves that the resource exists in the registry. For a regional provider, IPv6 may be used on access equipment, customer routers, servers or not at all. The evidence reviewed here cannot settle that. It can only warn against treating the IPv6 allocation as proof of usable, supported, customer-facing IPv6 service.

The same caution applies to route-origin security. RIPE Stat's RPKI validation response for sample White Cloud IPv4 prefixes returned an unknown status because no validating ROAs were found in that response. The ARIN RPKI material and RFC 6811 explain why route-origin authorization matters: networks that enforce validation may reject invalid routes, and valid routes are easier for counterparties to trust. Unknown is not the same as invalid, but it leaves a routing-security question open.

Three observed neighbours do not prove physical diversity

RIPE Stat's ASN-neighbours view showed three observed neighbours for AS395341: AS17380, AS3356 and AS6461. RIPE Stat's own overview labels these as Project Mutual Telephone Cooperative Association, Level 3 Parent and Zayo Bandwidth. The neighbour view marks them as left-side neighbours, with IPv4 observations and no IPv6 neighbour observations in that result.

For a small or regional network, that is materially better than a single visible upstream. It suggests that public BGP collectors see AS395341 adjacent to more than one network. But it is not proof of resilience. BGP adjacency does not disclose whether those sessions are paid transit, private peering, backup transit, regional transport, exchange-learned paths, or another arrangement. It also does not disclose whether two carriers enter the same building through the same duct, land on the same router, depend on the same power plant, or share a maintenance risk.

The route table and the physical plant can disagree. A network can show multiple upstreams while the customer's circuit still depends on one tower, one building entrance, one switch, one cross-connect panel or one site-access arrangement. A network can also have diverse fibre but limited public evidence contracted bandwidth on the backup path. The failure case that matters to a hosted customer is not "does another ASN appear in a neighbour list?" It is "can the remaining path carry my service at the moment the primary path, rack or router fails?"

White Cloud's public evidence therefore supports a set of concrete questions. Which of the three visible neighbouring networks carry default-capable traffic? Are they active-active or active-standby? Are they delivered to separate routers and power circuits? Are any customer services reachable through only one of them? Is there enough headroom to absorb peak traffic if one neighbour disappears? Are routing changes tested during a quiet maintenance window before a real outage?

The public MANRS network-operator guidance and RFC 7454 on BGP operations and security give the general hygiene frame: prevent route leaks, filter consistently, maintain accurate routing policy and make routing decisions observable. They do not certify White Cloud's specific design. They explain why multiple neighbours are only the beginning of the resilience review.

The White Cloud communications surface changes the likely failure modes

The public White Cloud communications site matters because it describes a company whose visible offering is rooted in physical communications work, not only abstract hosted compute. The home page metadata describes White Cloud Communications as a local business at the Twin Falls address, with weekday office hours and the same 208-733-5470 phone number that appears in ARIN contact data. The site title emphasizes two-way radio. The services page metadata points to two-way radios, distributed antenna systems, bi-directional amplifiers and FCC licensing.

Those details shift the operating lens. A radio and wireless communications operator may hold IP space for management systems, broadband customers, voice and dispatch systems, backhaul, customer routers, hosted applications, web portals or network-support services. The risk is not only a server rack in a conventional data centre. It may also be a tower site, rooftop antenna, repeater location, point-to-point wireless hop, licensed radio system, customer premises equipment, backhaul path, or a small data room connected to regional transport.

That does not make the company less important. In rural and regional connectivity, a provider's real dependence often sits in a messy mix of radio sites, fibre handoffs, leased space, power systems, supplier stock and field service. A cloud-style customer may experience those dependencies as a simple service outage, but the repair path is physical. A failed power supply at a tower, a damaged dish, an ice-loaded mount, a bad switch, a cut fibre or a delayed tower-climb approval can all become the reason a hosted or managed service degrades.

The public web surface also makes it hard to assign a clean product category. The assignment's cloud-service category is reasonable because the company has routed address resources and customer-facing capacity. The evidence, however, points toward a regional communications operator whose public services are more about connectivity and radio systems than a commodity virtual-machine shop. The article therefore treats "hosted capacity" broadly: any customer capacity sold as a managed service that depends on White Cloud's address resources, facilities, upstreams, equipment and support staff.

That broader definition is useful because it focuses on the actual dependency. Whether the customer buys business internet, a managed router, a hosted application, a radio-linked service or colocated equipment, the same questions appear: where is it powered, how is it routed, how is it repaired, and how does the customer leave if service or support fails?

Installed capacity is not the capacity that survives a failure

Capacity is often counted in ways that look precise but fail during incidents. Registered addresses, nominal bandwidth, tower coverage maps, server counts and service-area claims are installed capacity. Usable capacity is what a customer can consume today. Recoverable capacity is what remains after a defined failure. A customer should care most about recoverable capacity, because that is the capacity it will have on the day something breaks.

For White Cloud, public BGP evidence shows 5,888 announced IPv4 addresses, not the number of powered servers or available service ports. ARIN records show registered address resources, not the amount of spare hardware in Twin Falls or at any remote site. The public website shows a communications business surface, not a complete facility inventory. PeeringDB's API query for AS395341 returned no network profile in the checked response, so there is no public PeeringDB list of facilities, internet exchanges or policy notes to use as a cross-check.

That is not unusual for a regional provider. Many small and mid-sized operators do not publish facility names or rack diagrams. But absence of facility data should lead to a careful commercial conversation. If a customer hosts a critical system, it should know whether equipment is in a leased data-centre rack, an owned office room, a tower shelter, a carrier hotel, a third-party cloud account, or a partner facility. Each placement has a different repair clock and a different failure owner.

Power is the first hidden divider. A service may have public route diversity but one power domain. A tower or small equipment room may have batteries but limited generator runtime. A data-centre rack may have redundant feeds but a single customer device with one power supply. A field site may be hardened for radio service but not designed for dense compute. A customer cannot infer the answer from the route table.

Hardware stock is the second divider. A spare router, radio, switch, server disk or optical module has to be physically available, compatible, tested and reachable by someone authorized to install it. If the spare is ordered after the failure, the service-level promise is really a supply-chain promise. If the spare is in another city, the restore time includes travel and courier risk. Public records do not show White Cloud's stock position, so any capacity-dependent contract should state what spares are on hand and which repairs depend on third parties.

The main failure path is not one thing

The assignment's main failure path is a rack, upstream, hardware-stock, support, billing, migration or provider-contract failure. White Cloud's public evidence supports all of those as plausible review areas, not because the record shows a specific incident, but because the service surface depends on physical communications infrastructure and a routed IPv4 edge.

A rack or room failure is the simplest case. If customer systems sit in one cabinet, one data room, one tower shelter or one leased rack, then a power, cooling, access or equipment fault can degrade every customer assigned to that site. A customer should ask whether critical systems are split across sites and whether the split is real at the storage and routing layers. A second site that depends on the same upstream, the same management system or the same billing lock does not provide full independence.

An upstream failure is visible earlier in public data. If Project Mutual, Level 3/Lumen or Zayo adjacency disappears from the route table, the public edge may still remain reachable through the others. That is useful. But the customer needs to know whether the remaining paths are sized, routed and physically diverse enough. A backup path that is congested at peak hour will keep pings alive while making applications unusable.

Hardware stock is harder to see and often more decisive. Regional networks tend to run equipment for a long time because gear is expensive and supply lead times vary. That can be economically sensible. The risk appears when a failed part is no longer stocked, a software image is no longer supported, or a replacement requires a design change. Customers who depend on White Cloud for hosted or managed capacity should ask which parts are stocked locally, which are supplied by carrier or facility partners, and which repairs require vendor escalation.

Support failure is the human version of the same risk. If the person who understands a route filter, tower hop, customer firewall or storage system is unavailable, the route table may not help. Customers should ask whether support escalation is tied to a single individual or small group, how after-hours incidents are handled, and whether status messages are independent of the affected service. A phone number on a public site is useful contact evidence; it is not an incident-management guarantee.

Billing and contract failure can be just as disruptive. Hosted capacity can be suspended by an account dispute, expired payment method, domain-name issue, reseller contract change or unresolved abuse complaint. The customer may experience that as an outage even if the network is healthy. The contract should therefore define grace periods, access to backups, emergency reinstatement and export rights separately from ordinary billing terms.

Migration failure is the final risk. A customer that cannot leave has accepted the provider's failure as its own. For White Cloud, the public record does not show data-export terms, virtual-machine images, router-config export rights, address portability or backup-retention windows. Those are not registry facts. They are contract facts, and they should be settled before the customer relies on the service.

Data locality is not answered by the Idaho address

The United States region assignment is supported by ARIN, the Twin Falls address and the public White Cloud communications site. That does not settle data locality. A company can be based in Idaho while customer systems, backups, logs, support tickets, billing records or monitoring data sit in another state or on a third-party platform. An IP address routed by AS395341 does not prove where application data is stored, who can access it, or which subcontractor handles restoration.

Data sovereignty for a regional provider is often less about international transfer and more about operational control. Who has administrative access? Are backups encrypted and where are they held? Are support logs retained in a customer portal hosted outside the provider's own network? Are customer routers or servers managed through a vendor cloud? If a law-enforcement, civil discovery or billing dispute arises, which party can produce, freeze or delete the data?

The address-space evidence can help frame those questions. If a customer's service is numbered out of 209.206.120.0/22 or 208.64.8.0/22, the customer can monitor whether routes remain originated by AS395341. That helps detect edge changes. It does not show whether backups moved, whether an application record store exists somewhere else, or whether a management console depends on a different provider. Public routing tells a customer where packets are announced, not where every copy of the data lives.

The lack of visible IPv6 adds another locality question. If White Cloud offers only IPv4 reachability for a customer service, the customer may depend on carrier-grade translation, dual-stack partners or application-layer proxies elsewhere. If White Cloud does operate IPv6 privately but does not originate it publicly through AS395341, customers should ask how IPv6 services are delivered and where those paths terminate. Again, the public record is enough to ask; it is not enough to answer.

The best contract language would separate primary service location, backup location, log location, ticketing location, management access and subcontractor access. It should also state how a customer can obtain a complete export while the service is degraded. A data export that only works through the failed portal is not a recovery path.

Public service signals should be treated as signals, not proof

White Cloud's web footprint is thinner than the public route table. The sitemap at whitecloudcom.com/sitemap_index.xml lists a small set of ordinary company pages and many local service pages around emergency radio systems, testing, digital mobile radio and related terms. The home page and services metadata describe a communications specialist. The public pages do not provide a detailed hosted-compute catalogue, data-centre list, transit design, backup policy or service-level document.

That thinness should not be punished as if every regional communications operator had to publish a hyperscale-style trust portal. It should, however, control the article's confidence level. Public BGP and ARIN evidence are strong for the network edge. Public evidence is weak for rack location, customer workload placement, virtualisation platform, bare-metal inventory, backup restore process and customer exit terms.

Third-party aggregator pages, such as IPinfo's AS395341 view and Hurricane Electric's AS395341 page, can help confirm that other public views associate AS395341 with White Cloud Technologies LLC. They are useful cross-checks, especially when one source has sparse fields or a naming ambiguity. They cannot replace operator-provided evidence. Aggregators can lag, filter, omit private arrangements or present derived inferences that need verification.

The right way to use unofficial signals is to state what they can and cannot show. A search result or aggregator can suggest that an AS name, route or service surface exists. It cannot prove that a customer workload is hosted in a particular building, that a route is backed by a contract, that a backup restores within a promised time, or that a support escalation will be staffed during a major fault. The public evidence here is enough to identify White Cloud's operating surface, not enough to approve high-dependency customer placement without further proof.

For a buyer, the evidence to request is straightforward: a current prefix list, a simple network diagram, facility or site classes, upstream list, power and backup summary, spare-hardware statement, support escalation path, route-origin security plan, backup and export terms, and a recent restore test. None of those require disclosing sensitive customer names. They do require showing that the service is more than a routed number-resource record.

The same distinction matters for monitoring after the contract is signed. A customer can independently watch whether AS395341 continues to originate the prefixes listed by RIPE Stat, whether third-party views such as BGP.Tools and Hurricane Electric still associate the edge with White Cloud, and whether routing changes coincide with maintenance notices. That monitoring will catch some external symptoms: a withdrawn prefix, a changed upstream, a route that stops being visible, or an unexpected origin. It will not catch a failed backup job, an unavailable spare, a staff shortage, a locked customer portal, or a billing hold that prevents export during an incident. The provider's internal proof therefore has to complement the public route checks. The most useful operating package would name the service location class, state which upstreams and power domains matter to the customer's workload, document how support escalates after hours, and show one recent restore or migration exercise. Without that package, the customer is left with an incomplete but still important signal: White Cloud Technologies LLC controls a visible internet edge, while the durability of the customer service behind that edge remains a contract and operations question.

What customers should verify before depending on the service

A serious review of White Cloud's hosted or managed capacity should begin with scope. What service is actually being bought? If it is business connectivity, the review should focus on access paths, backhaul, tower or fibre dependence, customer equipment and support escalation. If it is hosted compute, the review should focus on racks, power, storage, backup, hypervisor management, patching and exit. If it is managed radio or dispatch infrastructure, the review should focus on licensed systems, site power, field access, spare radios and public-safety operating expectations.

The second step is mapping address use. The customer should know which public prefixes its service uses and whether those prefixes are originated only by AS395341. It should monitor RIPE Stat announced prefixes or an equivalent public feed for changes. It should ask whether route-origin authorization will be published for customer-used prefixes and what happens if a route becomes unknown or invalid in networks that enforce validation.

The third step is proving redundancy. The presence of three observed neighbours is useful, but the customer should ask for route and physical diversity separately. Do Project Mutual, Level 3/Lumen and Zayo paths terminate in separate places? Which path is primary for the customer's traffic? Can White Cloud show a maintenance or failover test where one upstream is removed and the service remains usable? Is there enough capacity on the remaining path to meet the customer's minimum service requirement?

The fourth step is proving restoration. A customer should ask what fails over automatically, what requires human action, what requires facility access, and what depends on a supplier. It should ask whether backups are stored in a different power and network domain. It should ask how long it takes to restore a full customer workload, not just a single file or a router configuration. It should ask for the difference between a tested restore and an estimated restore.

The fifth step is proving independence. Can the customer export data, configurations and logs without waiting for a special project? Can it move DNS, firewall rules and access controls under time pressure? If the service includes IP addresses controlled by White Cloud, what migration plan exists if the customer needs to renumber? If the account is in a billing dispute, does the customer still have emergency access to retrieve backups?

These questions are not adversarial. They are the normal questions that convert a regional service into a dependable operating dependency. A provider with disciplined answers benefits from the exercise because it can sell reliability honestly. A provider without answers should not be asked to carry workloads whose owners cannot tolerate the uncertainty.

Evidence grade: a live IPv4 edge with important unknowns

White Cloud Technologies LLC earns a Medium evidence grade. The positive side is clear: ARIN ties the company name to WCTL-3, a Twin Falls address, AS395341 and registered IPv4 and IPv6 resources. RIPE Stat shows live IPv4 origination, full IPv4 visibility across its peer set at the query time, twelve current IPv4 prefixes, and three observed neighbours. Public third-party views also associate AS395341 with White Cloud Technologies LLC.

The negative side is equally important. The public record does not show a PeeringDB network profile for AS395341. RIPE Stat shows no current IPv6 origination even though ARIN lists an IPv6 allocation. Sample RPKI validation checks returned unknown because no validating ROAs were returned in those responses. The public website emphasizes communications and radio services rather than a detailed cloud or hosting catalogue. Public evidence does not identify the physical facility, rack ownership, backup site, hardware stock, data-location commitments, service levels, billing protections or migration terms.

That grade should shape how readers use the company. White Cloud is not a name to dismiss as empty, because the network edge is live and has been visible for years. It is also not a provider to treat as fully evidenced cloud capacity from public records alone. The route table can show reachability. It cannot show who can enter the room, which spare part is on the shelf, which upstream contract carries emergency traffic, or whether a customer can leave cleanly during a bad week.

The practical conclusion is therefore specific to White Cloud Technologies LLC: the company's public internet footprint is real enough to justify a network-level resilience review, but the review must move from AS395341 and the Twin Falls contact surface into physical proof. Customers should verify active prefixes, route-origin security, upstream diversity, site placement, power, spares, support escalation, backup restore and export terms before treating White Cloud capacity as a dependable hosting or managed-service foundation.