Summary

  • AITelecom's own pages describe a Mexican satellite and terrestrial communications company offering internet access through wireless networks and satellite options, especially for remote locations. That establishes a useful service frame, but it remains first-party positioning, not independent proof of current coverage, physical plant, subscriber density or repair depth.
  • The company's legal page says its tariffs are registered with Mexico's Instituto Federal de Telecomunicaciones under folios 36408, 36409, 36410 and 36411. That gives the article a regulator-facing hook, but tariff references do not prove the current retail plan set, active service availability, route diversity, field operations or delivered performance.
  • LACNIC RDAP identifies active AS28396 as a direct allocation to AITelecom S.A. de C.V.; RIPEstat marks AS28396 announced and shows three IPv4 /24 routes in the 8-22 July 2026 window. This is stronger than a marketing claim because it puts a named company on a visible routing edge. It still does not prove access-network resilience.
  • PeeringDB lists an AITelecom AS28396 network record and one operational IXSY netixlan row with route-server peering true. That can support a narrow interconnection disclosure. It cannot be turned into a statement about actual throughput, independence, congestion, uptime, customer impact or whether private transit exists elsewhere.

A visible network is not the same as a resilient bill

The simplest version of the AITelecom story is tempting. A company says it offers internet access. A regional registry shows an active autonomous system under the same legal name. A routing-data service sees prefixes announced by that autonomous system. PeeringDB adds a self-disclosed exchange attachment. Put together too quickly, those facts can sound like a complete operating profile.

They are not complete enough for that. They are a sequence of public signals, each useful and each narrow. The service pages tell readers how the company presents itself. The legal page points to regulatory-facing tariff records and official collaboration channels. LACNIC identifies the holder of an internet-number resource. RIPEstat shows observed route visibility in a defined time window. PeeringDB records what the entity has chosen to disclose about its network and an exchange LAN.

A customer bill depends on more than any one of those layers. It depends on the access medium at the premises, the path from that premises to an aggregation point, the power feeding equipment on both ends, the upstream handoffs behind the local network, the operational practices that catch faults, and the technicians and spare parts that restore service. A record can prove one layer while leaving most of that chain unseen.

This distinction matters for regional internet providers because their value is local, practical and uneven. A large national carrier can sometimes hide a weak district behind a broad corporate footprint. A smaller provider is judged closer to the installation: does the link work at a particular address, does support answer, does the route remain usable during bad weather or a local power problem, and how quickly can the failed piece be reached? Public documents rarely answer those questions directly.

AITelecom's public record is therefore best read as an evidence boundary. It is enough to say that the company has a visible legal and routing surface. It is not enough to say that the access bill is resilient. The article's question is narrower and more useful: what does the public evidence prove about the chain behind AITelecom connectivity, and where would a buyer still need local proof?

The service claim starts with wireless and satellite access

AITelecom's first-party company page describes it as a satellite and terrestrial communications developer in Mexico. The page says its specialty is connecting organizations in Mexico and Central America. That phrase gives the company a clear operating posture: it is not merely a domain name around an autonomous system, and not merely a tariff entry. It presents itself as a communications provider for organizations that may need connectivity beyond conventional coverage.

The Internet page sharpens the access frame. It says AITelecom works to keep clients connected regardless of location and that its terrestrial solutions allow high-speed internet access in places where conventional internet services do not reach, using wireless networks or satellite options. The same page describes satellite internet as a link in which satellite systems help carry voice, video and data. These are directly relevant to the resilience question because remote access and non-cable options often sit at the edge of ordinary repair and upstream economics.

Yet the first-party nature of the evidence is important. Service pages are written to sell a capability. They can identify product families, markets and intended use cases, but they do not usually disclose how many links are live, which sites are active, what equipment is used today, how often links fail, or how much capacity is available in a specific place. A writer should not treat a marketing page as a topology.

The broad wording also leaves the access mix open. AITelecom mentions terrestrial and satellite communications, wireless networks and satellite options. It does not publish, in the reviewed source set, a current map of each technology by locality. It does not say how often satellite acts as a primary service, a backup service, or a specialised option for specific clients. It does not establish that a particular customer connection uses one medium rather than another.

