ISPCORP AS266247 Makes the Routing Identity Visible

Summary

Registro.br binds ISPCORP Soluções Digitais Corporativas Ltda. and CNPJ 36.209.554/0001-40 to AS266247, IPv4 allocation 45.6.216.0/22 and IPv6 allocation 2804:3d00::/32. That is strong evidence of legal and network-resource accountability, not proof of installed fibre, coverage, customers, capacity or resilience.
Receita Federal Contract 09/2021 records one specific fixed-broadband delivery in Caucaia: 50 Mbps, three monthly subscriptions at R$350 and a total of R$1,050 for the initial September-November 2021 term. The contract proves a dated service at one site, not a current regional footprint or present pricing.
RIPEstat, PeeringDB and IX.br make parts of the routing and interconnection identity visible. They do not disclose measured traffic, contractual upstreams, physical path diversity, facility ownership, customer experience or the resources available for outage recovery.

1. Start With the Exact Legal and Network Identity

The name ISPCORP sounds descriptive enough to encourage assumptions. It suggests an internet-service company serving corporate customers, perhaps with an owned network and a broad infrastructure footprint. None of those conclusions follows from the name. A defensible assessment starts with the exact legal registrant and the internet-number resources attached to it.

Registro.br's AS266247 record identifies ISPCORP Soluções Digitais Corporativas Ltda. under CNPJ 36.209.554/0001-40. The same identifier appears in the records for the company's registered IPv4 and IPv6 resources. This common identifier matters because company names can be repeated, abbreviated or entered differently across databases. The CNPJ provides the stable boundary that prevents facts about a similarly named organization from being merged into the wrong profile. The exact company is associated with Fortaleza, Ceará. A dated federal contract also lists a Fortaleza legal address for the same CNPJ. These records create a coherent administrative identity: one legal organization, one autonomous-system number and two principal address allocations. They make it possible to ask who is responsible for the resources and who should respond when a routing or service question arises.

That identity is not the same thing as an operating map. An ASN identifies a routing domain, not every cable, radio, cabinet, rack, building, technician, contractor or supplier involved in a delivered connection. A company can hold internet-number resources while leasing transport, placing equipment in third-party sites or relying on other organizations for part of the physical path. It can also operate equipment that is not visible in public registry records.

The distinction is essential for accountability. A clear legal holder gives customers, regulators, peers and suppliers a named party to contact. It does not tell them which components are under that party's direct control. A customer may have a contract with ISPCORP even when a fault occurs in a support structure, transport circuit or power system owned by someone else. The legal identity remains the commercial point of responsibility, while the technical cause may sit elsewhere.

Public company profiles can help keep the entity boundary stable, but they should not be treated as operational proof. An indexable directory identity confirms the subject and creates a durable link between the company and related research. It does not independently establish live service availability or current infrastructure. The strongest conclusion at this stage is exact but narrow: ISPCORP is the legal registrant behind AS266247 and the named address resources. That narrow conclusion is valuable because it prevents a more serious error later. Once the identity is fixed, each additional claim can be tested against a specific organization.

Contract facts, routing observations and interconnection records can be attributed correctly. Missing evidence remains missing instead of being filled with the usual profile of a regional provider. The result is a more useful operating picture, even when that picture contains large blank areas.

2. One Government Contract Proves One Delivery

The most concrete service evidence is not a marketing claim or a routing record. It is Receita Federal Contract 09/2021, published through the agency's official contract page. It names ISPCORP, gives CNPJ 36.209.554/0001-40 and describes fixed-broadband service for a Receita Federal agency in Caucaia, Ceará.

The schedule is unusually specific. It calls for 50 Mbps and records three monthly subscriptions at R$350, for a total of R$1,050 during the initial September-November 2021 term. That precision gives the public record a real service anchor. The named legal entity was not merely registered as an internet-resource holder. It entered a contract to deliver a defined broadband service at a defined government location during a defined period.

