Summary

  • Registro.br binds AS13459 and the active allocation 200.189.32.0/21 to PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA and CNPJ 00.887.249/0001-60. Those records establish a durable legal and number-resource identity, but their principal entities were last changed in 2013 and do not prove present day-to-day control.
  • RIPEstat observed six IPv4 announcements from AS13459 throughout its 11-25 July 2026 window, while Cloudflare Radar and bgp.tools also exposed a recent routing surface. That supports a narrow finding of current network visibility, not claims about customers, traffic, capacity, service coverage, physical assets or resilience.
  • The domains used around the network contact are registered to PHOENIX SOLUTION INFORMATICA under a different CNPJ. They may be relevant to administration, but the checked evidence does not establish ownership, merger, succession, outsourcing or a customer-facing relationship with the exact company attached to AS13459.

A network can be visible while its operator remains indistinct

Internet routing is unusually good at revealing that something is happening and often much less good at explaining the institution behind it. A route collector can see an autonomous system originate address space. A registry can identify the organization to which the number resource was assigned. A public contact can show that someone has maintained a channel through which operational messages may be sent. Those facts form a useful accountability trail, but they do not automatically describe one continuous, current business.

AS13459 illustrates that separation. The registered name is precise: PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA. The corresponding Brazilian company identifier is equally precise: CNPJ 00.887.249/0001-60. Registro.br connects both to the autonomous system and to an IPv4 allocation. Recent routing observations, meanwhile, show prefixes under that autonomous system appearing in the global routing system.

It would be easy to compress those facts into a simple profile of a current regional Internet provider. The evidence does not permit that compression. It does not identify a verified official website for the registered company, a current service catalogue, a customer support surface or a statement from the company explaining its use of AS13459. It does not show whether the legal registrant directly operates the routers involved in current announcements or whether another arrangement sits between registration and operation.

The distinction is more than a technical caveat. The Internet relies on organizations being reachable when routes are wrong, abuse reports need attention or a commercial counterparty needs to understand who is responsible for a network edge. A registered name can provide a starting point. A live route can establish that the issue is not purely historical. Accountability becomes harder when the public evidence joining those two layers is thin.

This does not make the registration false, the routes suspicious or the company inactive. It means each source answers a narrower question than a conventional company profile would suggest. The registry answers who is recorded as the resource holder. Routing observations answer whether a collector recently saw announcements associated with the ASN. Corporate data offers a reported legal status. Domain records identify separate registrants. None, on its own, settles current operating control.

The most defensible account of AS13459 is therefore one built from layers. Some are authoritative but old. Some are recent but observational. One is current-looking but comes from a third-party corporate mirror. Others expose a contact-adjacent namespace while simultaneously warning against treating it as the registered company's brand. The gaps between those layers are the central fact, not an inconvenience to be filled with assumptions.

What the Brazilian registry fixes firmly

Registro.br's RDAP record for AS13459 supplies the strongest identity anchor. It names PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA and associates the autonomous system with CNPJ 00.887.249/0001-60. The record places the resource in Brazil and connects it to the same legal identity that appears on the related IPv4 allocation. The allocation record covers 200.189.32.0/21. Registro.br marks that allocation active and repeats the exact legal name and CNPJ. Matching identifiers across the autonomous-system and address records matter because company names can be similar, abbreviated or mistyped.

Here, the numerical company identifier narrows the subject and keeps the analysis from drifting toward another business with a related-sounding name.

Both the autonomous system and the allocation date to 13 April 2000. That longevity is meaningful. It shows that the number-resource identity was not created for a recent, short-lived appearance. The public registry has carried a relationship between this legal entity, this ASN and this address space for more than a quarter of a century.

Longevity is not the same as continuous control. The ASN entity and allocation record were last changed in 2013. A record can remain accurate without frequent amendment, particularly when the core legal name and resource assignment do not change. It can also persist while the practical organization around the resource evolves. The update date cannot decide between those possibilities.

RDAP is strongest when used for what it actually records. It gives network operators and researchers a structured way to identify the registered holder, locate contact information and understand the resource boundary. It does not audit the company's internal governance, contracts or equipment. It does not certify that the named company still makes every operational decision associated with the number.

The active status of 200.189.32.0/21 is similarly bounded. It shows an allocation that remains valid in the registry. It does not show how much of the space is used, where equipment is located, which services depend on it or whether the registrant owns the physical paths carrying traffic. Address registration is an administrative fact, not an inventory of infrastructure.