This is not a weakness unique to AITelecom. It is a common problem in local access analysis. The customer sees a provider name and a product label. The reference may show a technology category. The operational question sits in the space between them: which exact path serves this address, what part of that path is shared, where is the backup, and who repairs it when the failure is not simply a modem reset?

The evidence supports a cautious formulation. AITelecom markets itself as a Mexican satellite and terrestrial communications company, and it specifically describes internet access through wireless networks and satellite options, including for remote locations. That makes it a relevant regional connectivity subject. It does not let the article claim complete coverage, a present satellite footprint, fibre ownership, tower ownership, or reliable service at any named location.

Regulatory-facing details provide a useful but limited hook

The legal page adds a different kind of source. It says AITelecom's tariffs are registered with the Instituto Federal de Telecomunicaciones under folios 36408, 36409, 36410 and 36411. It also gives channels for collaboration in security and justice matters, including an email address, phone number and a physical address in Merida, Yucatan. This is not just sales language. It places the company in a regulatory-facing operating context.

Tariff registration matters because internet access is not only an engineering service. It is also a commercial offer with terms, prices and regulatory exposure. A tariff reference can help distinguish a live telecom service surface from a vague technology consultancy claim. It also gives readers a traceable way to ask whether specific offers have formal filings behind them.

But the tariff statement is still not an operating audit. A legal page does not prove that a particular tariff is the current customer plan, that the referenced folios cover every service described on the site, or that the terms match the service a customer is offered today. It does not expose the network build, the upstream path, the installed capacity, or the repair organisation behind the filed offer. It is an anchor, not a full map.

The Merida address has the same boundary. It aligns with the registry layer, where the LACNIC record also places the registrant in Merida. That repeated locality is useful for identity and contactability. It should not be converted into a claim about equipment location. An office or contact address may be administrative, legal or operational, and the public source does not identify it as a network operations centre, teleport, exchange point, repair depot or customer aggregation site.

For resilience analysis, the regulatory-facing evidence therefore does two things. It strengthens the case that AITelecom is an operating telecom service provider worth tracking. It also shows why stronger public evidence would be needed before drawing conclusions about the customer experience. A tariff filing can exist while the path to the customer's premises remains fragile, or while the provider has strong engineering that is simply not visible in the public record.

The article should preserve that difference. AITelecom has enough regulatory-facing presence to be more than an unverified website. The public legal source does not answer the harder questions: whether access links are diverse, whether power is backed up, whether field crews can reach remote sites quickly, whether satellite service is primary or contingency, or whether customer traffic relies on one exposed handoff.

AS28396 gives the company a public routing identity

The LACNIC RDAP record is the clearest identity bridge in the source set. It identifies AS28396 as an active direct allocation and names AITelecom S.A. de C.V. as the registrant. The record gives the autonomous system as both the start and end of the allocation, making it a single ASN entity. Its events record registration in December 2014 and a last changed date in June 2022.

That matters because an autonomous system is not merely a marketing badge. It is a routing-policy identity. When a company has a live ASN, outside observers can look for route announcements, registry contacts and related public interconnection records. The ASN gives the company's network edge a handle that can be tested against public routing data.

The same record's registrant vCard points to AITelecom S.A. de C.V. and gives a Merida address. Contact information appears for administrative, technical and abuse roles. That supports a normal internet-number stewardship frame: the resource has a named organization and designated contacts. It does not guarantee that the contacts are sufficient for all service incidents, or that the address is where the technical work is performed.

RIPEstat's AS overview adds a current observation layer. It identifies the holder string as AS28396 - AITelecom S.A. de C.V. and marks the ASN as announced in the fetched overview. The announcement status separates this record from a merely dormant registration. It shows that the ASN was visible enough in the data source to be treated as announced at collection time.

Still, the term active means different things in different systems. In RDAP, active is registry status. In routing data, announced is an observation about BGP visibility. Neither tells a reader what traffic is flowing, how many customers are behind it, what backup exists, or whether failures have occurred. A well-run local network and a fragile local network can both have an announced ASN.

That is why AS28396 should be used carefully. It is a strong anchor for the article because it gives the public story a network-resource entity. It is not a proof of resilience. It supports the first half of the title: AS28396 makes AITelecom visible. It does not support the second half without additional local evidence: the resilience behind the access bill remains unproven.

Three announced prefixes show reach at the edge, not capacity behind it

