Summary
- Registro.br ties AS28126 to the Brisanet legal entity and CNPJ, while PeeringDB records declared interconnection.
- The ASN identifies a public routing domain, but live routes, physical diversity, customer quality and outage response require separate evidence.
What the public record says
The most specific record is the official RDAP response for autonomous system 28126. RDAP stands for Registration Data Access Protocol. It is a standard way to retrieve structured registration data for internet resources. The Registro.br response describes AS28126 as a direct allocation and names BRISANET SERVICOS DE TELECOMUNICACOES S.A. as the registrant. It also shows the company's Brazilian registration number, 04.601.397/0001-28, and links the autonomous-system record to several IPv4 and IPv6 resource records.
That is strong evidence for a narrow set of facts. It connects a legal organisation, a national company identifier and an autonomous-system number in a public registry. It gives engineers and investigators a stable place to begin when they need to identify the party recorded for a number resource. It also reduces a common source of confusion: a brand, a website and a network number can look similar in public databases while belonging to different legal entities. Here, the CNPJ shown in RDAP matches the CNPJ displayed on Brisanet's own company page.
PeeringDB adds a different layer. Its public network page names Brisanet Servicos de Telecomunicacoes and ASN 28126, describes the network as a cable, DSL and internet service provider, and lists exchange connections and interconnection facilities. The page marks connections at locations including IX.br and DE-CIX as operational. It also presents an open peering policy. Peering is the direct exchange of traffic between networks, usually to shorten paths, reduce reliance on paid transit or improve control over how traffic moves.
Brisanet's own website provides the business context. The company says its history began in 1998 in Pereiro, Ceará, that it adopted fibre in the northeastern interior in 2012, and that it won 5G spectrum for Brazil's Northeast and Centre-West in 2021. The page says the company is present in 158 municipalities and serves more than 1.4 million customers. These are company statements, not independent measurements, but they explain why the routing identity matters: AS28126 is attached to an operator that presents itself as serving a broad regional footprint across fixed and mobile services.
The three sources therefore form a useful chain. RDAP records the number-resource identity. PeeringDB describes declared interconnection. The company page describes the commercial and geographic operation. The chain is meaningful precisely because its limits remain visible. It does not automatically prove the state of every route, circuit or household connection.
An ASN in everyday language
An Autonomous System Number, usually shortened to ASN, sounds more mysterious than it is. Imagine the public internet as a huge collection of independently managed road systems. Each network decides which destinations it can reach and which neighbouring networks it will use to get there. An ASN is the public number attached to one of those routing decision-makers. It lets other networks recognise the source of route announcements and apply routing policies consistently.
The word "autonomous" does not mean isolated or politically sovereign. It means that the network presents a coherent routing policy to other networks. A company can operate more than one ASN. Several companies can also be connected through a parent, reseller or infrastructure partner. An ASN does not tell a reader how many employees work in a network room, how many kilometres of cable exist, which towers are owned, or whether a particular home is online.
Networks use the Border Gateway Protocol, or BGP, to exchange reachability information. A BGP announcement essentially says, "traffic for this group of IP addresses can be sent in this direction." The group of addresses is called a prefix. Other networks compare the announcements they receive and select paths according to technical and commercial policies. The path may change when a link fails, a provider changes policy, a new connection comes online or maintenance takes place.
The registry layer and the routing layer are related but not identical. A registry record can show that an organisation is recorded for an ASN or an address block. A route collector can show that a prefix was observed in BGP at a particular time. A traceroute can show one sampled path from one measurement point. A customer speed test can show the experience of one line at one moment. Each observation answers a different question.
This distinction matters because readers often treat an ASN page as a complete network map. It is not. AS28126 gives Brisanet a public routing identity, but the number does not contain an inventory of every access network, upstream provider, private interconnection, internal router, shared duct or customer modem. It is closer to a clearly labelled entrance in the public routing system than a blueprint of the entire building.
The registry is a ledger, not an operating certificate
Internet registries perform an essential recordkeeping function. Public IP addresses and autonomous-system numbers need uniqueness. If unrelated networks tried to use the same resources without coordination, traffic could go to the wrong place or become unreachable. Registries help maintain the chain of allocations, assignments, contacts and related metadata that makes technical coordination possible.
The RDAP record for AS28126 should therefore be taken seriously. It is the authoritative registration interface for the resource in Brazil. It identifies the recorded registrant and offers links to related resource entities. During an incident, that information can help an engineer determine which organisation to contact and which registry entity needs closer inspection. During due diligence, it can help a buyer separate a legal entity from a trade name.
But an authoritative registry record is not an operating certificate. It does not certify that every route is being announced correctly. It does not test whether traffic can reach every prefix. It does not verify that abuse contacts respond within a certain time. It does not measure latency, packet loss, capacity or repair performance. It does not prove that the registrant physically owns all infrastructure used to deliver a service.
This is an important limit, not a criticism of the registry. A ledger should be accurate about the facts it records. It should not be expected to replace the systems it describes. A land registry can identify recorded ownership without telling a visitor whether a building's lifts are working. In the same way, RDAP can identify a resource holder without telling a customer whether a neighbourhood fibre line is healthy tonight.
Good network accountability starts by preserving this boundary. The registry entry establishes identity and recorded resource relationships. Current BGP observations establish public route visibility. Operator telemetry establishes internal conditions. Contracts establish promises. Incident reports establish what happened during a failure. Customer measurements establish parts of the lived experience. No single layer can silently substitute for the others.
For Brisanet, the safe conclusion is exact: the public RDAP ledger ties AS28126 to the named company and CNPJ. Any broader statement about current routing, security, physical ownership or service quality requires additional, current evidence.
What PeeringDB adds, and what it cannot add
PeeringDB is widely used by network operators to publish information about where and how they interconnect. A network profile can list an ASN, traffic characteristics, a peering policy, exchange ports and facilities. That helps other operators find potential interconnection points and contact the right organisation. It also gives researchers a useful picture of a network's declared public edge.
The Brisanet profile is substantial. It identifies ASN 28126 and lists connections at Brazilian exchange points as well as international locations. It marks those connections as operational. For a non-specialist, the important point is not the number of rows. It is that an operator serving regional customers can connect to other networks at multiple exchange locations rather than sending all traffic through a single unnamed path.
Direct interconnection can matter to users. If two networks exchange traffic close to customers, a video, payment request or software update may travel a shorter and more controllable path. Multiple exchange points can also provide options when one location has a problem. However, the existence of several listed connections is not proof that every application uses them, that capacity is always sufficient, or that the connections fail independently.
PeeringDB is a network-maintained directory. The data is valuable because operators have an incentive to keep interconnection information useful, but it is not the same as continuous third-party measurement. A row marked operational may change after the page was updated. A session can be technically established but carry little traffic. Two connections can appear diverse while sharing a common facility, cable route, power system or upstream dependency.
The profile also does not expose private topology. Operators often keep internal router design, access aggregation, customer details and security arrangements out of public databases. That is reasonable. Public transparency does not require publishing a blueprint that would create security or commercial risk. It does require clear wording about what the available record can and cannot establish.
Readers should therefore treat PeeringDB as evidence of declared interconnection presence. To answer a live question, such as whether AS28126 is currently visible at a particular exchange or whether a route is preferred through one city, an analyst would need fresh routing and exchange observations. To answer a resilience question, a customer would need a design showing independent paths and tested failure behaviour. The directory points to where evidence may exist; it does not complete every test.
From backbone identity to the last mile
The public internet identity of an operator sits far above the cable entering a home or business. Between the two are several layers. A customer device connects to an optical terminal, radio or other access equipment. That access line reaches a local aggregation point. Traffic then moves through metro or regional transport, enters the operator's core network and eventually reaches other networks through peering or transit.
An ASN is most visible near the public routing edge, where one network tells other networks which prefixes it can reach. A household connection is experienced at the opposite end, where Wi-Fi conditions, local equipment, fibre splices, power, street works and support processes can determine whether a service feels reliable. The same operator name spans both ends, but the evidence needed to understand them is different.
This is why an AS number cannot be a map of every connection. A route may be globally visible while one neighbourhood cabinet has lost power. A customer's line may be healthy while a popular application is slow because of a distant content or transit problem. A local peering connection may shorten traffic to one service while another service follows an international path. An outage can occur inside the home, the access network, the regional backbone, an exchange, an upstream carrier or the destination platform.
Brisanet's company page describes a large customer and municipal footprint. That scale makes the distinction more important. A regional operator must connect many local access environments to a public routing identity. The public ASN is common, while the physical circumstances of each town and customer can differ. Terrain, available ducts, tower locations, power quality, supplier access and repair distance can all shape the real service.
For an ordinary user, the practical question is not "Does my provider have an ASN?" A serious provider needs network identity and interconnection, but the customer should ask what happens to the specific service: how faults are detected, how quickly repair teams can reach the area, whether critical sites have backup power, how capacity is monitored and how support communicates during a wider incident.
For a business customer, the questions become more precise. Which access path reaches the premises? Is there a second path, and does it use a different duct and aggregation point? Which device and power supply are the customer's responsibility? Which targets are monitored? What service levels apply? An ASN is part of the answer because it identifies the public network, but continuity lives in the complete path.
Fibre, 5G and one public identity
Brisanet's own account of its history links fibre expansion in Brazil's northeastern interior with a later move into mobile service. The company says it began in 1998, adopted fibre in the region in 2012 and won 5G spectrum for the Northeast and Centre-West in 2021. These milestones describe different infrastructure systems under a common corporate story.
Fixed fibre and mobile networks can share some backbone and operational resources, but they do not have identical failure modes. Fibre access depends on cables, splitters, cabinets, optical equipment and power across a fixed path. Mobile service depends on radio sites, spectrum, backhaul, core functions and device conditions. Both ultimately need IP transport and interconnection, yet the path from user to public internet is different.
AS28126 helps identify a public routing domain associated with the company, but it should not be used to collapse fixed and mobile operations into one diagram. A mobile network may involve additional identifiers, partners and core systems. A fixed service may use wholesale infrastructure or locally specific access arrangements. Corporate consolidation can also change which legal entity owns an asset, employs staff or signs a customer contract without immediately changing every routing record.
The company page is useful for scale and history, but it is promotional material. Statements about being a pioneer, serving a number of customers or being recognised by a regulator should be attributed to the company unless independently confirmed. That does not make the statements worthless. It means a reader should know which source is speaking.
The same care applies to network numbers. RDAP is stronger than a marketing page for the registrant of AS28126. PeeringDB is more specific than a marketing page for declared interconnection. A live routing collector is more specific for a route observed at a time. A contract is more specific for a customer's service commitment. Evidence becomes clearer when each source is used for its own purpose.
The promise of multiple links
Brisanet's SD-WAN product page offers another useful example of the gap between a product description and an operating result. SD-WAN is software-defined wide-area networking. In simple terms, it can manage traffic across more than one connection and choose how applications use those links. The Brisanet page promotes continuous monitoring, link balancing and the ability to use different forms of connectivity.
Those features can improve business continuity. A shop, clinic or office may use fibre as its main connection and a second service as backup. The SD-WAN equipment can monitor link conditions and move some traffic when the preferred path becomes unavailable. It can also apply priorities so that payment, voice or business applications receive different treatment from less urgent traffic.
However, two links are not automatically two independent routes. Both circuits may enter the building through the same duct. They may reach the same local cabinet, share a power supply or depend on the same upstream network. A mobile backup may use a tower whose backhaul follows the same regional path as the fixed line. A software policy can switch traffic only among paths that remain physically and operationally available.
The product page does not say that every Brisanet customer has SD-WAN, that every deployment uses multiple carriers, or that a particular pair of links is failure-independent. It describes a service the company markets. The actual outcome depends on the contracted design, available access options, configuration, monitoring and tests.
This distinction is especially important for non-technical buyers. Words such as "automatic," "intelligent" and "redundant" can sound like guarantees. A buyer should translate them into testable statements. How quickly is a failure detected? Which applications move? Does an existing session survive? Who receives an alert? How is traffic restored when the main link returns? Are both paths tested under load? Does the service-level agreement cover the combined design or only each component?
The ASN ledger cannot answer those questions, and the product page cannot answer them for an unnamed deployment. The operator and customer must create the operational evidence together.
Routing security is another separate layer
Internet routing includes security mechanisms that help networks judge whether a route announcement is plausible. One important system is the Resource Public Key Infrastructure, or RPKI. A resource holder can publish a Route Origin Authorization, commonly called a ROA, stating which ASN is authorised to originate a particular IP prefix.
RPKI can help networks reject or de-prioritise some invalid route origins. It does not encrypt traffic, prevent every route leak or guarantee availability. A route can be valid under RPKI and still follow an inefficient path. An operator can have correct authorisations and still experience equipment, fibre or power failures. Routing security is one control in a larger operational system.
The RDAP page for AS28126 does not, by itself, establish the current RPKI state of every related prefix. The record links number resources, but a current assessment would need to inspect the exact prefixes and current authorisations. This article therefore makes no claim that all Brisanet routes are covered, valid, invalid or unprotected.
That restraint matters because security labels can travel farther than the evidence. Saying that an operator "uses RPKI" might refer to one prefix, a portion of address space or a policy intention. Saying that an ASN is "secure" is even less precise. A responsible report names the prefix, the authorised origin, the observation time and the validation result.
For businesses, the practical takeaway is not to demand a vague security badge. Ask how the provider manages route objects, who approves changes, how invalid announcements are detected, how contact records are maintained and how incidents are escalated. For public reporting, distinguish registration metadata from route-origin authorisation and from observed BGP behaviour.
Accurate number-resource records matter because incident responders need to know whom to contact and what authority is claimed. Current security entities matter because networks make automated decisions from them. Running configurations matter because even a correct record has no effect if routers are not configured to use it. This is the same ledger-versus-reality boundary seen throughout AS28126.
What customers can reasonably infer
The public evidence supports several practical conclusions. First, Brisanet has a clearly recorded public routing identity in AS28126. The official registry ties that number to the legal company and CNPJ. This is stronger than guessing from a website domain or brand name.
Second, the PeeringDB profile shows that the network declares interconnection at multiple exchange and facility locations. That suggests an operator participating in the wider interconnection ecosystem rather than an access business with no visible public edge. The entries are useful for operators considering peering and for analysts mapping declared presence.
Third, the company presents a substantial regional operation across fibre and mobile services. Its own page gives scale and historical milestones that explain why public routing and interconnection records are relevant to customers, local businesses and other networks.
Customers should not infer a universal quality score from those facts. The records do not show how a specific line performs, whether two circuits are physically diverse, how quickly a local fault is repaired or how a particular application is routed. They also do not reveal every supplier and shared dependency.
Nor should readers infer ownership from visibility. An operator can announce addresses while using leased facilities, wholesale fibre, shared towers, cloud services or third-party transit. That is normal in telecommunications. The accountability question is not whether every asset is owned. It is whether responsibilities, dependencies and escalation paths are known and managed.
The most useful public conclusion is therefore balanced. AS28126 and its related records make Brisanet's network identity more legible. They provide a foundation for technical coordination and further investigation. They do not remove the need for measurements, contracts, architecture diagrams, incident records and customer-specific tests.
A plain-language checklist for a business buyer
A small business does not need to become a BGP expert to buy connectivity carefully. It needs a short list of concrete questions and a willingness to distinguish labels from evidence.
Begin with identity. Ask for the exact contracting company, service name and support contact. Check that invoices, contracts and escalation details use consistent legal names. If an ASN or IP block matters to the service, ask for the exact number rather than accepting a broad brand reference.
Then map the access path. Ask how the connection reaches the building, where the provider handoff occurs and which equipment belongs to each party. If a second link is proposed, ask whether it enters through a different physical route and reaches a different aggregation point. Two contracts can still share one vulnerable cable.
Next, map the public path. Ask whether the service uses provider-assigned addresses or customer-held resources, which ASN announces them and whether inbound and outbound traffic have different dependencies. A customer does not need every internal router name, but it should understand which failures the design is meant to survive.
Ask about monitoring and repair. Which conditions generate an alert? Is the line monitored from outside the customer site? Who opens a ticket when equipment loses power? What is the target for response and restoration? How does the provider communicate during a regional incident? A service-level promise is more useful when the measurement method is clear.
Test backup behaviour. Disconnect the primary path during an agreed window and observe what happens. Check payment terminals, voice, remote access and cloud applications. Confirm whether existing sessions continue and whether name resolution still works. A backup that has never carried production traffic may fail when it is finally needed.
Record dependencies. Note power, building access, local cabling, customer routers, carrier handoffs, mobile coverage and any cloud management service. Decide who owns each action during a failure. A diagram with named responsibilities is often more valuable than another marketing brochure.
Finally, review changes. Networks evolve. Exchange connections, upstreams, address assignments and service products can change. A design that was diverse two years ago may now share infrastructure after an acquisition or consolidation. Annual review and occasional failure testing keep the operating map aligned with reality.
What the public sources still do not tell us
The four sources used here are detailed but bounded. They do not provide a complete list of prefixes currently originated by AS28126. The RDAP record links related resources, while a complete live-routing assessment would require current BGP observations and careful treatment of more-specific routes.
They do not establish the RPKI validity of every route. That requires current prefix-level authorisation and observation data. This article deliberately avoids turning the presence of registry records into a routing-security score.
They do not describe Brisanet's internal topology. There is no public blueprint here for core routers, metro rings, access cabinets, towers, fibre ducts, backup power or network-operation procedures. Some of that information should remain private. Its absence means the public cannot independently certify physical diversity from these pages.
They do not measure customer experience. The company page provides customer and municipal figures, while PeeringDB describes interconnection. Neither source reports the performance of a named connection. Independent quality measurements would need a method, time window, location and sample large enough to support the conclusion.
They do not prove the performance of the SD-WAN product in any particular deployment. The page describes features. A real continuity claim needs the actual link mix, configuration, monitoring and test results.
They do not settle corporate responsibility for every service. The legal registrant of an ASN, the contracting entity, an infrastructure owner, a tower company, a wholesale provider and a support subcontractor can be different parties. Contracts and current operational records must connect those roles.
These gaps are not reasons to dismiss the public data. They are instructions for how to use it. The sources are strong enough to identify AS28126 and its recorded holder, describe declared interconnection and place the operator in its company context. They are not strong enough to turn that identity into an all-purpose claim about the running network.
Who is affected
Residential users are affected because the public network identity eventually supports everyday services: messaging, school portals, video, banking and government access. They rarely need to know an ASN, but they benefit when registry and contact records help operators coordinate incidents quickly.
Small and medium-sized businesses are affected because connectivity failure can stop payments, customer service and cloud access. They need to understand that a well-connected public ASN does not replace a site-specific continuity design. Their backup line, power and local equipment still matter.
Large enterprises are affected because they may peer, buy dedicated capacity or announce their own address space through the provider. For them, exact routing policy, route security, community controls, maintenance communication and diverse handoffs can become contractual issues.
Other network operators are affected because PeeringDB and RDAP help them decide whom to contact and where interconnection may be possible. Accurate records reduce the time spent matching a brand, legal company and ASN.
Public agencies and regulators are affected because broadband and mobile claims influence policy. Registry data can confirm number-resource identity, while service coverage, quality and resilience need different datasets. Using one as a substitute for the other can produce weak oversight.
Journalists and researchers are affected because ASNs are tempting shortcuts. A database can quickly produce a number and a company name, but responsible reporting must say whether a fact comes from a registry, a network-maintained directory, the company itself or an independent observation.
Brisanet itself is affected because accurate boundaries protect the company from both inflated praise and unsupported blame. A registry record should not be used to claim performance it does not measure, and a customer outage should not automatically be presented as failure of every network component associated with AS28126.
What to watch next
The first thing to watch is current route visibility. A future assessment could compare the prefixes related to the registry record with routes observed from multiple collectors. It should state the observation time and distinguish exact origins from routes learned through other networks.
The second is route-origin authorisation. Prefix-level RPKI data can show which origins are authorised at a given time. Any report should name the prefix and ASN instead of attaching a single security label to the whole company.
The third is interconnection freshness. PeeringDB records change as networks add, remove or update ports and facilities. The page's update timestamps help readers judge when declarations changed, but important decisions should still be confirmed with the operator or exchange.
The fourth is physical diversity. Public case studies or procurement documents that describe genuinely independent access paths would add evidence the current sources lack. The strongest disclosures would explain shared-risk groups without revealing sensitive topology.
The fifth is service continuity. Product claims about monitored or balanced links become more meaningful when accompanied by clear test methods, restoration targets and incident communication. Customers can request those details without needing access to confidential network design.
The sixth is legal and corporate change. Transfers, mergers or reorganisations can change names and responsibilities. Registry updates should preserve an accurate chain so that operators and the public can trace who is responsible for number resources.
The final thing to watch is language. "Registered to," "announced by," "connected at," "operated by," "owned by" and "used by" are not synonyms. Precise verbs keep the public record useful.
The reality behind AS28126
AS28126 is a meaningful public identifier. It allows other networks to recognise a Brisanet routing domain. Registro.br's RDAP record binds the number to a named legal entity and CNPJ. PeeringDB shows a declared public interconnection footprint. Brisanet's own pages describe the company and products around that network.
The value of those records comes from precision. They make identity and declared relationships visible. They support coordination. They help a customer or journalist ask better questions. They do not become more authoritative when stretched into claims they were not designed to answer.
The running network remains the final reality layer. Routes have to be announced. Links have to carry traffic. Power has to remain available. Monitoring has to detect faults. Repair teams have to reach physical infrastructure. Customers have to be able to use the services they bought. Those conditions can change faster than a registry page.
This does not put the ledger and operations in conflict. The internet needs both. Accurate records provide stable identifiers and contacts. Operational measurements show what the system is doing now. Contracts and incident evidence connect public identity to responsibility. When the layers agree, confidence rises. When they diverge, the difference points to the next investigation.
For non-specialists, the conclusion can stay simple. Brisanet's AS28126 is the nameplate on a public routing identity, not a map of every connection behind it. Use the nameplate to identify the network. Use current routes, tested paths, clear contracts and observed service to understand how that network works.
How to read evidence during an outage
An outage is the moment when people are most likely to collapse every layer into one explanation. A website stops loading and social media quickly fills with claims that a provider's "network is down." That phrase may be correct at a broad level, but it does not identify the failed component. The customer's Wi-Fi, local access line, regional transport, DNS resolver, public route, exchange connection, cloud platform or destination service could each produce a similar symptom.
The first useful record is a timestamp. Note when the problem began, where the user was located and which services failed. Check whether other destinations remain reachable. A payment application failing while ordinary browsing works points to a different investigation from a complete loss of connectivity. Multiple independent observations are stronger than one screenshot.
Next, separate reachability from registration. RDAP may still return the correct AS28126 record throughout an outage because the ledger is operating as designed. Its continued availability does not show that customer traffic is moving. Conversely, a temporary inability to reach a registry website does not mean the ASN has stopped existing. The resource record and the routed service have different operational paths.
Routing observations can narrow the question. If collectors continue to see expected prefixes originated by the expected ASN, the problem may sit elsewhere, although a visible route does not guarantee that every packet reaches every customer. If routes disappear or paths change sharply, engineers have a stronger routing lead. A traceroute can add a sample of the path, but one trace from one location is not a complete diagnosis. Networks may filter diagnostic packets or return them differently from application traffic.
Operator status notices and incident updates add another layer. A useful notice names the affected service or geography, gives a time and explains what is known without pretending certainty. It should distinguish investigation, mitigation and restoration. Customers should treat an initial estimate as provisional and retain the final incident report when the event affects important operations.
For a business, internal records matter too. Router logs, power events, failover alerts, application telemetry and support-ticket times show how the purchased design behaved. If the backup link came online but a critical application still failed, the post-incident review should ask whether DNS, firewall policy, source-address changes or application allow-lists blocked the alternate path. Calling the event simply an "internet outage" would hide the part the customer can improve.
The public ASN remains valuable during this process because it anchors identity. It helps engineers correlate routes and contact records with the operator. Its role is to make the investigation more precise, not to provide an instant verdict.
Why freshness and change records matter
Networks are not static assets. Operators add addresses, move exchange ports, replace equipment, acquire smaller providers and change upstream relationships. A public record can be accurate when published and incomplete months later. Every serious use of directory or routing data should therefore record when it was retrieved.
RDAP responses include registration and change events. Those dates help a reader understand the history of the entity, but a recent change date does not mean every operational detail was recently tested. It means the registry entity changed. PeeringDB also publishes update times for network and interconnection information. Those timestamps show when the profile was edited, not when an independent observer last verified each session.
The difference matters in due diligence. A buyer preparing a contract should save the exact resource identifiers and retrieve fresh records near the decision date. It should also ask the operator to confirm any interconnection or diversity claim that materially affects the design. A screenshot copied from an old presentation is weak evidence when the underlying network has changed.
Change records are particularly important after acquisitions. A customer-facing brand may remain while legal entities, support teams and network resources are consolidated. The registry may show a transfer or new contact. Routing may move gradually rather than on the corporate announcement date. Contracts may continue under an existing entity until renewal. Each transition has its own timeline.
Accuracy also requires preserving negative findings. If a current public source does not establish a route, prefix, RPKI state or physical path, the report should say so. Future researchers can then see which conclusion came from evidence and which question remained open. Filling a gap with a plausible assumption destroys that audit trail.
For Brisanet, the sources cited here were checked as a current snapshot on 5 August 2026. They support the identity and declared relationships described in this article. Readers making an operational or commercial decision later should refresh the records. The conclusion that a ledger is not a live map will remain sound, while the specific network entries may evolve.