Taken together, the two records establish the stable core of the story. AS13459 and 200.189.32.0/21 are not being associated with the company through a loose name match. They are tied to an exact legal identifier in an authoritative national registry. Everything more current or more operational has to be compared with that core rather than substituted for it.

The corporate record adds context, with attribution

A corporate-data mirror supplies a second view of CNPJ 00.887.249/0001-60. When checked in July 2026, it reported PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA as active, with an opening date in 1995, an address in Rio de Janeiro and information-technology consultancy as the principal activity. It also reported corporate officers and the trade name "PC SOLUTINO SERVICE".

Those details are useful because the exact CNPJ matches the number registry. They suggest that the legal entity attached to AS13459 has not simply disappeared from public corporate-data circulation. The reported opening date also predates the 2000 number-resource registrations, which is chronologically coherent with the company becoming a resource holder.

The evidence class matters. The page is a third-party presentation of corporate data, not a direct response from Receita Federal obtained for this research. Its status, address, activity, officers and trade-name fields should therefore remain attributed to the mirror. They are not a substitute for an official current certificate or company statement. Attribution is especially important for the trade name. "PC SOLUTINO SERVICE" is the spelling reported on the page. Correcting it to a more familiar English word would produce a cleaner-looking name but a weaker record.

The unusual spelling might reflect a filing, a transcription or another source condition; the checked evidence does not explain it. Preserving the reported form avoids quietly inventing a brand.

The principal activity creates another boundary. Information-technology consultancy is broad. It does not establish that the company currently sells Internet access, operates a regional ISP, manages a fibre network or serves a particular customer group. The ASN and live routes make network activity relevant, but they do not transform a general corporate activity field into a detailed service description.

Nor does reported active status close the control question. A company can be legally active while delegating technical administration, relying on contractors or changing the way it presents itself publicly. Conversely, a sparse online presence does not make an active legal entity non-operational. The corporate mirror answers a legal-status question imperfectly; it does not answer who logs into routers or negotiates connectivity.

The prudent conclusion is modest. A third-party corporate source reports the exact company and CNPJ as active in Rio de Janeiro. That supports continued legal existence, subject to the limitations of the source. It does not establish the current customer-facing identity, service portfolio or chain of operational authority behind AS13459.

Current routing visibility changes the question

If the story ended with records last changed in 2013, AS13459 might look like a historical registration whose present relevance was uncertain. RIPEstat's announced-prefixes observation changes that. Across its 11-25 July 2026 query window, the service observed six IPv4 announcements originated by AS13459.

The observed set consisted of 200.189.32.0/24, 200.189.33.0/24, 200.189.34.0/23, 200.189.34.0/24, 200.189.35.0/24 and 200.189.36.0/22. These announcements sit within the broader registered allocation. Their appearance gives the administrative record a contemporary technical counterpart: the ASN was not merely present in a registry but visible to routing collectors near the time of review.

RIPEstat's routing-consistency endpoint added another bounded observation. It found all six checked prefixes in both BGP and WHOIS. That agreement reduces one simple form of discrepancy between what was being observed in routing and what was represented in registration data. It does not mean that every route was authorized through every security mechanism or that every operational relationship was documented.

Cloudflare Radar also displayed AS13459 under the same legal-name label and associated it with Brazil. bgp.tools exposed six recent originated IPv4 prefixes and an observed connectivity surface. Independent visibility across those services supports the narrow conclusion that AS13459 had a recent public routing presence.

An observation is not a permanent certificate of activity. Prefixes may be announced, withdrawn, aggregated or represented differently across collectors. The finding should be stated in time-bounded language: the services checked near late July 2026 exposed a routing surface for AS13459, and RIPEstat saw the six specified announcements throughout its reported window.

That visibility does not identify customers. An originated prefix can support many kinds of systems and relationships. Cloudflare's estimated population must not be converted into subscribers or market share. No source here supplies traffic volumes, application mix, revenue, contract counts or the number of organizations using addresses from the allocation.

Current visibility is nevertheless important. It turns the main question from "Does this old registry entity still matter?" into "What institution is accountable for the network activity now visible under this old and durable registry identity?" The public evidence answers the first part more strongly than the second.

Six announcements are not six independent networks