RIPEstat's announced-prefixes query returned three IPv4 /24 prefixes for AS28396 in the 8-22 July 2026 window: 200.9.182.0/24, 200.9.183.0/24 and 200.9.184.0/24. This is useful evidence because it moves beyond registration into observed public routing. AITelecom's ASN was not just assigned; it had visible IPv4 routes in the measurement window.

The three routes give analysts a bounded view of the network edge. They provide route objects that can be watched over time. They also let readers distinguish between a company with only a website and one whose resource identity appears in public internet observations. For a regional connectivity provider, that distinction matters. It establishes that the company has a public routing surface that may sit behind customer or organizational services.

But a prefix list is not a capacity statement. Three /24s do not tell the amount of bandwidth bought from upstream providers, the oversubscription ratio, the busiest-hour experience, the number of customers, or the amount of address space actually in use. They do not reveal whether routes follow separate physical paths or share a single powered location. They do not show whether traffic is protected during local power failures, cable cuts or equipment faults.

The route list also does not identify the access network between the customer and the routed edge. If a customer receives service over fixed wireless, the customer's experience can be shaped by line of sight, interference, local mast power, equipment alignment, roof access and weather exposure. If the customer uses satellite, other constraints apply. RIPEstat cannot see those access-layer conditions. It sees the public internet side, not the installation.

Address space can also mislead if treated as a proxy for scale. A /24 contains 256 IPv4 addresses before reservations and internal use. Three such routes may support different business models depending on NAT, customer type, allocation policy and upstream design. Without subscriber counts, traffic data or service architecture, the prefix count should not be used to imply market size.

The right conclusion is narrower and sturdier. AS28396 had three observed IPv4 /24 routes in the reviewed RIPEstat window. That is a real routing signal. It does not demonstrate route diversity, physical redundancy, subscriber scale, delivered speed, usable capacity, customer uptime, repair performance or the independence of AITelecom's access plant.

PeeringDB adds one self-disclosed exchange surface

PeeringDB returned a network record for ASN 28396 with the name AITelecom. The record classifies the network as Network Services, marks general peering policy Open, and lists one IX count. The associated netixlan query returned one operational row at IXSY, with route-server peering set to true, IPv4 address 45.164.110.11, IPv6 address 2806:30c:2021:110::11, and a 1 Gbps speed value.

This evidence is useful because PeeringDB is a place where networks disclose interconnection details for other operators. The IXSY row suggests that AITelecom presents at least one public exchange-facing interconnection surface in the database. It also indicates route-server participation, which can matter for reachability and policy. Combined with the announced-prefix evidence, it makes the network more visible than a provider whose only public artifact is a service page.

The usual PeeringDB limits still apply. PeeringDB is entity-maintained. It is not an independent audit of the port, the traffic level, the customer impact, the service quality, or the physical diversity behind the listed attachment. The 1 Gbps field should not be read as delivered customer capacity. It is a disclosed port-speed field, not a public performance report.

The row also should not be turned into a statement of dependency concentration. One public IX row does not mean AITelecom has only one upstream path. It does not prove the absence of private transit, private peering, backup links, satellite backhaul, commercial handoffs or other facilities. Conversely, it does not prove that those alternatives exist. It simply gives one disclosed exchange edge.

Route-server peering needs similar care. A route server can simplify multilateral reachability at an exchange. That is different from proving resilience for an end customer. A customer's video call can fail because the access radio lost power, a cable was damaged, a router failed, a premises device crashed, an upstream path congested, or a local support process stalled. A route-server flag does not remove those failure modes.

PeeringDB therefore supports a specific public claim: AITelecom has a PeeringDB network record and an operational IXSY netixlan disclosure for AS28396. It does not support broader claims about redundancy, traffic performance, uptime, path independence or customer experience. The article can use it as part of a visibility stack, but not as the answer to the resilience question.

The access layer remains the least visible part

AITelecom's public story points repeatedly toward access. The company page talks about connecting organizations across Mexico and Central America. The Internet page discusses wireless networks and satellite options for places that conventional internet does not reach. The legal page refers to tariffs. The routing layer shows an announced ASN. Yet the most customer-sensitive part of the system remains the least visible: the path from the premises to the provider's routed edge.

