Summary

  • RIPEstat identifies AS134945 with the holder string BLUESKY8-AS - Blue Sky Broadband Pvt. Ltd. and currently reports the autonomous system as announced.
  • The announced-prefixes response lists four visible IPv4 /24 prefixes, which supports a routing-visibility profile but does not prove the physical access network, customer base, capacity, redundancy, power path or outage behaviour behind the record.

Four visible routes make the company inspectable

Blue Sky Broadband Pvt. Ltd. enters the public Internet record through a number-resource surface rather than through a facility disclosure or a conventional service map. The relevant public object is AS134945. RIPEstat's AS overview identifies the holder as BLUESKY8-AS - Blue Sky Broadband Pvt. Ltd. and marks the autonomous system as announced. Its announced-prefixes response lists four IPv4 /24 prefixes: 103.84.236.0/24, 103.84.237.0/24, 103.84.238.0/24, and 103.84.239.0/24. Those facts create a clear infrastructure signal. They show an observable routing domain, but they do not describe the delivery chain behind it.

That distinction matters. A visible autonomous system can anchor a company in the public coordination record. It can show that number resources are present in a route collector's view and that registry-derived fields name a holder, a maintainer set and an incident-response reference. It cannot by itself prove where routers sit, which access medium reaches subscribers, whether there are independent upstream paths, how power is supplied, what capacity is usable, or what happens when a physical link fails. The public route footprint is real evidence, but it is not an audited network map.

For Blue Sky Broadband, the routing evidence is stronger than a dormant registry entry because RIPEstat currently sees four announced prefixes. It remains a narrow form of evidence. Four /24s establish visible IPv4 origination in the query window. They do not identify the customers using those addresses, the geography in which service is delivered, the upstream relationships carrying the prefixes, or the failure paths that would matter during a local outage. AS134945 is therefore best read as a routing-control surface with an unresolved physical operating boundary.

Blue Sky Broadband is the company boundary used for this profile. That boundary is deliberately narrow: it identifies the named company associated with the registry and routing record, then leaves every physical-service claim to separate public evidence. It does not prove that the public routes belong to a particular access plant, that they serve a particular town, that they have redundancy, or that the company is commercially operating a specific service over them. It connects the named company to AS134945 before the route evidence is evaluated.

This is why the safest thesis starts with AS134945 and route visibility rather than with a broad claim about broadband service. The visible public record is enough for infrastructure analysis: the AS holder string names Blue Sky Broadband, the route collector currently sees four IPv4 /24s, and WHOIS exposes APNIC-derived registry fields. The same record also imposes limits. It leaves the company's physical operating boundary open, and that boundary is the core finding.

Registry identity is a recordkeeping layer

The first layer of the evidence is the registry identity. RIPEstat's AS overview places AS134945 in an APNIC-assigned IANA 32-bit autonomous-system number block and returns the holder string BLUESKY8-AS - Blue Sky Broadband Pvt. Ltd.. The WHOIS view records aut-num: 134945, as-name: BLUESKY8-AS, and descr: Blue Sky Broadband Pvt. Ltd.. It also shows country: IN, maintainer references including MAINT-IN-BLUESKY8 and MAINT-IN-IRINN, an incident-response reference IRT-BLUESKY8-IN, and APNIC as the source. The last-modified timestamp in the response is 2025-09-27T10:34:43Z.

Those fields matter because they turn a route table observation into an accountable public record. A prefix announcement without a holder link can be hard to interpret. A company name without a routing object can be too broad for an infrastructure profile. The AS overview and WHOIS records give both pieces: a named company and a public autonomous-system number. That does not mean the registry record is the network. It means the registry record is the ledger surface that lets readers inspect who is named around a routing domain.

The recordkeeping layer should not be inflated into a claim about operational quality. A maintainer reference does not prove that repair staff are available. An IRT reference does not prove a response record. A country field does not map fibre routes, access towers, power rooms or customer premises. A last-modified timestamp does not prove that customers are active. Each field has a narrow use. It anchors the AS in a public administrative record and shows that the resource has named registry contacts and provenance. It does not prove the condition of the physical system.

That distinction follows the reality-layer method that governs number-resource coverage. The registry is valuable because it is inspectable and because Internet number resources need accurate recordkeeping. It is not sovereign over the actual state of the running network. Running-code evidence, route collector evidence and later operational sources have to be examined separately. For AS134945, route collector evidence does exist: RIPEstat marks the AS as announced and lists four IPv4 /24s.