The six-prefix observation invites more interpretation than it can safely carry. Some of the prefixes overlap in address coverage. A /23 contains two /24 blocks, and a /22 contains several /24-sized units. Seeing both a less-specific announcement and more-specific announcements can occur for many operational reasons, but the checked sources do not identify the reason in this case.

It would therefore be wrong to describe the list as six physically separate networks, six customer groups or six paths. Prefix count is a property of the observed routing presentation. It is not a direct measure of topology, commercial scale or resilience. It says how the address space appeared, not how the service was built.

More-specific routes can be used for traffic engineering, policy expression, migration or incident handling, among other purposes. They can also appear because of arrangements that are routine for a particular operator. Without statements from the network or richer longitudinal analysis, selecting one explanation would be speculation.

The same caution applies to BGP and WHOIS consistency. A prefix appearing in both sources is a useful hygiene signal. It shows that routing observation and registration information are not plainly disconnected at that level. It does not prove route-origin authorization, RPKI coverage, secure router configuration or effective response to a hijack.

No IPv6 deployment can be inferred from the checked material. The evidence under review concerns the stated IPv4 allocation and the six observed IPv4 announcements. Absence from this source set is not proof that IPv6 is absent, but it prevents a positive claim that it is deployed.

Capacity is also unknowable from prefix size. The number of addresses in an allocation does not reveal link bandwidth, oversubscription, concurrent demand or service quality. Address space can be sparsely or densely used. Some addresses may support infrastructure rather than end users. Translating a /21 into a customer estimate would compound several unsupported assumptions.

The useful analytical point is that routing evidence needs to be read as routing evidence. It establishes a visible technical surface and offers precise entities for continued observation. It does not reveal the economic or physical system behind that surface unless additional evidence connects the layers.

Three clocks are running at different speeds

AS13459's public record can be understood through three clocks: the company's reported legal history, the number registry and the routing system. Each advances according to a different process, and none should be forced to stand in for the others.

The corporate clock begins with a reported 1995 opening date and a July 2026 third-party indication of active status. Corporate records are concerned with legal existence, address, officers and classified activity. They may change when filings change, not when a route is announced or a router is replaced. The registry clock records the ASN and address allocation from April 2000, with the principal resource entities last changed in 2013. Number-resource records are designed to maintain assignment and contact information. A long interval between changes can indicate stability, staleness or simply the absence of a need to alter core fields.

The routing clock moves much faster. RIPEstat's window covers days in July 2026. A routing collector can observe changes over minutes or hours, while a corporate filing may remain untouched for years. This makes BGP valuable for establishing present visibility but weak for identifying the legal arrangements behind that visibility. Confusion arises when the clocks are collapsed. A recent route does not automatically refresh every old registry field. A recent contact update does not prove that the same legal owners or managers remain in control.

A corporate status page does not establish that the company directly originates the routes bearing its registered ASN.

Good accountability requires bridges between the clocks. A current company page could state the legal name, CNPJ, ASN and service role. A clear routing-policy document could explain contacts and operational responsibility. Current registry remarks could point to a verified organizational domain. None of those public bridges was established in the checked evidence.

The lack of a bridge should not be turned into an accusation. Many small and long-established networks have thin public documentation. Their technical work may be perfectly ordinary even when an external researcher cannot reconstruct it. The consequence is narrower: counterparties and affected users have less public material with which to verify responsibility quickly.

A maintained contact is a signal, not a chain of control

The contact information associated with AS13459 provides one newer timestamp. The administrative, routing and abuse contact handle shows a change in October 2025. Compared with the 2013 dates on the core resource entities, that suggests the contact record received more recent attention.

Contact maintenance matters. An address that is reviewed or changed is more promising than a record that has not visibly moved for decades. Operational and abuse contacts are intended to give other networks and users a path for reporting problems. Their usefulness depends on accuracy, monitoring and authority.

The timestamp does not reveal what changed. It does not prove that a message sent to the contact will receive a response, that the recipient is an employee of the registered company or that the recipient has authority to change routing. It does not identify whether administration is handled internally or by another organization.

This is where a common analytical shortcut becomes dangerous. A contact domain may look like a company brand, and an observer may assume that the domain owner and resource holder are the same business. In this case, the domain evidence points in the opposite direction: it identifies a different CNPJ.