Access resilience is physical before it is statistical. A fixed wireless customer may depend on radio alignment, a clear path, a powered mast or rooftop unit, weatherproof cabling, and a nearby aggregation point. A satellite customer may depend on antenna placement, power, equipment condition, backhaul arrangements and service policy. A fibre customer, if one exists in a particular case, may depend on ducts, poles, splice points and local repair access. The public source set does not show which of these applies to which customer.

That absence prevents strong claims in both directions. It would be unfair to assume weakness simply because the access layer is not publicly documented. Many competent operators do not publish detailed plant maps, upstream contracts or failure statistics. But it would also be unsafe to infer strength from a visible ASN and a service page. The proof is missing, not the network.

Customer density is another blind spot. Regional access economics change when customers are close enough to share infrastructure, technician time and spares efficiently. Sparse demand can make repairs slower or force more expensive designs. Dense local demand can support more resilient build choices. AITelecom's public sources do not reveal density, locality mix or installation volume. They do not show whether remote customers are the exception, the core business, or a specialised segment.

Power is equally opaque. The image of a resilient link often assumes backup power at network locations and customer-premises equipment. The sources reviewed here do not document backup batteries, generators, power autonomy, monitoring, or how AITelecom prioritizes restoration when power and connectivity fail together. In remote or difficult locations, power can be as important as bandwidth.

Field repair also remains unknown. The service promise behind any access bill depends on whether a provider can diagnose and reach a fault. A radio unit may need adjustment. A cable run may need replacement. A premises device may need swapping. A remote installation may require travel. Public records do not say how many field staff AITelecom has, where they are based, what spares they carry, or what repair windows customers receive.

For a buyer, these missing facts are not academic. They determine whether the visible routing edge matters at the moment of failure. AS28396 can be announced, and the IXSY row can be operational, while a local access link at one site is down. Resilience is made across the whole chain, not at the public edge alone.

Satellite language should be treated as a capability, not a shortcut

Satellite service claims can easily sound like a resilience shortcut. If a provider can use satellite links, the reader may imagine that geography and local infrastructure limits disappear. AITelecom's Internet page does say that satellite connections are not limited by cable reach and that the antenna needs visibility to the satellite. That is a meaningful service statement for remote locations.

It is still not enough to prove continuity. Satellite links have their own dependencies: equipment, antenna placement, installation quality, power, subscription terms, backhaul design, latency, weather exposure and service policies. The public source set does not identify which satellite systems are used, whether they are primary links or backups, what capacity is available, or how the service performs in specific conditions. The article should not imply those answers.

The same caution applies to the phrase "anywhere" or "remote." Marketing language can describe the goal of reach, not a tested availability grid. A link that works in one remote site may not work in another. The public evidence does not provide a coverage map, installation rules, minimum signal conditions or repair arrangements for satellite service.

Satellite can still be part of the analysis because it changes the dependency set. A remote customer might care less about fibre cuts and more about power, antenna visibility, equipment replacement and service policy. An enterprise using satellite as backup might care about failover design and whether applications tolerate latency. A rural site using satellite as primary access might care about capacity sharing and support.

The key is to avoid treating satellite as magic. It may help where cable does not reach, but it does not eliminate operational questions. It moves the questions to a different architecture. For AITelecom, the public sources establish satellite as a service option in the company's own description, not a proven resilience layer for all customers.

Data-center and service-menu language needs a hard boundary

AITelecom's navigation includes service labels beyond internet access, including content and data-center-labelled pages. Such labels can be commercially relevant. They suggest the company wants to serve more than simple household connectivity and may package communications, hosting, storage or managed-service work for organizations. But the reviewed source set does not prove a data-center operating surface.

This distinction matters because a data-center claim has a different evidence burden. To say that a company operates a data center, a writer would normally want a facility address, ownership or operating role, power/cooling claims, colocation or hosting terms, independent customer evidence, certifications, photos that can be verified, or registry data tied to the facility. A navigation label does not supply that.

The service-menu wording is better used as context for the access bill. A company that offers voice, content, managed services or data-center-labelled products may increase the dependency carried over its access links. If a customer buys more services from the same provider, the failure of the access path may affect more business processes. That is a legitimate analytical angle.

But the angle must remain negative where the sources are silent. The article should not say AITelecom owns a data center, operates cloud infrastructure, controls a storage platform, or provides route diversity through a hosted environment. It can say the first-party site presents a broader services menu and that the infrastructure behind those services is not disclosed in the sources reviewed.