The contract should not be made to carry more weight than it can support. It does not prove that the same service remains active in 2026. It does not establish current pricing, current performance, a wider government portfolio or availability beyond the Caucaia site. It does not reveal whether every physical component was owned by ISPCORP, leased from another operator or provided through a subcontracted arrangement. Even the 50 Mbps figure has a bounded meaning. It is a contractual service specification, not an independently measured performance result.

The record does not provide a long-term series of throughput, latency, packet loss or availability measurements. Nor does it reveal how the service was engineered, which access technology was used or whether backup connectivity formed part of the delivery.

The three monthly subscriptions should not be converted into three customers or three circuits without further evidence. They are billing units in a specific contract schedule. They may correspond to the agency's administrative arrangement rather than a reusable picture of ISPCORP's retail model. Likewise, the R$350 monthly amount belongs to that dated procurement context. It cannot be treated as a current list price.

What the contract does reveal is the importance of service boundaries. A public body buys an outcome from one supplier, but that outcome can depend on multiple layers: local access, aggregation, transport, internet routing, power, equipment, monitoring and support. The contract names the supplier responsible to the customer. It does not disclose the entire dependency chain that makes the promised service possible.

This is why one dated contract matters more than a vague claim and less than a coverage map. It confirms that ISPCORP had a real service obligation at one site. It offers a fixed point for questions about delivery and accountability. At the same time, it leaves the wider operating footprint open. The disciplined conclusion is one proven delivery, not a generalized statement about regional scale.

3. The Service Catalogue Is a Claim Surface, Not an Asset Register

ISPCORP's website presents the company as a provider of dedicated internet, enterprise broadband, wholesale connectivity, LAN-to-LAN services, IP telephony and colocation. It also publishes a Fortaleza contact address. These labels help explain the commercial territory the company wants customers to associate with its name. They do not provide an inventory of owned assets. A dedicated-internet offer can be delivered over owned fibre, leased capacity or a combination of infrastructure. A LAN-to-LAN service can depend on several carriers and handoff points. A wholesale label can describe a commercial product without disclosing where capacity comes from or how much is available. IP telephony introduces software, numbering, platform and regulatory dependencies that are not visible in an ASN record.

The colocation label requires particular care. Marketing colocation does not prove that ISPCORP owns or operates a data centre. A provider can resell space, arrange access to a third-party facility, place equipment in a partner location or package connectivity with someone else's property. Without an attributable facility record, operational address and ownership evidence, the label should remain a description of a marketed service rather than a statement about real estate or facility control.

First-party descriptions are still useful. They show which customer problems the company claims to address. Enterprise broadband and dedicated access suggest that service assurance, installation coordination and business continuity may matter to buyers. LAN-to-LAN and wholesale services suggest that handoffs between networks or sites may be part of the commercial proposition. Those implications guide the questions customers should ask, but they are not answers.

Marketing claims about speed, stability or efficiency have the same limitation. They describe a promised quality or positioning. They do not substitute for measurements, contractual service levels, incident records or evidence about restoration. A claim may be accurate, but the public page does not provide the independent proof needed to turn it into a research finding.

The gap between service catalogue and asset register has practical consequences. Buyers need to know which parts of a service are controlled directly, which are leased and which depend on third parties. They need to understand where fault isolation stops and escalation begins. They also need to know whether the provider can reroute traffic or restore local access when a dependency fails. None of those questions is answered by a list of products. The service page therefore belongs in the evidence stack as an attributed commercial source. It gives language for what ISPCORP says it sells.

It cannot establish current coverage, customer count, network scale, facility ownership, installed fibre or performance. Keeping that boundary visible protects both the reader and the company from an inflated profile.

4. Address Resources Create Accountability, Not a Footprint

Registro.br assigns 45.6.216.0/22 to the exact ISPCORP CNPJ. The allocation spans 45.6.216.0 through 45.6.219.255. The registry also assigns 2804:3d00::/32 to the same legal holder. These records create a strong link between the organization and a dual-stack address base.