The contact update is best treated as evidence of registry maintenance. It supports the view that the public record is not wholly abandoned. It should not be described as proof of ownership continuity, legal control or service availability. Those require evidence about organizational authority, not simply a recent date on a contact entity. Operational accountability depends on more than reachability. A contact needs to know which systems and relationships are involved, be able to investigate, and have a route to decision-makers or technical staff. Public RDAP cannot measure those qualities.

It can only expose the channel and its recorded associations.

For AS13459, the contact layer adds contemporaneity while also opening the most important identity question. The associated domains lead to another legal entity. That makes careful separation mandatory.

The domain evidence draws a boundary, not a bridge

Registro.br lists both pcsolution.com.br and datka.com.br as active domains. The registrant shown for each is PHOENIX SOLUTION INFORMATICA, CNPJ 05.082.602/0001-59. That is not the CNPJ attached to AS13459 and the 200.189.32.0/21 allocation.

The difference is substantive. Company names can lose words, gain abbreviations or appear in different legal forms, but two distinct CNPJ numbers must not be treated as a typographic variation. They identify separate registrations unless authoritative evidence establishes a legal relationship. No such relationship was established here.

The AS13459 contact uses an address at datka.com.br. The domain returned a live, minimal page during the bounded check. The page did not provide a company identity, service catalogue, capacity statement or ownership explanation. Its existence confirms a public web surface, not the nature of the relationship with the ASN holder.

The direct pcsolution.com.br hostname did not resolve during the check even though the RDAP domain delegation was active. DNS reachability and registration are different states. An active registration does not guarantee a functioning website, and a non-resolving hostname does not establish that the domain or company is defunct.

Several relationships could theoretically explain a contact using another registrant's domain. Administration could be outsourced. Companies could share personnel. A historical transition might have occurred. One organization could provide technical services to another. There could be a commercial relationship or none of the above. The sources do not select among those possibilities.

That uncertainty forbids several tempting claims. Datka cannot be called the operator of AS13459 on this evidence. PHOENIX SOLUTION INFORMATICA cannot be described as a parent, successor or owner of PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA. The two companies cannot be said to have merged. pcsolution.com.br cannot be presented as the registered ASN holder's official customer portal.

The domain records are valuable precisely because they prevent a false unification. They show that a contact-adjacent namespace is not necessarily an identity match. Rather than making the profile more complete, they expose the point at which the public chain of attribution breaks.

Registration, operation and service are separate layers

The public record becomes clearer when registration, operation and service are treated as three distinct layers. Registration concerns the legal identity attached to number resources. Operation concerns the people and systems that make routing decisions and maintain connectivity. Service concerns what is offered to customers or users.

For AS13459, registration is the strongest layer. Registro.br supplies the legal name, CNPJ, ASN and allocation. The corporate mirror supplies attributed context about the company. These facts allow the resource holder to be identified without relying on a brand guess. Operation is partly visible. The routes exist in recent observations, and the contact record has a newer timestamp. Those facts imply ongoing activity around the ASN and its records. They do not identify the operator's organizational chart, network operations centre, contractors, router locations or authority structure.

Service is the weakest layer. No verified first-party page in the source set describes Internet access, hosting, consultancy delivery or another live product under the exact registered identity. No service geography, pricing, customer segment, support channel or terms of service can be attributed to the company from the checked sources.

It is possible for the three layers to align completely. The registered company may directly operate the ASN and deliver services under a name that simply has little public documentation. It is also possible for responsibilities to be distributed. The evidence cannot decide, so the article must not decide for it.

This layered model prevents routing visibility from becoming a claim of retail activity. It also prevents sparse marketing evidence from erasing a real technical presence. AS13459 can be active in routing without the research being able to describe a current consumer offer. Both statements can be true.

For counterparties, the missing bridge is practical. A network considering interconnection, a security team tracing abuse or an organization reviewing a supplier may need to know which legal entity can make commitments. Registry data provides a first answer. Current operating and service documents would provide the rest.

Observed connectivity is not a contract map

bgp.tools displays an observed connectivity surface around AS13459. Such views are useful because they make routing relationships legible at a glance and help researchers identify where to investigate. They remain observations of paths and announcements, not copies of commercial agreements.

A path containing another ASN does not by itself establish the legal category of the relationship. Terms such as upstream, peer and customer carry contractual and policy meanings that may not be fully visible from a route. Relationships can change over time, differ by location or involve intermediaries not obvious in a simplified view.

The checked evidence therefore cannot name contractual transit providers or peers. It cannot establish that two observed paths are physically diverse. Separate AS-level paths may share fibre, ducts, power, buildings or another hidden dependency. Conversely, a sparse public view may omit arrangements that exist but were not visible to the collector.