The registry and route table therefore reinforce each other at the public-number-resource layer, while physical service evidence remains outside the current public record.

A clear hierarchy emerges. Blue Sky Broadband is the exact company entity. AS134945 is the number-resource and routing surface associated with the holder string. The APNIC-derived WHOIS data supplies maintainer and IRT recordkeeping. RIPEstat's announced-prefixes response shows current IPv4 route visibility. None of those layers, separately or together, proves the access network, service footprint, customer dependency or resilience model.

The four IPv4 prefixes are visible, but their role is limited

RIPEstat announced-prefixes lists four IPv4 /24s for AS134945 in the current query window ending 2026-07-29T16:00:00: 103.84.236.0/24, 103.84.237.0/24, 103.84.238.0/24, and 103.84.239.0/24. Each is shown with a timeline beginning 2026-07-15T16:00:00 and ending at the query-window close. That is a concrete routing fact. It gives the company a public route footprint in a way that a directory entry alone would not.

The fact still has a limited meaning. A /24 prefix visible to route collectors shows that an address block is being originated in the public routing system under the observed AS. It does not say whether those addresses sit behind residential broadband customers, business circuits, infrastructure equipment, hosting services, NAT pools, management systems or other uses. It does not show which upstream path carries the prefix, whether route-origin authorization is configured, or whether the route is stable under failure. It also does not show the physical route by which traffic reaches the operator's equipment.

This limit is important because broadband labels are easy to overread. A name such as Blue Sky Broadband may suggest access service, but the current public record does not prove access plant. It proves an AS holder string and four visible prefixes. It does not support tower counts, fibre kilometres, powered sites, exchange presence, customer premises, service tiers, latency claims or redundancy architecture. Those would be physical and commercial claims. The route evidence only supports a public routing-state analysis.

The four-prefix footprint does make the subject more concrete than a registry-only company. It means the public record exposes IPv4 space under AS134945. It shows that the public ledger and the running-route view are aligned enough to make the company visible. It also shows why the operating question remains open. Visibility is the start of inspection, not the end of inspection.

The useful reading is therefore layered. The prefixes prove public IPv4 origination at the collector layer. They support monitoring questions about continuity, origin changes, withdrawal and future neighbour evidence if those facts are later available. They do not prove physical redundancy, service availability, delivered capacity, customer dependence, outage recovery or commercial operating status. The profile remains strongest when those boundaries are explicit.

What the four /24s can and cannot support in monitoring

Four visible /24s give analysts a practical baseline. If the same four prefixes remain visible, the baseline suggests continuity of public route origination at the collector layer. If one or more prefixes disappear, shift origin, or become more specific in another view, the change would be worth inspecting. If future data shows additional upstream neighbours, route-origin authorization, or related routing-security records, the public understanding of the network surface would improve. The current evidence does not contain those later facts, but it creates a reference point for them.

The baseline is useful because number resources are not only corporate labels. They are operational identifiers in the global routing system. An AS and its originated prefixes can be watched over time. They can reveal whether a named holder remains visible, whether prefix sets are stable, and whether registry fields continue to align with route-table evidence. That is a legitimate infrastructure lens even when customer-facing service data is absent. It focuses on public, inspectable control surfaces rather than on promotional claims.

The baseline should not be treated as a performance report. Prefix visibility is not packet loss. It is not uptime. It is not throughput. It is not a service-level agreement. It is not a measure of last-mile reach, customer density or market share. A network can announce a small amount of address space and carry important traffic. Another can announce similar address space and carry little traffic. Without traffic, topology, outage or customer evidence, the prefix list should stay in the monitoring layer.

The same caution applies to geography. The WHOIS record includes country: IN, and the exact company subject is Blue Sky Broadband Pvt. Ltd. That does not map the routes to a city, district, exchange, tower, fibre span or service cluster. APNIC-region registry data supplies administrative context, not a local plant map. The article can identify the India/APNIC context, but it cannot describe the physical footprint beyond the public number-resource record.

A responsible monitoring frame also separates current evidence from future proof. The current evidence says AS134945 is announced and four /24s are visible. A future measurement could show route withdrawals, path diversity, ROA status or neighbour changes. A future official document could show service regions or licence conditions. Until those facts appear, the safest conclusion is that Blue Sky Broadband has an inspectable public route surface and an unresolved delivery-chain profile.

The delivery chain remains outside the current evidence

The delivery chain begins where the route table stops. Traffic has to move through routers, upstream or peer connections, local access media, powered sites, customer equipment, maintenance processes and repair paths. The current evidence does not reveal that chain for Blue Sky Broadband. It names the AS holder and shows four announced IPv4 /24s, but it does not show how those routes connect to people, premises or services.