The IPv4 block contains 1,024 addresses in total, but that arithmetic cannot be converted into a subscriber count. Addresses can support routers, servers, network management, business customers, translation pools, test environments or reserves. One public address can represent many devices behind address translation, while one customer can consume several addresses. Some parts of a registered block may be announced, assigned or held differently over time. The IPv6 /32 is even less suitable as a measure of commercial scale. IPv6 allocations are intentionally large so operators can create stable addressing plans without repeating IPv4 scarcity.

The numerical size creates design space. It does not show how much of that space is configured, routed or delegated to customers. It cannot prove that native IPv6 reaches every service, site or access product.

Address registration also says nothing about the physical medium. A prefix can travel over owned fibre, leased wavelengths, Ethernet transport, wireless backhaul or another provider's network. The registry identifies the holder of the numbering resource, not the owner of each path. A customer cannot infer access technology from the first octets of an address.

The records are still operationally important. When an address from the registered ranges appears in a routing table, abuse report or security event, the registration identifies the organization responsible for the allocation. It provides a contact and a legal reference. It supports route-origin validation and helps distinguish intended announcements from obvious mistakes or hijacks. The event dates in RDAP should also be read carefully. Registration and later-change events describe updates to registry entities. They do not prove uninterrupted ownership, management or service delivery across every date between those events.

Corporate structures, contacts, network design and commercial relationships can change while the resource record remains recognizable.

A responsible interpretation therefore separates three layers. The legal layer binds the CNPJ to the resource. The routing layer asks whether the resource is publicly announced. The service layer asks how connectivity reaches a customer and what is promised. Registro.br provides strong evidence for the first layer and part of the second. It does not resolve the third.

This separation prevents two common exaggerations. A registered IPv4 block is not a map of customers, and an IPv6 allocation is not proof of modern service across a territory. What the resources show is a coherent, accountable network identity with room to operate in both address families. The physical and commercial footprint must be established elsewhere.

5. Public Collectors See Routes, Not Customer Experience

RIPEstat's announced-prefixes data showed ISPCORP's registered IPv4 /22, IPv6 /32 and several more-specific routes during the checked 12-26 July 2026 interval. Its routing-status view reported six visible IPv4 prefixes and six visible IPv6 prefixes at query time, with the origin visible through many queried RIS peers.

That observation is meaningful. It distinguishes address space that exists only in a registry from resources that public collectors could see in the routing system. It confirms that both address families formed part of AS266247's visible identity. It also creates a dated baseline. Future changes in origin, prefix set or visibility can be compared with this snapshot.

The observation remains a control-plane view. RIPEstat does not measure the experience of an enterprise circuit in Caucaia or any other location. A route can be visible while a local customer cannot connect because of an access fault, power failure, equipment problem, configuration error or commercial suspension. Conversely, a local service can continue through a path that is poorly represented in a particular collector set.

More-specific routes should not be treated as geographic or customer labels. Operators announce more-specifics for many reasons, including policy, traffic engineering, migration, operational separation or incident response. The data does not identify the purpose of each route. A /24 is not evidence of one town, one product or one customer group, and a /48 is not evidence of one enterprise site. Broad collector visibility is also not a redundancy score. Seeing an origin through many peers indicates that the route propagated across the observation network.

It does not reveal how many independent physical paths exist close to the operator, whether those paths share ducts or power, how much capacity is contracted or how quickly traffic can be moved after a failure.

The route data does not disclose commercial upstreams. A path view can show neighboring AS numbers observed by collectors, but it cannot prove the contract behind an adjacency. It does not reveal price, committed information rate, burst terms, service credits, handoff address, fibre route or restoration obligation. Those details belong to agreements and engineering records that are not public here.

IPv6 visibility deserves the same caution. The appearance of IPv6 routes supports the statement that AS266247 originated visible IPv6 space. It does not prove customer deployment, delegated prefix sizes, compatible home or enterprise equipment, firewall policy, support quality or equal treatment across services. Resource-level readiness is not customer-level availability.