No exchange membership or facility presence is established. There is no basis to place AS13459 at a particular data centre, Internet exchange, tower or network operations site. A route can be observed globally without disclosing where the relevant equipment sits.

Resilience is equally unresolved. Multiple visible relationships do not prove tested failover. A resilient service depends on capacity, routing policy, physical separation, power, monitoring and operational response. None of those elements is measured by the source set.

This is not a reason to disregard route observation. It is a reason to keep its vocabulary exact. The observations show that AS13459 originates the specified prefixes and has a visible relationship to the wider routing system. They do not disclose the commercial or physical design behind that relationship.

The distinction protects the company as well as the reader. Overstating weakness from sparse public data would be unfair. Overstating diversity or robustness from a route graph would be misleading. The evidence supports neither verdict.

The absence of a service surface has consequences

A company does not need an elaborate website to operate a network. Many long-running infrastructure businesses rely on direct relationships, local reputation or private channels. Public documentation is not the same thing as operational competence.

Even so, a missing verified service surface raises the cost of external verification. A prospective customer cannot readily connect the registered legal entity to a product. A network operator cannot use a company page to confirm the ASN and current contacts. A researcher cannot distinguish a historical name from a current brand through a first-party explanation.

The domain mismatch intensifies that cost. Search and contact clues can lead to PHOENIX SOLUTION INFORMATICA and Datka, but the legal identifier differs. Without an authoritative bridge, using those materials to complete the AS13459 profile would risk assigning one company's public claims to another. This matters during routine operations. Abuse handling may require confirming that a contact represents the relevant resource. Procurement may require matching an invoice, contract and network identity. Incident communications may need a current public name that affected parties recognize.

A clear identity statement reduces friction in each case.

The source set offers no evidence of a current outage, abuse failure or procurement dispute. These are examples of why identity clarity matters, not claims that AS13459 has performed poorly. The analytical point is about the quality of the public accountability surface.

Small organizations face a real trade-off. Maintaining registry entries, corporate records, domains and explanatory pages requires attention that may compete with technical work. But the most useful improvements need not be elaborate. A concise page linking legal name, CNPJ, ASN, contact domains and service role would resolve much of the ambiguity found here. Until such a bridge appears, observers should keep their conclusions narrow. The registered company is identifiable. The network is recently visible. The customer-facing and operational identity remains unverified.

What live routing cannot tell customers

For a customer, the presence of routes is a prerequisite for Internet reachability, not a description of service quality. RIPEstat, Cloudflare Radar and bgp.tools observe the network from outside. They do not measure the experience at a home, office or application endpoint served through an unknown arrangement.

No checked source reports latency, packet loss, jitter, throughput or congestion. There is no independent test of peak-hour performance. The prefix observations do not show whether traffic reaches users over fibre, wireless, leased capacity or another access method.

There is also no verified coverage area. The Brazil label identifies the country associated with the ASN in public data. The corporate mirror reports an address in Rio de Janeiro. Neither fact maps a service footprint. It would be wrong to infer statewide, metropolitan or neighbourhood coverage.

Customer count and market share are absent. Cloudflare's estimated population is modelled for its own observational purposes and cannot be recast as subscriptions. Addresses, requests, devices, people and paying customers are different units. Converting between them would require data that is not present.

Capacity is similarly opaque. Prefixes do not disclose port speeds, committed rates or spare headroom. An ASN can originate the same address space over very different transport arrangements. No inference about scale should be drawn from the age of the allocation or the count of announcements.

Physical ownership is unproven. The sources do not identify fibre, routers, facilities, towers, exchange ports or customer equipment owned by the registered company. Live routing establishes control over announcements at some point in the operating chain, not title to the infrastructure carrying them.

The customer-facing conclusion is therefore deliberately limited. Current routing visibility indicates that AS13459 participates in the public Internet. It does not establish what service the exact company sells, where it sells it or how well that service performs.

What route consistency does and does not establish

The agreement RIPEstat found between BGP and WHOIS for the six prefixes is a positive, specific result. It means the observed announcements and registry information were aligned in the service's checked view. For basic network-resource accountability, that is better than a plain mismatch.