That gap is not a reason to ignore the company. It is the analytical boundary. Public infrastructure coverage often has to distinguish between a control-plane record and service-delivery proof. AS134945 is visible in the control plane. The company is visible in the directory and registry layers. The delivery chain is not visible in the current public record. A reader can therefore understand what is inspectable and what still requires independent evidence.

Several important questions remain unanswered. The record does not identify upstream providers. It does not show whether the four prefixes are carried over one path or several. It does not show whether the network has diverse access to power, an alternate upstream, a backup transport path or an emergency restoration plan. It does not establish whether the prefixes are used for retail subscribers, enterprise links, infrastructure services, management systems or another purpose. It does not show whether Blue Sky Broadband owns equipment, leases capacity, contracts field repair or relies on another operator for critical functions.

Those unresolved questions are the physical dependency path. A network can appear in the public route table while depending on a single upstream, a single powered site, a single access technology or a small group of field crews. Another network with the same visible prefix count might have richer redundancy. The route table alone does not decide between those possibilities. It gives analysts a place to begin, not a full operating model.

The correct language is therefore modest. Blue Sky Broadband is visible through a public AS holder string and four IPv4 route announcements. The visible routes support scrutiny of a number-resource control surface. They do not prove access reach, customer dependence, recovery paths or operational resilience. That boundary is the point, because the public Internet record is meaningful only when its limits are kept visible.

Announcement state should not be confused with capacity

RIPEstat's AS overview reports AS134945 as announced. That is a stronger claim than a registry-only record, but it is still not a capacity claim. An announced AS can have a small footprint or a large one. It can carry customer traffic, internal traffic, management traffic, transit, hosting, access, or some mixture of roles. The public route view captured here identifies visible IPv4 blocks. It does not show how much traffic flows, how many end users depend on it, or what design capacity the operator may have installed.

Capacity is one of the most common places where infrastructure writing goes wrong. A prefix count is not a bandwidth figure. A /24 is an address block, not a committed information rate. Four /24s do not imply a subscriber base, revenue scale, route diversity, market share or resiliency level. The address space may be used efficiently or sparsely. It may be announced through one path or multiple paths. The current public record does not answer those questions.

The route evidence can still explain why Blue Sky Broadband is observable. RIPEstat sees four visible IPv4 /24s originated by AS134945. The query window and the specific blocks can be named. Future changes in those prefixes would be useful to watch. What the record cannot do is convert the visible prefixes into installed, lit, powered, sold or usable capacity. Those are different forms of infrastructure evidence.

The same caution applies to commercial operation. A route can be announced while public evidence remains silent about whether commercial customers are active. Conversely, a company may operate a service that is not fully visible in the route data. The current record supports a public routing analysis, not a full commercial-operation assessment. It is safer to use phrases such as visible public route footprint and unresolved delivery boundary than to use operational claims such as served area, subscriber base or resilient broadband platform.

By keeping capacity claims out of the profile, the evidence becomes more useful. It shows where the public Internet record is strong and where it is thin. It avoids giving Blue Sky Broadband unearned credit or unsupported criticism. The route record is meaningful enough to inspect, but not broad enough to settle the operating story.

WHOIS contacts matter for accountability, not service proof

The WHOIS fields in the RIPEstat response are useful because they expose public recordkeeping details for the autonomous system. The maintainer references MAINT-IN-BLUESKY8 and MAINT-IN-IRINN show how the registry record points to maintenance objects. The IRT reference IRT-BLUESKY8-IN points to an incident-response object. The APNIC source and last-modified timestamp locate the record in a regional number-resource system and give a visible recordkeeping time marker.

Those fields matter for accountability because routing depends on accurate public records. If an AS is visible in the route table, readers need to know which organization is named around that AS and which registry fields are attached to it. A maintainer field can indicate where registry maintenance responsibility is represented. An incident-response reference can indicate how abuse or security contact is represented in the registry. A source registry can show which regional process produced the public view.

The fields do not show how the network performs. They do not prove that a help desk responds quickly, that abuse reports are resolved, that upstream routing is secure, that customer service is reliable, or that the company has redundant infrastructure. They are not service-level indicators. They are registry-side accountability fields. Their value is that they expose the recordkeeping surface around a visible AS.

