Summary
- Radar Internet's website publishes CNPJ 10.242.083/0001-89 and an Anapolis address. Casa dos Dados reports that the same identifier belongs to the active head office of RADAR WISP LTDA, whose trade name is RADAR INTERNET.
- The company markets fibre internet, television and digital services, provides residential and business contact paths and exposes subscriber functions for service and billing. Its claims about longevity, municipality reach, plan speeds, coverage and quality remain first-party representations.
- IPinfo associates AS262880 with RADAR WISP LTDA, identifies it as a LACNIC-registered ISP and displays IPv4 and IPv6 resources plus observed network relationships. Those observations do not reveal contracts, traffic, capacity or physical paths.
- Radar's operator-maintained PeeringDB profile describes a regional ISP with an open peering policy and lists operational IX.br connections in Brasilia, Goiania and Sao Paulo. Exchange presence can broaden interconnection options, but it does not establish independent routes or successful failover.
- The decisive customer questions concern the hidden handoffs: whether an address is serviceable, which access medium and equipment are involved, where provider responsibility ends, how faults are escalated, what restoration evidence exists and how a customer can leave without losing operational control.
Two public windows onto the same service
Radar Internet is visible in two ways that are individually useful and jointly incomplete. The first is the retail window. Its live website advertises fibre internet alongside television and other digital services. It offers a residential route into the company, a separate business contact path and subscriber functions associated with account service and billing. In that window, connectivity is a product: a prospective customer checks what is offered, chooses a plan and expects the provider to turn the choice into a working connection.
The second window is the internet's routing layer. IPinfo identifies AS262880 as RADAR WISP LTDA, classifies it as an ISP and places the resource registration in LACNIC. The page displays public IPv4 and IPv6 resources and observed upstream and downstream relationships. PeeringDB connects the same autonomous-system number to Radar Wisp, RADAR WISP LTDA and the Radar Internet brand. It describes the network as regional, gives it a cable, DSL and ISP classification, publishes an open peering policy and lists operational IX.br connections in Brasilia, Goiania and Sao Paulo.
These records make the company more legible. They show that the name on the retail surface is connected to a legal counterparty and a public network identity. They also provide evidence that Radar presents an interconnection surface beyond one customer-facing website. None of them, however, is a complete service map. A routing observation does not reveal how a cable reaches a house. A service page does not show which routes carry traffic after it leaves the local access network. An exchange listing does not say whether two apparent paths share fibre, power or an upstream supplier.
The gap matters because the customer experiences the whole chain as one product. If a video call fails, the user does not initially know whether the problem is indoor Wi-Fi, a customer-edge device, an access segment, local power, backhaul, an external route, a remote service or congestion somewhere outside Radar's control. The commercial relationship nevertheless starts with Radar. The provider's operational value lies partly in diagnosing that chain, taking responsibility for the layers it controls and coordinating the layers it obtains from others.
The distinction also protects against two opposite errors. It would be wrong to reduce Radar to a marketing brand merely because the physical network is not documented in the four public sources; AS262880 and the PeeringDB profile are substantive operating signals. It would be equally wrong to convert those signals into an independently verified picture of fibre ownership, coverage, capacity or resilience. The responsible account stays between those extremes and asks how the visible pieces are joined.
A legal identity gives accountability a starting point
The cleanest link in the public record is the corporate identity. Radar Internet's website publishes CNPJ 10.242.083/0001-89 in its footer and gives an address in Anapolis, Goias. Casa dos Dados maps that identifier to RADAR WISP LTDA and the trade name RADAR INTERNET. It reports an active head office in Anapolis and lists multimedia communication services as the principal economic activity. The page says its underlying Receita Federal information was consulted on 11 July 2026.
That alignment is useful for a customer because a brand can otherwise sit at some distance from the entity that issues an invoice or signs a service agreement. A CNPJ and legal name provide a counterparty against which commercial terms, account authority and formal notices can be organised. The connection between website, legal name and network-resource identity also reduces the risk of discussing three unrelated organisations simply because they share similar words.
The evidence remains bounded. Casa dos Dados is a third-party presentation of information attributed to Receita Federal, not a direct Receita Federal certificate obtained for this article. The accepted sources do not include a current direct Anatel authorisation check. They also do not resolve every detail of the location descriptions published by the website and the corporate-data page. An address can be a head office, customer-service point, administrative site or something else; it should not be turned into evidence of a network operating centre, equipment room or owned facility.
Legal identity does not settle operational responsibility either. The company named on the contract may use landlords, pole owners, construction contractors, wholesale carriers, exchange operators, equipment suppliers or field technicians. The public material does not identify that supplier chain. A customer usually should not have to negotiate separately with every supplier, but it benefits from knowing which obligations remain with Radar and which events depend on another party's intervention.
This becomes especially important during a fault. The subscriber may report the problem to the brand displayed on the bill. Radar may then need to determine whether the issue is inside the premises, at the local handoff, on a shared access element or beyond its autonomous network. The customer needs one accountable contact even when the diagnosis crosses several organisations. The legal counterparty gives that process a clear beginning, while the service terms should define how far the obligation extends.
Identity also matters at exit. Equipment returns, final billing, account closure, number or service changes and access to records should be handled against the correct company. A business customer may need documentation that survives a change of employee or contractor. Keeping the legal name, CNPJ, account number and independent contact route together is a modest control, but it reduces confusion precisely when the usual customer portal or connection is unavailable.
The available corporate facts therefore support a narrow conclusion. RADAR WISP LTDA, the Radar Internet brand and CNPJ 10.242.083/0001-89 are publicly connected. That is enough to anchor accountability. It is not enough to infer ownership of every asset, direct regulatory verification, the role of every branch or the identity of every person who operates the service.
The fibre promise begins with an address, not a municipality
Radar says on its own site that it has more than 17 years in the market and serves more than 50 municipalities. It names Brasilia, Goiania, Anapolis and Rio Verde among examples and displays residential offers with stated speeds. Those claims describe the scale and reach the company wishes to present. The four-reference does not independently verify each municipality, each serviceable address, the launch history or the throughput received by customers.
For a buyer, the difference between municipal presence and address-level availability is fundamental. A provider can operate somewhere in a municipality without reaching every street, building or rural property. Even within one neighbourhood, the serviceable medium and installation work can vary. A route may stop on the other side of a road. A building may need permission for internal cabling. A customer in a shared property may depend on common equipment or power. None of those possibilities can be settled by the municipality list.
The phrase "fibre internet" also needs an explicit handoff. It can describe a service whose final delivery reaches the premises by fibre, but the website alone does not prove the construction, ownership or topology at every address. A customer should ask what medium will actually be installed, where it terminates, which equipment is included and what work must occur on private or shared property. The answer should be tied to the service address rather than inferred from a broad coverage statement.
Plan speed is another boundary. A displayed speed describes a commercial offer. It does not by itself establish universal availability, sustained throughput, performance over Wi-Fi or speed to every destination. The local access link is only one part of the path. The customer device, indoor radio conditions, home router, remote server and wider internet can all influence an observed result. A fair assessment separates the rate sold at the handoff from the performance of a particular application.
That separation protects both parties. A customer who tests only on a distant wireless device may attribute an indoor coverage problem to the outside line. A provider who points only to a link test may overlook an installation choice that makes the service difficult to use in the actual premises. The useful installation record states where the service enters, how the customer-edge device is connected and which side is responsible for the internal network.
Business users need a more detailed version of the same record. They may require a fixed installation window, public addressing, particular router control, support authority for an IT contractor or a clear demarcation between provider equipment and an office firewall. The Radar site provides a business contact route, which establishes a place to begin that discussion. It does not publish enough evidence to assume any particular business feature, service level or restoration commitment.
Address qualification is therefore the first real operating test. It converts a regional claim into a specific obligation: this location, this medium, this installation, this equipment and these terms. A municipality count can help a provider explain its footprint, but customer resilience begins only when the broad map becomes a written handoff.
The last mile is the least visible part of the public record
The four sources say little about the physical path between a Radar customer and the wider network. They do not identify individual fibre routes, pole rights, ducts, towers, radio sites, splice points, shared building equipment, local power arrangements or field-repair depots. They do not establish which components Radar owns, leases or accesses through another provider. That absence is not evidence that the resources do not exist. It is a warning against drawing a detailed network from corporate and routing records.
This hidden layer is where many practical distinctions arise. A local access fault can affect one customer because of a damaged connector or customer-edge device. It can affect a building because of common equipment. It can affect a street or wider area because a shared segment, power source or backhaul path has failed. The symptoms may look similar from inside the premises, but the diagnosis, permissions and repair work differ.
Physical diversity is particularly easy to overstate. Two commercial services may have different names, routers or autonomous-system paths while sharing a duct, pole line, building entrance or power supply. Conversely, one provider may have alternative arrangements that are not apparent in public records. The PeeringDB connections in three cities do not answer the local question. An exchange presence concerns interconnection at a network edge; it does not document the route from a particular customer address to that edge.
A customer seeking continuity should therefore ask about failure domains rather than merely buying a second label. For a household, a mobile connection may be sufficient for essential communication. For a business, the requirement may include a separate physical entrance, a different access medium or a backup that can support only critical systems. The appropriate design depends on the cost of interruption and on which common dependencies can be tolerated.
Repair access is part of the physical design. A provider may need entry to a building, a riser, a roof, a cabinet or customer equipment. A landlord or site manager may control that entry. Work may require a power check before a field visit. The public sources do not describe Radar's repair process or staffing, so no restoration time should be inferred. A customer can still reduce delay by documenting the service location, keeping contact details current and ensuring that authorised people can grant access when required.
Equipment ownership also affects repair and exit. If Radar supplies a router or optical device, the agreement should say whether it remains provider property, who can change its configuration and what must be returned. If the customer supplies equipment, compatibility and support boundaries should be clear. A device can be physically inside the premises while remaining logically managed by the provider; location alone does not determine responsibility.
The correct public conclusion is deliberately restrained. Radar markets fibre access, but the accepted evidence does not establish universal fibre-to-the-premises availability or a company-owned route to every customer. The physical last mile remains an address-specific operating fact. That is where the retail promise becomes real, and it is also where a customer needs the most concrete documentation.
The router is a demarcation point and a source of ambiguity
The customer-edge router is often treated as a simple appliance, yet it sits at the meeting point of several responsibilities. On one side is the provider access service. On the other are the customer's devices, applications and indoor network. The device itself may be owned by one party and managed by another. Its settings may determine wireless coverage, address assignment and the way the customer reaches the internet. A failure at that point can resemble a wider outage.
Radar's public website exposes subscriber-service and billing channels, but the accepted material does not define router ownership, management rights or support scope for a particular plan. Those details should come from the order and installation record. The customer should know which equipment was supplied, whether replacement is included, which settings may be changed and how a reset affects the service. A business should also know whether its own firewall or router can be used and where Radar's diagnostic responsibility ends.
Indoor Wi-Fi deserves separate treatment from the outside connection. Walls, distance, neighbouring radios and device capabilities can affect local performance even when the access link is healthy. This does not mean every complaint is a customer problem. The provider may supply or manage the wireless device as part of its proposition. It means that diagnosis should distinguish the radio inside the premises from the line arriving there.
Power creates another shared boundary. Customer-edge equipment normally needs power at the premises. A local electricity interruption can therefore remove service even if the provider network remains available. The four sources provide no evidence about backup power at customer sites or across Radar's network, so resilience should not be assumed. A customer who needs connectivity during local power loss must identify which devices require power and whether its own backup arrangement supports them.
Configuration authority matters during both normal use and incidents. A provider-managed device may allow faster standard support but give the customer less direct control. Customer-managed equipment can support a tailored network but may create a sharper support boundary. Neither arrangement is inherently superior. The risk comes from ambiguity: both parties believe the other controls a setting, or an emergency reset removes information that no one has recorded.
The handoff record can be short. It should identify the access medium, device, owner, management authority, provider contact and customer contact. It should note any customer equipment that must remain connected and any credential-recovery route. It need not expose sensitive passwords. Its purpose is to make the first diagnostic decisions possible when the usual account holder or technician is absent.
For Radar, this demarcation is where a broad regional service becomes a repeatable operating relationship. For the customer, it is where responsibility can be tested without making unsupported assumptions about the rest of the network. A visible AS number may explain who administers routes at the internet edge. The router record explains who can act at the point where the service enters daily life.
AS262880 shows routing agency, not a complete network
An autonomous-system number is a durable clue about network administration. IPinfo associates AS262880 with RADAR WISP LTDA, identifies the network as an ISP and displays IPv4 and IPv6 resources. PeeringDB binds the same number to Radar's legal and retail identities. Those records support the conclusion that Radar presents a distinct routing identity rather than only a customer-facing name.
That identity matters because routing is how networks announce reachability and exchange traffic with other networks. Operating an autonomous system can give an ISP a policy surface at which it selects external relationships and manages address resources. It can make the operator visible to peers and other network entities. PeeringDB's publication of a network-operations contact adds a practical point through which technical coordination can begin.
The number does not reveal the whole service. IPinfo's displayed address resources do not equal active customers, traffic or revenue. The size of an allocation does not show how efficiently it is used, which products depend on it or whether every address is currently announced. IPv6 visibility is relevant to technical capability, but it does not prove that every retail customer receives IPv6 or that every application works through it.
Observed network relationships require similar caution. IPinfo reports upstream and downstream observations, but a public observation does not disclose the contract behind a route. It cannot determine from that label alone whether an arrangement is paid transit, private peering, settlement-free exchange, backup service or a temporary routing state. Roles can change with time and with the path being observed. Commercial terms remain private unless separately disclosed.
Routing visibility also stops short of physical geography. A route can be announced through equipment in one place and carried over transport supplied by another company. Two logical neighbours can be reached through a common facility or fibre system. A customer packet can follow different paths according to destination, policy and current conditions. AS262880 therefore cannot be used to draw a verified fibre map or to claim independent routes.
Nor does an autonomous system guarantee performance. Routing policy can create options, but usable service depends on capacity, equipment, transport, operations and the remote networks involved. The accepted sources contain no measurements of traffic, congestion, latency, loss, uptime or failover. They also contain no contract-quality evidence for capacity. It would be wrong to translate the existence of the ASN into a promise about any of those outcomes.
The defensible interpretation is still important. AS262880 establishes a public network identity associated with RADAR WISP LTDA and Radar Internet. It gives the company a visible role in coordinating reachability beyond the local customer handoff. That is stronger evidence than a retail page alone. Its value lies in showing an operating surface and in framing better questions, not in answering every question about the physical network.
Three exchange cities expand the questions, not the guarantees
Radar's PeeringDB profile lists operational IX.br connections in Brasilia, Goiania and Sao Paulo. The same profile describes the network as regional, classifies it as cable, DSL and ISP and publishes an open peering policy. Because PeeringDB entries are maintained by network operators, these details should be read as Radar's current public interconnection presentation rather than an independent measurement of every connection.
Exchange participation can matter for a regional ISP. An internet exchange provides a place where participating networks can interconnect, subject to their technical and commercial arrangements. Direct exchange may give an operator more options for reaching some networks and can reduce dependence on a single form of external connectivity. An open policy signals willingness to consider peering, although it does not compel another network to connect or specify the terms.
The three-city listing is therefore evidence of an outward-facing interconnection strategy. It suggests that Radar presents itself to the network community at more than one exchange location. It is not proof that customer traffic is evenly distributed across the three cities, that every listed connection carries traffic at all times or that all destinations are reached there. A route to a network not present at an exchange may still require another provider.
Geographic multiplicity is not automatically physical diversity. Connections in Brasilia, Goiania and Sao Paulo may involve separate systems, but the public profile does not show the transport paths from Radar's access areas to those points. It does not identify shared fibre, facilities, suppliers, power or operational control. One exchange connection can fail while another remains technically listed but inaccessible from the affected part of the network. Only current design and operating evidence could establish the actual failure boundaries.
Port and traffic fields, when displayed on an operator-maintained profile, also need attribution and context. A listed port speed is a property of an interface entry, not proof of available customer capacity. A reported traffic range is not a measured service commitment. Neither can establish congestion-free delivery or a customer's performance. This article does not use those fields to make a capacity claim.
For a technically sophisticated customer, the exchange footprint can prompt useful questions. Does a business product have a stated external-connectivity design? How does Radar communicate a broad routing incident? Are backup arrangements tested, and are they relevant to the customer's access area? Which commitments are contractual and which describe a current design that may change? The public profile gives context, while the provider must supply any service-specific answer.
For most households, the direct practical value is less visible. The user wants a website, call or stream to work. The exchange strategy matters insofar as it helps Radar deliver that outcome and diagnose failures. It should not require the customer to become a routing specialist. Radar's role is to translate interconnection options into a stable service and to remain the accountable contact when an external relationship affects that service.
The exchange entries thus occupy a useful middle ground. They show more than a generic promise of connectivity but less than a verified resilience design. They are evidence of where Radar says it interconnects, not proof of what every packet does or what happens during every failure.
Support turns a network design into a customer service
Radar's website provides subscriber-service and billing channels and separates residential and business contact paths. That is evidence of a current customer operation rather than a bare corporate registration. It gives users visible ways to begin an order, account or support interaction. The public material does not, however, disclose staffing levels, ticket performance, spares, field resources, outage history or restoration times.
The difference between contact availability and resolution capability matters. A channel can accept a message immediately while diagnosis takes longer. The first responder may need account details, device status and evidence about the affected area. A field visit may depend on access permission or replacement equipment. A wider network incident may require another organisation. None of this diminishes the value of an accessible channel; it explains why response and restoration should not be conflated.
A good incident report starts with scope. Is one device affected, every device at one premises, several known customers or a wider area? Are the customer-edge devices powered? Does a wired test differ from Wi-Fi? Is the account current? Did the problem begin after a local change? These questions help locate the handoff without presuming that the customer caused the fault or that the provider did.
Business customers need authority to be explicit. Radar should know who may request a configuration or service change. The customer should keep an independent way to reach support if the primary connection is unavailable. Account details and the installed-service record should remain accessible to more than one authorised person. A billing issue can interrupt service through a different chain from a physical cut, yet both are experienced as loss of connectivity.
Field repair introduces another set of handoffs. A remote diagnostic may identify a likely access fault, but physical work can require a technician, site access, replacement material and safe working conditions. The accepted sources do not identify Radar's crew structure or contractor arrangements. It is therefore improper to make either a positive or negative claim about repair speed. The practical customer question is what information and access will be needed when a visit becomes necessary.
Communication during a wider incident is part of the product. A precise update can prevent customers from repeatedly resetting equipment or opening duplicate cases. It can state the known scope, the next checkpoint and whether customer action is required. It should distinguish what Radar has observed from what remains under investigation. Public evidence does not show how Radar handles such events, but the presence of service channels creates a surface through which that performance can be evaluated.
Support history can also improve future design. Repeated local power issues suggest one remedy; recurring indoor wireless complaints suggest another; a shared transport incident raises a different continuity question. A customer and provider can use incident records to decide whether equipment, service scope or backup arrangements should change. Broad quality language on a sales page cannot replace that evidence.
Radar's customer surface is therefore operationally meaningful but not self-proving. It shows that the company offers places for residential and business users to engage and for subscribers to manage service and billing. Reliability emerges from what happens after contact: diagnosis, ownership, escalation, repair and learning. Those are exactly the elements the public record leaves open.
Resilience must be demonstrated at the relevant failure boundary
Resilience is often discussed as if it were a single property of a network. In practice, it depends on the failure being considered. A second external route does not keep an unpowered customer router running. Backup power does not repair a cut access segment. A second access service does not help if it enters through the same damaged path. A well-designed exchange strategy does not restore a customer account suspended through an administrative error.
The public evidence for Radar does not establish route diversity, backup power, spare equipment, congestion margins, failover behaviour or restoration performance. Its website's coverage and quality statements remain first-party marketing claims. The ASN and exchange records do not fill those gaps. A defensible analysis must therefore avoid the shortcut of labelling the service resilient or fragile.
Customers can instead define a small number of critical scenarios. For a home worker, local power, indoor equipment and one access line may dominate. For a shop, payment connectivity and a support contact may be critical. For a multi-site business, the external routes and the independence of access at each site may matter more. The scenario identifies which component needs an alternative and how long interruption can be tolerated.
A backup service should be tested against that purpose. If it uses a mobile network, will it work inside the premises and support the necessary devices? If it is another fixed line, does it have a genuinely different physical handoff? If the same router manages both, what happens when that router fails? The answers are address- and design-specific. Radar's public footprint cannot supply them.
Operational testing should also include people and authority. Can someone find the account details during an outage? Can a business switch the essential devices without its usual technician? Can a case be opened through a different connection? Is the person who can approve site access reachable? These controls are inexpensive compared with elaborate redundancy, yet they often determine whether a nominal backup can actually be used.
Radar's three listed exchange cities may be relevant to network-level alternatives, but they should not be used as a proxy for customer-level continuity. The path from a particular address to each interconnection point is unknown. The profile does not prove that the connections are independent or that traffic can fail over under every condition. Service-specific evidence must bridge that gap.
This approach avoids demanding disclosure of sensitive network details. A provider does not need to publish exact routes or security arrangements to give a customer meaningful assurance. It can define the service boundary, state applicable commitments, explain escalation and provide evidence from tests or incident reviews at an appropriate level. The customer can then decide whether residual uncertainty fits its risk.
Resilience becomes credible when it is attached to a scenario, a boundary and evidence. Without those, the word is only a broad claim. The same discipline applies to uptime, low latency, capacity and fast repair: none should be inferred from Radar's marketing reach, address resources or exchange listings.
What households and businesses can verify before ordering
The public record is sufficient to support a disciplined buying conversation. It identifies RADAR WISP LTDA and CNPJ 10.242.083/0001-89, connects that company to Radar Internet and AS262880 and shows a live retail and interconnection surface. A buyer can use those anchors while asking for details specific to the address and intended use.
The first questions concern installation. Is the location serviceable now? What access medium will be used? Where will it enter the premises? Which equipment is supplied, who owns it and who manages it? Are non-standard construction or property permissions required? The written answer turns "fibre internet" into an inspectable handoff without asking Radar to reveal a wider physical map.
The next questions concern the commercial service. Which speed and usage terms apply at this address? Which aspects of performance are measured at the provider handoff, and which depend on the customer's internal network? How are changes, cancellation and equipment return handled? The displayed offers are a starting point, but the order should control the actual commitment.
Support questions should distinguish channels and outcomes. Which contact should a residential customer use? Is there a different route for a business incident? What information speeds diagnosis? How are widespread incidents communicated? When might a field visit be required, and who must provide access? The public website establishes that service channels exist, not their response distribution or restoration result.
Continuity questions should reflect the customer's workload. Does the household need connectivity during local power loss? Does the business need an independent backup for payments, voice or remote work? Would a proposed alternative share the same entrance or equipment? The customer need not buy maximum redundancy. It should avoid paying for two labels that fail at the same boundary.
Account control is another practical test. More than one authorised person should know the legal customer name, account route and recovery procedure. The organisation should keep its own record of installed equipment and any provider property. A business should clarify whether an external IT contractor may speak to Radar and what proof of authority is required. These controls become valuable during staff changes as well as outages.
Routing information can inform a more technical review without becoming a performance guarantee. AS262880 and the PeeringDB profile show a public network identity and listed IX.br connections. A business with material dependence on connectivity can ask Radar how its proposed service handles external incidents and what commitments apply. It should not assume contracted capacity or diversity from an observed neighbour or exchange port.
Finally, a buyer should preserve an exit route. It should know how to cancel, return equipment, retrieve records and replace the service. If the business depends on internet-based applications, those accounts and data should not be controlled solely through an email address or connection that may disappear during a dispute or transition. Connectivity is easier to replace when identity, authority and technical handoffs remain legible.
These questions are not allegations about Radar. They are ordinary controls for any regional access service. Radar's public evidence is useful precisely because it identifies enough of the operating surface to ask them accurately while leaving unsupported physical and performance claims aside.
The evidence sets a firm boundary around the conclusion
The identity evidence is consistent within a defined limit. Radar Internet publishes CNPJ 10.242.083/0001-89. Casa dos Dados reports that the number belongs to RADAR WISP LTDA, trading as RADAR INTERNET, and describes an active head office in Anapolis with multimedia communication services as its principal activity. IPinfo and PeeringDB associate AS262880 with the same legal and retail names.
The customer surface is also current and specific. Radar's site markets fibre internet, television and digital services, offers residential and business contact routes and exposes subscriber-service and billing functions. It claims more than 17 years in the market, more than 50 municipalities and various plan speeds and service qualities. Those scale and performance statements are Radar's representations; they were not independently measured in the four-source set.
The network-resource evidence adds a distinct layer. IPinfo displays IPv4 and IPv6 resources and observed network relationships for AS262880. PeeringDB describes a regional ISP, publishes an open peering policy and lists operational IX.br connections in Brasilia, Goiania and Sao Paulo. The observations are time-sensitive, and the PeeringDB profile is operator-maintained.
What remains unknown is at least as important. The sources do not prove direct current Receita Federal or Anatel status. They do not map fibre routes, wireless sites, pole or tower rights, facilities, backhaul contracts, field resources or customer equipment. They do not establish who owns or leases every physical element. They do not identify contractual upstream roles, traffic distribution, usable capacity, congestion, uptime, customer count, market share or outage history.
The sources also cannot establish universal fibre coverage or measured service performance. A listed municipality does not make every address serviceable. A plan speed is not a result for every customer or destination. An exchange connection is not a guarantee of diverse transport. An observed routing relationship is not a disclosed commercial contract. A legal address is not proof of an operating facility.
These limits do not make the evidence weak. They determine which questions it can answer. The record can answer who presents the service, which legal entity and CNPJ are publicly attached to it, which autonomous-system identity is associated with the company and where the operator says it interconnects. It can show the existence of customer and network-operation surfaces. It cannot certify how every layer performs.
That boundary supports a balanced judgement. Radar is not merely an abstract name: the company has a legally anchored retail surface and a visible routing and interconnection identity. At the same time, the evidence does not justify describing a verified estate of company-owned fibre, towers, facilities, diverse paths or guaranteed capacity. The operating reality must be evaluated at the handoffs where those public surfaces meet.
Radar's real product is accountable coordination
A regional ISP creates value by joining local access to a much larger system. The work includes qualifying an address, arranging installation, managing the customer edge, administering network resources, selecting external connectivity, receiving fault reports and coordinating repair. Some components may be owned, others leased or supplied. The customer experiences the result as one relationship.
Radar's public footprint illuminates several parts of that role. The legal identity and CNPJ identify the counterparty. The website shows the retail and subscriber surface. AS262880 shows a distinct routing identity. The PeeringDB profile shows an outward-facing interconnection posture in three listed cities. Together they establish more than a marketing promise, while stopping short of a complete operational map.
The missing map should not be filled with confident assumptions. It should be filled, where necessary, with service-specific evidence: an address qualification, an installation record, a responsibility boundary, applicable terms, an escalation path and a tested continuity arrangement. Those items are less dramatic than a network diagram, but they are more useful to the person whose connection has failed.
For Radar, accountability means remaining the customer's organising point across layers. A fault may ultimately involve indoor equipment, a local access segment, transport, an exchange relationship or a remote network. The provider need not control the whole internet to give a clear diagnosis and next step. It must make its own scope clear and coordinate the dependencies that sit behind the service it sells.
For the customer, accountability includes maintaining power, access, authorised contacts, internal equipment and a realistic backup where the workload requires one. Shared responsibility should be explicit, not used to send the customer in circles. The legal and technical boundaries should make action easier under pressure.
The strongest conclusion available from the evidence is consequently narrower than a claim about coverage or resilience and more useful than a list of route records. RADAR WISP LTDA operates a visible regional retail and network identity through Radar Internet and AS262880. Its service matters at the junction between a promised connection and the hidden chain required to sustain it.
The quality of that junction cannot be read from an ASN allocation, a municipality count or three exchange entries. It is demonstrated one address and one incident at a time: the right medium is installed, the handoff is understood, external reachability is managed, support identifies the failing boundary and repair returns the customer to service. That is the standard by which the broad fibre promise becomes accountable connectivity.