The routing record is most valuable as an accountability surface. It shows what identity the wider internet could see and which registered resources were associated with that identity. It allows precise monitoring for origin changes or unexpected withdrawals. It cannot turn a visible control plane into a verified delivery chain.

6. Exchange Participation Shows Reachability Options, Not Physical Diversity

IX.br's Fortaleza entity page lists AS266247 as ISPCORP and exposes IPv4 and IPv6 route-server entity links. The Brasília entity page also lists the ASN and name. These official exchange surfaces add a useful interconnection signal to the registry and routing evidence. PeeringDB's network record identifies AS266247 as ISPCORP, lists AS-ISPCORP, marks IPv4 and IPv6 support and states an open peering policy. Its netixlan record includes an operational IX.br Fortaleza entry, route-server participation and a reported 20G port speed.

The distinction between source types matters. IX.br is the exchange operator's entity surface. PeeringDB is an operator-maintained directory. Both can be useful, but the PeeringDB policy and speed fields are self-reported metadata. They should not be presented as independent measurements or contractual guarantees.

Participation shows that an interconnection option exists at the directory level. It does not show how much traffic crosses the exchange, which bilateral peers are active or whether route-server sessions carry all eligible routes. It also does not reveal private-network interconnections, transit arrangements or the relative importance of each path. The reported 20G port speed is especially easy to overstate. A port's nominal speed is not measured average traffic, available headroom or customer-facing capacity. Traffic may use only part of the port, and the service chain may contain narrower links elsewhere.

The value also does not establish who owns the fibre or equipment that reaches the exchange.

Presence in Fortaleza and Brasília does not prove a customer footprint in both places. Exchange participation can support routing and interconnection without implying retail access in the same city. Equipment can be remotely operated, hosted in third-party facilities or reached through leased transport. A entity listing is not a coverage map.

Nor does two-city participation prove physical path diversity. Two logical locations can share long-haul infrastructure, operational staff, vendors, power dependencies or upstream transport. Conversely, meaningful diversity can exist without being obvious in a public entity list. Physical diversity requires route and facility evidence, not a count of directory entries. The interconnection records still improve the operating picture. They show that ISPCORP's public identity extends beyond registry allocation into recognized exchange participation. They help frame questions about route policy, traffic exchange and dependency.

The correct conclusion is visible interconnection metadata, not verified capacity, owned facilities or resilient topology.

7. The Delivery Chain Between a Contract and a Route

A customer experiences a service as one connection, but the connection is the result of several technical and commercial layers. At one end sits a site, customer equipment and a local handoff. At the other sits an autonomous system that exchanges routes with the wider internet. Between them can lie access plant, aggregation, transport, shared facilities, power, monitoring and multiple operating teams.

The 2021 Caucaia contract proves that ISPCORP accepted responsibility for one defined service. The AS and prefix records prove that ISPCORP has a distinct routing identity. The public evidence does not show exactly how those two ends were connected. It does not identify the local access medium, the transport supplier, the handoff site, the aggregation design or the equipment used. This hidden middle is where accountability often becomes difficult. A retail provider may control configuration and support while leasing the physical circuit. A transport supplier may own the long path while relying on another organization for local access.

Building entry can depend on property management, poles or ducts. Power can depend on site owners and utilities. The customer sees one service, while several organizations may control its components.

Commercial responsibility should not disappear into that complexity. The contracted provider remains responsible for communicating status, isolating faults and coordinating escalation. But the speed and quality of restoration can depend on agreements that the public cannot see. Service credits, escalation times, maintenance windows and spare-capacity arrangements matter as much as route visibility when a connection fails.

The missing delivery map also affects procurement. A buyer comparing providers needs to know whether two offers rely on genuinely different physical paths or merely different commercial brands over shared infrastructure. It needs to know whether a backup circuit has independent power and entry routes. An ASN and an IX listing cannot answer those questions.