This is especially important for a company with a compact public record. When the record is narrow, every field can look more important than it is. The correct method is to ask what each field can bear. The holder string can bear identity. The announced=true field can bear route visibility. The prefix list can bear visible IPv4 origination. The maintainer and IRT fields can bear registry accountability. None of them can bear a physical-network map.

If a future public record identifies upstream providers, route-origin authorization, public outage incidents, regulatory licence conditions, customer-impact reports or service-region details, those facts could expand the operating profile. Until then, the WHOIS fields remain in the recordkeeping layer. That makes the profile precise and keeps the public copy inside the evidence boundary.

The unresolved dependency questions are concrete

The unresolved dependency questions for Blue Sky Broadband are not vague. They can be listed clearly because each one corresponds to a missing public evidence layer. Where are the routers that originate the four visible /24s? Which upstream or transit arrangements carry them? Are the prefixes announced from one site or more than one? Is there route diversity, or does one provider or facility create a concentrated failure point? How is power supplied to critical equipment? What field repair path would restore service after a local cut or equipment failure? The current public record does not answer those questions.

Customer dependency is equally unresolved. The four prefixes may support subscribers, business links, infrastructure services, management systems or another use. Without customer-facing documentation or independent operational evidence, the public record cannot identify who depends on the network. It cannot say whether a local community, a business district, government services or other providers would be affected by a failure. Dependency claims require evidence of usage, not only address space.

Power and redundancy remain open as well. A route table does not show backup power, generator contracts, battery autonomy, dual utility feeds, independent fibre paths, emergency spares, field crew availability or restoration time. Even a visible AS can be fragile if the physical layer is concentrated. It can also be robust if built with independent paths and disciplined operations. The present public evidence does not decide between those possibilities.

That uncertainty does not weaken the infrastructure value of the profile. It makes the value more specific. Blue Sky Broadband can be described as an inspectable number-resource holder with a visible route footprint. The public record does not yet support a stronger conclusion about service delivery. The result is a useful baseline for future monitoring rather than a verdict on the network.

The title promises a boundary, not a verdict

The title, AS134945 puts Blue Sky Broadband in public routing view while the delivery chain still needs proof, captures both sides of the public evidence. The AS is visible. The company is named. The prefixes are listed. The physical system behind those prefixes is not established. That balance is more durable than a title that calls the company a resilient network, a major broadband operator, a verified access provider, a capacity platform or a critical service.

The deck paragraph carries the same boundary. It describes the APNIC-derived registry identity, the announced=true state and the four /24 routes, then states what remains unproven. It does not sell the company or dramatize the route data. It explains why a narrow infrastructure record matters: public routing evidence can show a control surface while leaving the service chain opaque.

The summary follows the same structure. One bullet states the holder and the visible prefixes. The other states the boundary: visible IPv4 routes are not evidence of access footprint, capacity, redundancy, power or customer dependency. The pairing gives readers the useful takeaway before they reach the detailed registry and routing fields.

That framing also protects the article from unsupported claims. The public record does not justify statements about customer numbers, service quality, geographic reach, outage performance or resilience. It does justify a controlled analysis of registry identity, route visibility and unresolved delivery proof. The title therefore points to the real evidence rather than to a conclusion the evidence cannot support.

Why this belongs in regional ISP coverage

The safest navigation category for this profile is regional ISP or network-identity coverage, subject to the active site taxonomy. The reason is not that the current record proves a broad service region. It does not. The reason is that the subject is a company with an autonomous system and visible prefix footprint associated with broadband naming. The article is about public Internet infrastructure evidence, not software, finance, data centres or general business operations.

The category choice remains conservative. If the active taxonomy has an Asia-Pacific regional ISP leaf, that leaf fits the APNIC and India context. If admission only supports a broader regional-ISP category, the bundle can use that broader leaf. The category should not imply a verified service geography beyond the evidence. It is a navigation label for the type of infrastructure subject, not proof that the company serves a mapped region.

The topics are also controlled. Useful topics are autonomous-system registry, routing visibility and number-resource recordkeeping. The durable monitoring object is the gap between registry identity and route visibility. The topic should not be the company name, the AS number alone, a country string, or a loose keyword unless the controlled taxonomy defines it. The value of the profile is that similar questions can be asked across many number-resource holders.

The same logic applies to image choice. A generic network-control image matches the regional-ISP and routing-visibility frame because it illustrates the type of control surface being discussed. A branded broadband van, tower, office, data-centre room or cable route would overstate the evidence. A plain, unbranded image is not weaker; it is safer and more accurate.

Future evidence could change the operating assessment