That approach keeps the article useful without overstating. It points readers toward questions that matter: where are hosted or managed services run, what third parties are involved, how are services separated, what happens if the access link fails, and whether backup paths exist. Those questions arise because of the service menu. They are not answered by it.

What a stronger resilience record would show

The current public record is enough for a bounded article, but not enough for an operating-grade resilience conclusion. A stronger record would connect the layers. It would show which access media serve which locations, where traffic hands off to upstream networks, whether IXSY is primary or supplementary, and whether private transit or backup paths exist. It would explain how satellite options are used and where they fit into continuity planning.

It would also show whether the three observed IPv4 prefixes represent separate failure domains or simply separate routes behind a common path. It would identify current upstream providers, physical handoff diversity and route-policy safeguards. It might include RPKI or routing-authentication evidence if relevant, but even those would only cover the routing layer. The access layer would still need physical and operational proof.

For customers, a stronger record would include service-level definitions that can be tested. Availability language is meaningful only if the denominator, exclusions, credit process and measurement method are clear. Repair-time commitments matter only if a customer knows what counts as response and what counts as restoration. Backup-power claims matter only if they specify the sites, duration and maintenance assumptions.

For regional economics, density and logistics would matter. A provider serving clustered customers can justify different spare-equipment and technician models than one serving scattered remote installations. A public record of service areas, installation counts, reseller relationships or institutional contracts could help readers judge that model. The AITelecom sources reviewed here do not provide it.

For interconnection, the next layer would be current and independently checked. PeeringDB's IXSY row is useful, but a fuller view would include current upstream transit, private-network arrangements, route monitoring, historical stability and policy clarity. The writer should not punish a company for not disclosing everything publicly. But buyers should know which questions remain unanswered by the public record.

The evidence gap is therefore actionable. It tells an enterprise buyer what to ask before relying on the service for critical operations. It tells a policy reader why registry and route visibility are necessary but limited public evidence. It tells a local market observer that the provider is visible enough to monitor, but not transparent enough to classify as resilient from open sources alone.

The fair reading is a bounded regional-ISP profile

AITelecom belongs in the regional ISP frame because the strongest sources point to access and connectivity: wireless networks, satellite options, tariff references, AS28396, three routed prefixes and one disclosed exchange connection. The evidence is not best understood as a cloud-service or data-center story. The source set does not support those stronger infrastructure claims.

The primary category should therefore sit at the Latin America regional ISP leaf, with topics around network-resource evidence, peering and transit, regional ISP economics and wholesale/access economics. Those labels reflect what is actually visible: the company presents a regional connectivity service, and its network-resource footprint gives analysts a way to examine the edge. The labels should not imply a complete technical audit.

The public picture is neither empty nor conclusive. It is richer than a stub because it includes first-party services, regulatory-facing tariff language, a LACNIC ASN, RIPEstat route observations and PeeringDB interconnection data. It is thinner than a resilience proof because the access layer, upstream diversity, power, repair resources, customer density and current product terms remain undisclosed.

That balance is the point of the article. AITelecom is visible enough to matter. AS28396 anchors the public internet side. The IXSY record adds an exchange surface. The service pages explain why the company is relevant to remote and organizational connectivity. But resilience is not created by visibility alone. It is created by design, investment and operations across the path a customer actually uses.

What buyers should ask before relying on the link

The practical value of a bounded public record is that it turns vague concern into a checklist. A buyer considering AITelecom service does not need to accuse the provider of weakness. The buyer needs to ask which parts of the chain are proven by contract, measurement or operating practice. The sources reviewed here make that checklist more precise.

The first question is the access medium at the exact site. If service is delivered by wireless, the buyer should ask about line-of-sight survey results, radio model, mounting responsibility, weatherproofing, local interference expectations and the handoff inside the premises. If service is delivered by satellite, the buyer should ask which satellite service is used, whether it is primary or backup, what latency is expected, who maintains the terminal, and what happens when equipment fails. If fibre or another terrestrial path is involved, the buyer should ask who owns or controls the last segment and where the handoff occurs.

The second question is upstream independence. AS28396 and the IXSY row make the public edge visible, but they do not say how customer traffic leaves the local access network under stress. A buyer should ask for the current upstream design, whether more than one external provider is active, whether paths share a building, duct, pole route or powered room, and whether routing changes have been tested rather than merely configured. A diagram can be helpful only if it distinguishes logical routing diversity from physical path diversity.