The same issue affects network security. Route-origin monitoring can detect certain control-plane anomalies, but it does not protect local equipment from power loss, fibre cuts, misconfiguration or unauthorized physical access. Security responsibilities can be split across customer devices, provider routers, shared facilities and upstream networks. A clear identity helps coordinate response, but it does not reveal the entire control surface.

The most important unknown is therefore not a missing marketing statistic. It is the allocation of control. Which assets are owned? Which are leased? Which counterparties can interrupt service? Which party monitors each boundary? Which party can make a configuration change, dispatch a technician or authorize a reroute? The public record identifies ISPCORP as the service and routing identity but leaves those operational answers open.

That gap should not be treated as evidence of weakness. Many providers have legitimate reasons not to publish detailed topology. It should be treated as a reason for disciplined contracting and due diligence. The public identity starts the conversation. Service-specific evidence must finish it.

8. Public-Sector Connectivity Raises the Standard for Evidence

A government-site connection is not automatically critical infrastructure, but it carries a public accountability dimension that an ordinary marketing page does not. Public procurement creates a named buyer, supplier, entity, period and price. It gives citizens and oversight bodies a way to ask what was purchased and whether the supplier met the obligation. The Caucaia contract is modest in monetary size, yet analytically useful. It identifies a 50 Mbps service and a short initial term. This specificity reduces ambiguity about what was ordered.

It does not provide performance monitoring, acceptance tests, outage logs or evidence about service after the term. Those would be needed to assess actual delivery quality.

Procurement records can also expose how little a headline speed says about service design. A 50 Mbps commitment may be delivered through different technologies and contention models. Latency, packet loss, repair time, support hours, installation boundary and backup arrangements can matter as much as nominal bandwidth. The public contract excerpt does not establish those characteristics.

For a public buyer, vendor identity and dependency disclosure are practical controls. The agency should know who owns the customer handoff, who supplies transport, who can enter the site, how incidents are escalated and how changes are authorized. It should also know what evidence is available when the supplier reports that a fault lies with a third party.

IPv4 and IPv6 support are another example. AS266247 visibly originates both address families, but that does not prove that the 2021 Caucaia service offered native IPv6. A procurement team would need an explicit service requirement and acceptance evidence. Public route visibility cannot substitute for a test at the contracted endpoint.

The contract also demonstrates why historical evidence needs a date. A provider's capabilities, prices and dependencies can change significantly over five years. A 2021 service proves that a relationship existed then. It cannot be turned into a 2026 statement about coverage or current government customers. Good accountability preserves the date rather than smoothing it into a timeless profile. Public-sector digital infrastructure is often discussed at the level of national programmes or large data centres. The Caucaia example shows the importance of smaller links.

An agency's day-to-day access depends on ordinary circuits, local installation, support and escalation. Those connections may be inexpensive compared with major projects, but their failure can still interrupt public work.

The appropriate conclusion is precise. ISPCORP had a documented service obligation to one Receita Federal site during a dated term. That evidence supports a real enterprise-connectivity history and a set of questions about delivery accountability. It does not establish a broad public-sector footprint, present performance or current contract status.

9. Regional ISP Economics Sit Behind the Technical Unknowns

The public evidence supports a regional-ISP and enterprise-connectivity frame, but it does not disclose ISPCORP's revenue, subscribers, market share, workforce or capital base. Economics must therefore be discussed as mechanisms around the visible network identity, not as company financial facts. Access businesses usually commit resources before monthly revenue is certain. Connecting an enterprise site can require qualification, permissions, equipment, configuration, technician time and testing. Extending service can require construction or purchased capacity before take-up is known.

Customer density and retention affect returns, but no public source here shows ISPCORP's installation cost, churn or utilization.