Several future facts would change the operating assessment. Route data could show additional prefixes, withdrawals, origin changes, upstream neighbours or more specific visibility over time. Routing-security evidence could show whether route-origin authorization exists for the visible prefixes. Public peering or transit records could identify upstream dependency. Official service documents could identify geography, customer types or product boundaries. Regulatory filings could clarify licences or service obligations. Outage reports could show failure history and recovery behaviour.

None of those facts is present in the current public record. That is why the operating judgement stays open. As of the captured RIPEstat responses, AS134945 is announced and four /24s are visible. APNIC-derived WHOIS names Blue Sky Broadband in the AS record and exposes maintainer and IRT references. The delivery chain, service footprint and resilience model remain outside the evidence.

A future update could also narrow the role of the visible prefixes. If another public source showed that the prefixes are used for a specific access product, the route data could be connected to customer dependency. If it showed that the prefixes are routed through a single upstream, the resilience question would sharpen. If it showed multiple independent paths, the analysis would change again. The current profile leaves those possibilities open rather than pretending to know them.

The watchpoints are practical. Watch AS134945 for prefix changes. Watch for public route-security data. Watch for independent evidence of upstream relationships. Watch for service-region documentation. Watch for outage or maintenance history. Watch for official statements that connect the AS to a physical delivery platform. Each item would move the profile from a registry-and-routing boundary toward a fuller operating profile.

Until then, the most accurate assessment is modest. Blue Sky Broadband is visible through a public AS holder string and four IPv4 /24 route announcements. That is enough to make the company part of infrastructure coverage. It is not enough to describe the company as a proven resilient access network.

The address blocks create a narrow public control surface

The four visible IPv4 /24s also show why address blocks are a control surface rather than a company biography. An address block can be originated, withdrawn, filtered, transferred, documented, misdocumented, delegated to customers, placed behind access aggregation or used for internal infrastructure. Public routing evidence can show that a block is visible under an origin AS. It cannot show every operational decision that gives the block meaning inside a company network. That is why the number-resource layer is useful and limited at the same time.

For AS134945, the useful public control surface is narrow but concrete. The visible set is four adjacent IPv4 /24s, all in the 103.84.236.0/24 through 103.84.239.0/24 range. The route collector view associates those prefixes with the AS during the captured window. The WHOIS response associates the AS name and description with Blue Sky Broadband Pvt. Ltd. Together, those facts create a stable reference for monitoring public origin state. They do not create a full map of use inside the network.

This narrowness matters for operational continuity. If a future observation showed one of the four /24s withdrawn, that would not automatically prove an outage. It could reflect a route policy change, a measurement gap, maintenance, aggregation, provider filtering, address-use change or a real service disruption. If a future observation showed the same prefixes originated by a different AS, that would deserve close review but still require context. The route table can expose a change. It cannot always explain the cause.

The same logic works in the other direction. The continued visibility of four prefixes would not prove that all services are healthy. A route can stay visible while some customers are affected by local access faults, congestion, power problems or customer-premises failures. The route table sees the control-plane signal. It does not measure every last-mile experience. That difference is especially important for broadband-labeled companies, where readers may be tempted to equate public route visibility with delivered service.

Blue Sky Broadband's current public footprint should therefore be read as a baseline for control-surface accountability. The AS holder is named. The prefixes are visible. Registry contacts exist. Those facts make the company inspectable in the public Internet record. The unresolved operating layer remains unresolved until separate evidence identifies upstream relationships, physical plant, customer usage, outage history or service obligations.

Operational continuity would need a different evidence layer

Operational continuity is not visible just because the AS is announced. Continuity would require evidence that the network can keep traffic moving when something breaks. That might include independent upstreams, alternate transport paths, backup power, documented repair processes, route security controls, monitoring practices, spare equipment and clear contact points. Some of those signals may appear in public routing or registry systems. Others usually require official company disclosures, regulator filings, outage notices, procurement records, third-party network measurements or customer-facing documentation.

The current public record provides only part of that chain. The maintainer and IRT fields show registry-side contact structure. The announced-prefixes response shows public route origination. The AS overview shows that the AS is currently visible. Those are necessary building blocks for accountability, but they are not continuity evidence by themselves. They do not show whether the same operator can restore service after a fibre cut, whether a secondary upstream exists, whether equipment is geographically diverse, or whether abuse and security contacts respond in practice.