The third question is power. For remote or semi-remote access, power can be a bigger failure driver than routing. A customer should ask which pieces have backup power, how long that power is maintained, how batteries are monitored, and what failure at the customer premises remains the customer's responsibility. A provider's core may remain reachable while a local radio, cabinet or premises device is dark. Resilience is only as strong as the weakest powered point in the service chain.

The fourth question is repair time. AITelecom's public sources do not disclose field crew distribution, spare inventory or service-level remedies. Buyers should ask what response means, what restoration means, whether weekend or holiday faults are handled differently, and whether remote sites carry different repair assumptions. The answer may vary by service tier, location and access technology. That variation should be explicit before the connection is treated as critical infrastructure.

The fifth question is measurement. Customers often buy a speed tier and then discover that the relevant performance problem is not the headline speed. Packet loss, jitter, evening congestion, routing detours and application-specific latency can matter more than a nominal downlink number. If a service is important, the buyer should ask what is measured, who can see the measurements, and whether the provider can supply evidence when a dispute arises. Public route visibility cannot replace service-specific telemetry.

These questions do not require public disclosure of sensitive network details. They require enough customer-level clarity to separate a general connectivity claim from the resilience required by the use case. A small office using the link as secondary internet may accept a different answer than a clinic, mine, industrial site or remote public-service installation. The public evidence establishes why AITelecom is a relevant provider to ask. It does not remove the need to ask.

Monitoring should focus on change, not just presence

For an outside observer, AITelecom's current source set also suggests what should be watched over time. The first signal is route stability around AS28396. If the three observed /24 routes remain stable, disappear, move origin, or split across different patterns, the change would be worth reviewing. A stable route does not prove resilience, but a change can expose a new question about upstream dependency, registry updates or operating transition.

The second signal is PeeringDB disclosure. The current public record shows one operational IXSY netixlan row. A new exchange, a removed row, a changed speed field or a policy change would not settle the customer question, but it would shift the evidence boundary. Because PeeringDB is self-reported, changes should be treated as prompts for verification rather than as final facts. Still, the record is a useful place to watch how the network chooses to present itself.

The third signal is regulatory and tariff language. AITelecom's legal page points to tariff folios but does not reproduce the current terms in the reviewed source set. If new IFT material becomes available or the company updates the legal page, the change could clarify which offers are active and how service terms are framed. The important point is not to chase tariff numbers for their own sake. It is to connect commercial terms with the operational commitments customers actually depend on.

The fourth signal is the company's own service language. If AITelecom adds a coverage map, publishes clearer satellite terms, identifies business-service dependencies, or separates wireless, fibre and satellite products more explicitly, the public analysis can become less speculative. If the site expands data-center-labelled services without adding operating evidence, the boundary should remain firm. More menu items are not the same as more proof.

Monitoring should also resist false precision. It is easy to count prefixes, ports and folios because they are discrete public entities. The more important variables, such as field repair capacity, access density, backup power and customer-premises responsibility, are harder to see. A serious watch process should not confuse measurable public artifacts with the full system. It should use those artifacts to decide what must be verified next.

That is why the current conclusion is durable even if individual signals change. If AS28396 adds a route, the provider becomes more visible but not automatically more resilient. If PeeringDB adds a second exchange row, the article would need to ask whether the new row represents physical diversity or another logical surface behind shared dependencies. If service pages add new claims, the same rule applies: claims become stronger only when evidence binds them to actual operations.

For now, the evidence makes AITelecom a credible subject for regional access monitoring. It does not make the customer bill self-explanatory. The bill still hides the access medium, upstream path, power, field operation and repair model. Those are the parts that determine whether a visible network becomes a dependable service.

For Mara Voss coverage, the careful title is not a hedge. It is the answer supported by the sources. AS28396 makes AITelecom visible, but not the resilience behind the access bill.

The same boundary should guide any later update. New routes, new tariff references or a revised service page would matter, but each should be tied back to the same operating questions: what changed at the access layer, what changed at the handoff, what changed for repair, and what changed for the customer when something breaks. Until those layers are shown, public visibility remains the opening evidence, not the final judgment for customers who must keep working during local faults.

Sources