Consistency can help reduce ambiguity when an ASN originates space associated with another holder or when registry data appears unrelated to observation. Here, the broad allocation and the originated more-specifics share a coherent registration context. That supports treating AS13459 and 200.189.32.0/21 as one bounded resource story.

The result should not be mistaken for a security audit. WHOIS alignment does not prove that route-origin authorization entities exist or are valid. The source set does not establish RPKI deployment. It does not test filtering, password management, router software, monitoring or response procedures.

Nor does consistency establish legal authorization at every layer. A registry can name a holder while day-to-day technical actions are performed through contractors or other arrangements. BGP can reflect a route without revealing the contract that permits it. Public consistency narrows the question but does not eliminate it.

The observation is also time-specific. Future route changes could alter the set or the consistency result. An accountability profile should therefore state when it was checked rather than presenting it as a timeless property.

For readers, the right interpretation is simple: the current routing evidence is not in obvious conflict with the registered number-resource identity. That is useful. The unresolved issue is the organizational bridge between the legal holder, the contact-adjacent domain and the operator making present decisions.

This distinction allows a positive technical fact to stand without being inflated. The records align at the level tested. Broader claims about security, authority and operational quality remain open.

The accountability gap is institutional, not merely informational

Missing data is often treated as a research inconvenience: find another page, search a different spelling, or infer the most likely relationship. In infrastructure analysis, that approach can erase the very accountability problem the evidence reveals.

AS13459 has enough public information to identify several relevant institutions, but not enough to define their relationships. The exact CNPJ tied to the ASN belongs to PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA. The contact-adjacent domains belong to PHOENIX SOLUTION INFORMATICA under another CNPJ. The network remains visible. The legal or operational connection between those facts is unresolved.

That is an institutional gap because responsibility may depend on the answer. The resource holder is the obvious starting point for registry accountability. The contact domain may be the practical route to a technical administrator. A customer-facing organization, if one exists under another name, may hold the commercial obligation. Public evidence does not show whether these roles coincide.

No conclusion about wrongdoing follows. Outsourced administration can be legitimate. Shared services can be efficient. Historical changes can leave old labels in technical systems for understandable reasons. What matters is that observers should not invent the arrangement, and operators should recognize the cost when the arrangement is not explained.

The cost appears in verification time. Each ambiguous handoff requires another check. Similar company names create a merger risk in analysis. Different CNPJs force a halt where a casual profile might continue. A minimal website offers no corrective statement. The result is a technically visible network with a weak public narrative of responsibility.

Accountability can improve without revealing sensitive topology or commercial terms. A resource holder can publish its current legal identity and authorized operating name. It can identify the domains used for contacts. It can explain whether a technical service provider administers the ASN. It can keep abuse and routing contacts current while clarifying who has authority to act.

Such disclosures would not prove reliability or service quality. They would make the chain of responsibility legible. That is the missing public layer around AS13459.

A practical standard for reading sparse network evidence

Sparse evidence calls for a repeatable method. The first step is to anchor identity in exact identifiers rather than names. Here, CNPJ 00.887.249/0001-60, AS13459 and 200.189.32.0/21 define the subject more reliably than any possible brand.

The second step is to separate authoritative records from observations and mirrors. Registro.br is authoritative for the Brazilian number-resource and domain records used here. RIPEstat, Cloudflare Radar and bgp.tools provide observations of routing. The corporate page is a third-party mirror and must be described that way. The third step is to bind every conclusion to time. The resource assignment dates to 2000, core entities were last changed in 2013, the contact has a 2025 change, and the routing observations are from July 2026. These dates do not conflict; they describe systems updated on different schedules.

The fourth step is to treat identifier mismatches as boundaries. The two domain registrations carry another CNPJ. That prevents the domains from being adopted as official company surfaces without further evidence. Similar words in legal names are not enough to overcome the numerical difference.

The fifth step is to resist converting technical measures into business measures. Prefixes are not customers. Cloudflare estimates are not subscriptions. Route paths are not contracts. Address space is not capacity. Country labels are not coverage maps.

The sixth step is to make uncertainty explicit. Current legal-control continuity, customer-facing branding, service geography, topology, capacity, resilience and incident history are unresolved. Listing those gaps is more accurate than filling them with generic regional-ISP language.

This method produces a less dramatic profile, but a more useful one. It tells a potential counterparty exactly what can be verified and where direct confirmation is still needed. It also creates a baseline against which future disclosures or registry changes can be compared.

What stronger public accountability would look like