The ASN and address resources sit above that investment. They allow ISPCORP to present a stable routing identity and manage its own prefixes, but they do not eliminate transport costs. Traffic still needs paths to other networks. Transit, peering, exchange ports, cross-connects and leased circuits can carry fixed fees, usage commitments and upgrade decisions. The public records do not reveal those contracts.

IPv4 scarcity can shape operations. A /22 is a useful registered resource, yet its commercial value depends on assignment policy, network design and customer products. Address translation can extend IPv4 capacity while adding operational complexity. IPv6 can reduce long-term address pressure, but customer deployment requires compatible access equipment, support practice, routing and security. The presence of a /32 and visible IPv6 routes does not reveal how far that work has progressed.

Enterprise services can have uneven support costs. A small number of sites may demand higher availability, faster fault response or specialized configuration. Field incidents do not arrive on a smooth schedule. A provider needs access to technicians, tools and spares even when demand is uncertain. Outsourcing can make costs more variable while reducing direct control over dispatch. Dependency concentration matters as well. If several services rely on one transport path, facility or power domain, apparent product diversity may not create operational diversity.

If capacity comes from multiple counterparties, coordination can become more complex. Neither condition can be inferred for ISPCORP from the public evidence, but both are central to the economics of service assurance.

Exchange participation can reduce some traffic costs or improve paths, depending on actual traffic and peering relationships. The directory entries do not show whether those benefits are material. A nominal port speed does not reveal utilization or cost. The value of interconnection depends on who exchanges traffic, where demand originates and how the rest of the network reaches the exchange. The economic picture is therefore one of visible control at the routing edge and uncertain cost allocation underneath. ISPCORP holds the identity and resources. The expenses and dependencies that turn them into a customer service remain largely private.

That is normal for a private operator, but it limits what can be claimed from public data.

10. Resilience Cannot Be Read From a Prefix Table

Resilience is often inferred from technical-looking signals. Multiple prefixes, IPv6 support, exchange participation and a declared port speed can create an impression of scale or redundancy. None of those signals proves that a customer service will survive a fibre cut, power failure, equipment fault, upstream outage or operational error.

Prefix deaggregation can serve policy or traffic-engineering goals, but it does not prove independent physical paths. Two routes can traverse the same duct, building, power feed or upstream. Likewise, presence at two exchange locations does not show whether the paths to those locations are physically separate. Logical diversity and physical diversity are different controls. The public record contains no evidence about backup power. There is no verified inventory of batteries, generators, fuel, maintenance intervals or runtime. It also contains no evidence about spare routers, optical modules, customer equipment or repair materials.

These resources can determine restoration time when a failure moves from software to the physical layer.

Staffing is another unknown. Network monitoring may detect a problem quickly, but field restoration depends on access, travel, permissions and technical capacity. A provider can use employees, contractors or partner teams. Each model can work, yet each creates different escalation paths. The sources do not disclose ISPCORP's arrangement.

There is also no verified outage history. Without incident records, uptime measurements or service reports, it is impossible to compare claims with observed performance. The absence of public outage data is not evidence of perfect service and not evidence of poor service. It is simply an unmeasured area.

Customer-specific resilience can differ from network-level resilience. An operator may have multiple internet paths while one enterprise site has a single local loop. A customer may buy a backup circuit that shares the same building entry or utility supply. Evaluating resilience requires the actual service design, not the provider's ASN alone.

Security and change control can create failure modes that physical diversity does not solve. An incorrect route policy, software defect or unauthorized configuration can affect multiple paths at once. The public route data can reveal some resulting symptoms, but it cannot show the internal controls that prevent or recover from them. The right resilience statement is therefore a list of unknowns, not a score. Public evidence confirms a visible dual-stack routing identity and exchange participation. It does not establish capacity headroom, physical redundancy, backup power, field readiness, restoration time, uptime or service quality.

Any buyer who needs those properties should require service-specific evidence.

11. What Enterprise Buyers Should Ask

The public record is sufficient to ask sharper questions than a generic request for "reliable internet." The first question concerns the service boundary. Which equipment marks the handoff, who owns it and where does the provider's responsibility begin and end? A clear answer reduces ambiguity during installation and fault isolation.