A continuity assessment would also need temporal depth. One snapshot can show that routes are visible in a particular query window. It cannot establish long-term stability. A stronger public record would compare route visibility across longer periods, check for withdrawals, inspect origin changes, and look for route-security material where available. It would also separate collector visibility from end-user service availability. A prefix can disappear from one view for reasons unrelated to a customer outage, and a customer outage can occur while the prefix remains globally visible.

The operating question is therefore not whether AS134945 exists in the public record. It does. The question is what that record allows a reader to conclude. It allows a conclusion about inspectability: Blue Sky Broadband is named around a currently announced AS and four visible IPv4 /24s. It does not allow a conclusion about continuity: the path from route origination to delivered service remains undocumented in the current public materials.

That limitation is valuable because it prevents false certainty. Infrastructure analysis often becomes less useful when it converts every public identifier into a verdict about reliability. The better approach is to identify the layer being observed and the layer still missing. For Blue Sky Broadband, the observed layer is ASN/IP registry and BGP/routing visibility. The missing layer is the physical and operational continuity surface behind that visibility.

The baseline gives future checks a clearer target

A baseline article does not need to settle the entire company profile to be useful. It can identify the exact public objects that future checks should revisit. For Blue Sky Broadband, those objects are AS134945, the four visible IPv4 /24 prefixes, the APNIC-derived WHOIS record, the BLUESKY8-AS name, the maintainer references, and the IRT reference. If future public evidence changes any of those elements, the change can be evaluated against the baseline rather than treated as an isolated observation.

The most direct future check is prefix continuity. The four /24s can be watched for withdrawal, more-specific announcements, route-origin changes or changes in visible origin state. Another check is registry continuity: maintainer, contact, source and last-modified fields can change over time. A third check is source enrichment: public material may later identify upstreams, service regions, route security data, regulatory obligations or outage history. Each added layer would either strengthen the operating profile or reveal a narrower role for the AS.

This future-check frame keeps the subject grounded in public evidence. It avoids presenting the company as either more important or less important than the record supports. A company with four visible /24s may be significant to a specific customer base or may be operationally modest. The current record does not decide. What it does show is that the company is not invisible at the public-number-resource layer. That visibility is enough to justify an evidence-bound profile and a watchlist.

The baseline also protects against a common error in directory-linked company coverage: treating a company description as infrastructure proof. The directory object establishes the subject. The routing and registry data establish the public Internet surface. Neither layer alone proves a physical service chain. Keeping the layers separate makes the article more accurate and more reusable. The same method can be applied to other regional operators, hosting providers, broadband companies and network-resource holders whose public footprints are visible but incomplete.

For readers, the practical takeaway is simple. AS134945 is currently visible and names Blue Sky Broadband in the public registry/routing record. Four IPv4 /24s are visible. The public record supplies maintainer and IRT references. The record does not yet show customer dependence, access geography, redundancy, power or recovery. That combination creates a clear starting point for monitoring, and it also defines the proof that remains missing.

The same baseline is also useful for avoiding false negatives. A compact route footprint should not be dismissed merely because it is small. Four visible /24s may still matter to the users or systems behind them. The public record cannot measure that dependence, but it can show that a named company has a route surface worth monitoring. That is enough for a bounded profile without converting the evidence into an operational verdict.

The useful conclusion is a boundary, not a judgement

The conclusion should not declare Blue Sky Broadband strong, weak, active, inactive, resilient or unreliable. The public record does not support those verdicts. It supports a boundary. AS134945 names Blue Sky Broadband in APNIC-derived registry data. RIPEstat currently sees the AS as announced and lists four visible IPv4 /24 prefixes. WHOIS records maintainers, an IRT reference, APNIC as source and a last-modified timestamp. Those public records show an inspectable number-resource and routing surface.

The same records leave the delivery chain unresolved. They do not show access media, physical route diversity, powered sites, upstream concentration, customer dependency, capacity, service geography, outage history or recovery behaviour. A reader who needs to understand the company's operational role would need more evidence. The current profile identifies the public control surface and the missing operating proof, which is a useful starting point.

That is the right balance for a Mara Voss infrastructure company article. It follows the physical dependency as far as public evidence allows, then stops before invention. It treats the registry as a ledger, the route table as running evidence, and the physical network as unproven until sourced. It avoids advocacy, avoids promotional copy and avoids unsupported allegations.

For Blue Sky Broadband, the route table provides a clearer signal than a silent AS would provide. Four visible /24s make the public footprint observable. The lack of physical-service evidence keeps the analysis disciplined. The result neither ignores the route evidence nor exaggerates it. It shows what the Internet's public record can say about AS134945, and it shows exactly where that record stops.

Sources