The evidence suggests several questions that could be answered without exposing confidential network design. The most basic is whether PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA remains the organization exercising legal and operational control over AS13459.

A second question concerns the contact domain. If PHOENIX SOLUTION INFORMATICA or Datka performs technical administration, a short public statement could identify the relationship and scope. If the domain is only a legacy contact mechanism, that too could be clarified. Either answer would be better than inference. A third question concerns the customer-facing name. The corporate mirror's reported trade name is not enough to establish a current brand, especially given its unusual spelling and the lack of a verified first-party page. A company statement linking legal name, CNPJ and operating name would reduce confusion.

A fourth question concerns routing policy. A public record could state which ASN is operated, what address resources are in scope and where routing or abuse reports should go. It need not disclose upstream contracts, capacity or physical locations.

A fifth question concerns the service boundary. If the company offers connectivity, consultancy or another network-related service, a first-party description could identify the broad offering and geography without making unverifiable performance claims. If it does not sell a public connectivity service, saying so would prevent the ASN from being mistaken for a retail ISP surface.

These are standards for transparency, not findings that the company has failed an obligation. The sources do not show whether private counterparties already possess complete documentation. They show only that the public chain is incomplete.

For a long-held ASN with current routing visibility, closing that chain would have disproportionate value. It would connect a quarter-century-old registration to the organization responsible today and allow technical observation to be interpreted within the right legal and commercial frame.

The questions counterparties should keep separate

Anyone assessing AS13459 should begin by asking what decision they are trying to make. A routing engineer, a procurement team, a security responder and a prospective customer need different evidence. Combining their questions can produce overconfident answers.

A routing engineer can verify the observed prefixes and compare current paths over time. That work may reveal changes in reachability or route presentation. It still will not establish the contracts behind those paths without direct counterparty information.

A procurement team can verify the legal entity and CNPJ, then request current corporate documents and evidence of authority. The registry provides a strong identifier match. The third-party mirror is useful context but should not replace official due diligence.

A security or abuse responder can use the RDAP contacts and preserve the message trail. If a contact domain differs from the resource holder's legal identity, the responder may need explicit confirmation of authority. The mismatch is a reason to verify, not a reason to ignore the channel.

A prospective customer needs evidence of an actual offer, coverage, terms, support and performance. None of those can be obtained from the ASN registration or route collectors alone. Direct commercial documentation would be essential.

An infrastructure researcher should keep physical claims out of the account unless a source supports them. No facility, fibre route, router, tower or exchange port is established here. Even an accurate route graph cannot safely fill that gap.

Separating the questions creates a disciplined result. The legal resource identity is well anchored. The routing surface is recently observed. Corporate status is reported by a mirror. Operational authority, commercial service and physical implementation require direct evidence.

Visibility is the beginning of the inquiry

AS13459 is publicly visible in the most literal network sense. RIPEstat observed six IPv4 announcements in July 2026. Cloudflare Radar and bgp.tools exposed a recent routing presence. Registro.br provides a durable legal and resource identity behind the number.

That combination is stronger than a dormant registry entry. It establishes a live subject for infrastructure research. The address space and ASN can be monitored over time, and the exact CNPJ prevents casual confusion with a merely similar company name.

The same evidence also establishes the limit of the profile. The core registry entities are old, the newer contact points toward domains registered to another CNPJ, and no verified first-party service surface explains the relationship. Current routes cannot resolve current corporate control.

The plainest conclusion is therefore the most accurate. PHOENIX CONDOR SOLUTION SERVICE INFORMATICA LTDA is the registered holder attached to AS13459 and 200.189.32.0/21. A third-party mirror reports the company active. The ASN remained visible in recent routing observations. The public sources checked do not establish who exercises day-to-day control, what customer-facing service exists, or how the contact-adjacent company relates to the resource holder.

Nothing in that conclusion supports a merger, common ownership, succession, customer count, service footprint or facility claim. Nothing establishes poor performance or a network incident. The uncertainty is about institutional legibility, not a technical failure inferred from silence.

For the Internet's accountability system, that uncertainty is worth recording. Registry identity, contact maintenance and live routing each answer a different question. When they align clearly, counterparties can move from observation to responsibility quickly. When they do not, careful analysis must stop at the boundary.

AS13459's routes make the network observable. A current, authoritative explanation of legal and operating responsibility would make it understandable. Until then, visibility is the beginning of the inquiry, not its conclusion.

Sources