The second question concerns access technology and path. Is the connection fibre, wireless or another medium? Which parts are owned, leased or subcontracted? Does a backup offer use a genuinely separate route, entry point, power domain and upstream? Brand diversity alone is not enough if two circuits share the same physical dependency.

The third question concerns routing. Will the service use ISPCORP address space, customer-owned space or private addressing? Is native IPv6 available, and if so, what prefix is delegated? How are route changes authorized and monitored? If the customer needs BGP, what filtering, maximum-prefix and routing-security controls apply? Interconnection deserves a separate conversation. IX.br participation and PeeringDB metadata show a public interconnection identity, but a buyer should ask how its traffic is expected to reach important destinations. Which paths are normal, which are backup and what happens during congestion or maintenance?

The answer should be tied to the purchased service, not to a general exchange listing.

Performance commitments should be measurable. Nominal bandwidth is only one field. Latency, packet loss, jitter, availability, repair targets and support hours may matter depending on the application. Measurement points, exclusions and escalation rules should be clear. A public route collector cannot validate a customer service-level commitment.

Power and site access are also practical. Which locations require backup power, who maintains it and how is extended failure handled? Can technicians enter the relevant building or support structure outside business hours? Are spare components available locally? These questions can determine restoration speed when monitoring has already identified the fault.

Buyers should ask how third-party dependencies are managed without expecting every contract to be disclosed. The provider can explain whether important components are leased, how counterparties are escalated and whether maintenance notices are coordinated. This gives the customer a realistic view of control without demanding sensitive topology.

Finally, the buyer should preserve evidence. Installation records, acceptance tests, addressing details, configuration baselines, incident tickets and post-incident reviews make future disputes easier to resolve. The goal is not to turn every customer into a network operator. It is to connect commercial promises to observable service facts.

12. What Peers and Resource Operators Should Monitor

For network operators, AS266247's public identity creates a different set of controls. The starting point is origin consistency. Prefixes registered to the exact legal holder should be monitored for unexpected origin changes, withdrawals and more-specific announcements. A change may be legitimate, but it should be explainable. The registered IPv4 /22 and IPv6 /32 provide stable parent references. Monitoring can compare observed routes with intended policy and identify announcements that fall outside expected boundaries.

This is more useful than assuming that every observed more-specific is suspicious or that every registered resource must always be visible.

Contact quality matters when something changes. Registry and directory records should point to people or channels capable of resolving routing and abuse issues. A precise legal identity helps, but operational response depends on maintained contacts and clear escalation. Stale records can turn a detectable event into a prolonged coordination problem.

Peering policy metadata can support initial coordination, yet it should be confirmed directly before operational decisions. An open-policy label and a reported exchange presence do not guarantee that a session will be accepted or that all routes will be exchanged. Technical requirements, traffic thresholds and bilateral terms may exist outside the public directory. Route-server participation also has boundaries. It can simplify multilateral exchange, but it does not eliminate the need for filtering, prefix validation and monitoring. Each entity remains responsible for its announcements and customer routes.

Public listings do not reveal every control applied inside the network.

The IPv6 identity deserves equal operational attention. IPv6 incidents can be overlooked when monitoring and support remain IPv4-centric. The visible /32 and more-specifics justify checking route consistency, reachability and configuration in both families. They do not justify assuming that customer support or access deployment is identical.

Change history can become useful over time. A future record of route-set changes, exchange metadata changes and registry updates could reveal operating transitions without requiring private topology. The value comes from dated comparison, not from reading one snapshot as a permanent design. The monitoring objective is modest: keep the public identity coherent enough that unexpected change can be noticed and directed to the right organization. It does not require publishing sensitive network detail.

It requires accurate resource records, maintained contacts and a clear distinction between administrative data, routing observation and customer service.

13. A Practical Evidence Hierarchy for ISPCORP

The sources form an evidence hierarchy rather than one complete profile. At the strongest legal level, Registro.br binds the CNPJ to AS266247 and the address allocations. That establishes the responsible registrant. The federal contract adds one dated service obligation, with a named site, speed, term and price.

At the routing level, RIPEstat shows that collectors observed the registered resources and more-specifics. This supports a statement about public control-plane visibility during a defined interval. It cannot establish the physical network or customer experience. At the interconnection level, IX.br lists AS266247 as a entity in Fortaleza and Brasília. PeeringDB adds operator-maintained policy, protocol and port metadata. These records support a statement about a visible interconnection identity. They do not prove traffic, contract terms, owned facilities or physical diversity.

At the commercial level, ISPCORP's own site names enterprise connectivity, wholesale, LAN-to-LAN, telephony and colocation services. These statements explain positioning and possible product scope. They are not independent measurements and should never be used as an asset register.

The hierarchy also identifies what is absent. There is no verified current coverage map, no installed-fibre inventory, no customer count, no traffic measurement, no upstream contract, no physical path map, no facility-ownership evidence, no backup-power record, no outage history and no independent performance series. Each absence limits a different kind of claim.

This approach avoids treating all sources as equivalent. An authoritative resource registry is strong for resource identity and weak for customer delivery. A routing collector is strong for visibility and weak for physical topology. A contract is strong for one obligation and weak for current regional scale. A company website is strong for self-description and weak for independent verification.

The result is not a negative profile. It is a bounded one. ISPCORP has a documented legal identity, a visible routing domain, dual-stack resources, exchange participation and at least one dated enterprise-service record. The missing information concerns how those pieces are assembled into services today. That distinction makes future updates easier. New evidence can be added to the correct layer. A current service map would improve the coverage layer. A facility contract would clarify one physical dependency. A route-policy statement would improve the control-plane layer. Service measurements would address customer experience.

No single new source should be allowed to erase the boundaries among them.

14. The Accountability Gap Is the Main Finding

ISPCORP is visible where internet administration is designed to be visible. Its legal registrant, ASN and principal address allocations can be identified. Its routes appeared in public collectors. Its name appears on exchange-entity surfaces. A federal contract proves one dated service obligation. These are substantial facts. The company is much less visible where service delivery becomes physical and contractual.

The public record does not identify current access technology, address-level availability, customer count, installed plant, transport suppliers, contractual capacity, facility control, backup power, staffing, spare resources, outage history or restoration performance.

That gap is not unusual for a private regional provider. Public routing systems were not designed to disclose commercial and physical topology. Procurement pages were not designed to serve as network maps. Company websites were not designed as audited asset registers. The mistake would be to make one source answer questions that belong to another. For customers, the gap means that due diligence must move from identity to service design. For peers, it means that resource and route monitoring should be tied to maintained contacts and direct coordination.

For public buyers, it means that nominal speed and supplier name should be supplemented with measurable acceptance, support and dependency terms.

For ISPCORP, the visible identity creates an opportunity. Clearer, carefully bounded public information about service areas, access methods, support boundaries and routing policy could reduce uncertainty without exposing sensitive topology. The goal would not be to publish every fibre route. It would be to make the commercial and operational boundary easier to understand. The available evidence supports a precise final judgment. ISPCORP is a real Brazilian network operator with a coherent legal and routing identity, public IPv4 and IPv6 resources, exchange-entity records and a documented history of one enterprise broadband delivery.

The same evidence does not prove owned fibre, data-centre facilities, national coverage, customer scale, measured capacity, physical redundancy or service quality.

That combination of visibility and opacity is the operating story. AS266247 makes the organization legible at the edge of the global routing system. It does not show the chain that turns a route into a working connection at a customer site. Accountability begins with the public identity and must be completed by contracts, engineering evidence and service-specific observation.

ISPCORP AS266247 Makes the Routing Identity Visible, but the Delivery Boundary Remains Opaque