Inside The Internet, Inc and AS14473 show two announced IPv4 prefixes with uneven RPKI coverage

Summary

ARIN and RIPEstat records connect Inside The Internet, Inc with AS14473 and two currently announced IPv4 prefixes in the reviewed public evidence.
The same evidence shows uneven RPKI coverage and supports only a bounded registry/routing/control-surface analysis, not claims about customers, facilities, capacity, reliability or business outcomes.

The narrow finding

The defensible company-specific finding is concise. ARIN's public registration data identifies organization handle INSID-1 as Inside The Internet, Inc, records a United States address for it, and names that organization as the registrant of autonomous system number AS14473. Separate ARIN ASSIGNMENT records for 63.88.42.0/23 and 107.0.20.0/24 use distinct customer handles while repeating the company name. That name agreement supports a bounded association, but it is not evidence that the blocks are direct allocations to INSID-1.

RIPE NCC's RIPEstat observations add a running-network layer to that registry layer. In the responses reviewed on 5 August 2026, AS14473 is marked as announced. The two registered address blocks appear as current announced prefixes. A routing-status observation records the most recently observed route at 2026-08-05T00:00:00Z and reports IPv4 visibility from 327 of 327 RIPE Routing Information Service peers in that observation. Collector paths in the reviewed BGP-state response terminate at AS14473 for both prefixes.

The security metadata is not uniform. For the 5 August 2026 observation, 107.0.20.0/24 with origin AS14473 is RPKI valid. The other announced prefix, 63.88.42.0/23, is RPKI unknown and has no validating Route Origin Authorization in the response. It would therefore be inaccurate to describe both prefixes as RPKI validated.

One additional consistency response says the two current prefixes are present in both the Border Gateway Protocol and an Internet Routing Registry, while an older 8.25.16.0/24 routing-registry object is not present in BGP. That older object is not part of the two-prefix current footprint described above. It is useful only as a reminder that a record in a routing registry and a route observed in the live routing system are different kinds of evidence.

That is the complete company-specific evidentiary core. The sources do not disclose the company's internal topology, devices, software, staffing, facilities, upstream providers, downstream customers, commercial products, traffic levels, service-level commitments, outage history, security incidents, financial results or customer outcomes. They also do not establish why one prefix has valid RPKI origin authorization while the other is unknown. Any account that filled those gaps with confident detail would be inventing facts.

A plain-language map of the network records

The technical jargon in this analysis is explained at first use so that each public record can be read without assuming specialist network training.

The Internet is made of independently operated networks that exchange information about where traffic should go. An autonomous system, usually shortened to AS, is one of those independently administered routing domains. An autonomous system number, or ASN, is the unique number used to identify it in interdomain routing. AS14473 is the number connected to Inside The Internet, Inc in the reviewed ARIN and RIPEstat records.

An IP address prefix is a block of addresses written in a compact form. In 107.0.20.0/24, the /24 indicates the size of the block. In 63.88.42.0/23, the /23 represents a larger block than a /24. The reviewed ARIN responses identify the first as the range 107.0.20.0 through 107.0.20.255 and the second as 63.88.42.0 through 63.88.43.255. This analysis does not infer how the addresses are assigned internally or what systems use them.

The Border Gateway Protocol, or BGP, is the mechanism networks use to announce reachable prefixes and exchange paths between autonomous systems. A BGP announcement is not a packet-by-packet map. It is a statement, propagated through the routing system, that a prefix can be reached through a particular path. The origin AS is the final autonomous system in that advertised path. In the collector state reviewed on 5 August 2026, paths for both current prefixes terminate at AS14473.

A routing collector listens to route information from participating networks and stores what those observation points report. RIPE RIS is such an observation system. When the reviewed routing-status response says AS14473 had IPv4 visibility from 327 of 327 RIS peers, the precise meaning is that all 327 peers represented in that response saw relevant IPv4 routing information under that method and at that time. It does not mean every network, device or user on the Internet was tested. It is not a promise about future visibility. It is not a measurement of application performance.

An Internet Routing Registry, or IRR, stores routing-policy objects that operators can publish. An IRR object expresses intended or registered routing information. BGP collector data expresses routes that were actually observed. The consistency result reviewed on 5 August 2026 reports that the two current prefixes are present in both BGP and IRR, but that an older 8.25.16.0/24 IRR object is not in BGP. That difference illustrates why a record of intent must not be substituted for a live observation.

The Resource Public Key Infrastructure, or RPKI, provides cryptographically verifiable information about which autonomous system is authorized to originate a prefix. A Route Origin Authorization, or ROA, is the signed object that states that authorization within defined limits. A route can be classified as valid when the observed origin is covered by a matching authorization. An unknown or not-found result means the relevant validation data does not provide such a validating statement; it does not, by itself, prove that the route is malicious or operationally broken. In the public evidence reviewed on 5 August 2026, 107.0.20.0/24 is valid for AS14473, while 63.88.42.0/23 is unknown.

RDAP, the Registration Data Access Protocol, is a structured way to retrieve public registration data. WHOIS is an older registration-data system and term. The reviewed ARIN RDAP and RIPEstat-backed WHOIS responses connect the company name, organization handle, ASN and address information. Those registration systems operate as public record layers. They identify relationships recorded by the registry; they do not expose the complete internal operation of the registered organization.

These definitions matter because public infrastructure data is easy to overread. A registry record, a live route, a policy object and a cryptographic authorization answer different questions. Treating all four as a single green or red status removes the distinctions an operator needs in order to supervise the system.

Four evidence levels: model, capability, reliability and outcome

A disciplined analysis should separate four levels that are often collapsed in sales copy or hurried technical reporting: the public model, demonstrated capability, measured reliability and customer outcome.

1. The public model

The public model is the map formed by identifiers and relationships. In this case, the model connects INSID-1 to the legal-style company name in ARIN's record and connects that organization to AS14473. Two separate IPv4 assignment records use different customer handles but repeat the same company name. RIPEstat repeats the holder name for the ASN, and its WHOIS response repeats the ASN, organization handle, company name and US address information.

This model supports basic statements about recorded identity and number-resource relationships. It helps a researcher avoid confusing two similarly named organizations. It gives operators and counterparties identifiers that can be compared across systems. It provides a starting point for questions about routing and authorization.

The model does not reveal everything behind those identifiers. It does not say which routers announce the prefixes, how many sites exist, how traffic is engineered, which people hold credentials, what monitoring is installed, or what contracts govern service. It is a public control map, not an internal architecture diagram.

2. Demonstrated capability

Capability asks whether the system has shown that it can perform a function. The reviewed routing evidence demonstrates a narrow capability: both registered prefixes were observed as announced by AS14473, the routing-status response recorded visibility through its full set of 327 IPv4 RIS peers, and current collector paths terminated at AS14473.

That observation is stronger than a registry entry alone. A registration says which organization is recorded in connection with a resource. A BGP observation says a route appeared in the running interdomain system. When the IRR and BGP consistency response also lists the two current prefixes in both systems, it adds another form of agreement between intended records and observed routing.

Still, capability is bounded by the observation. It shows that route propagation happened in the reviewed window. It does not establish continuous performance before or after that window. It does not show that every packet reached the intended destination. It does not measure latency, loss, congestion, path stability, application response or recovery behavior.

3. Reliability

Reliability asks whether a capability is delivered consistently over time and under expected variation. Answering it requires repeated observations, a defined service, a time window, failure criteria and a method for handling maintenance and measurement gaps. The public source set reviewed on 5 August 2026 is a point-in-time evidence package. It does not contain a longitudinal availability series, incident log, service-level report, repeated active probes or customer-ticket history.

Therefore, the public evidence reviewed on 5 August 2026 cannot support a reliability percentage or qualitative verdict such as "highly reliable." Even 327-of-327 collector visibility in one response is a current routing observation, not an uptime benchmark. Likewise, the valid RPKI state of one prefix is evidence of matching origin authorization for that prefix at that time, not proof that all routing changes will always be correct or that every network will enforce RPKI-based policy.

Reliability also has several layers. The public registration layer may be accurate while a route is withdrawn. A route may be visible while the application behind the addresses is unavailable. A route may be visible and the application reachable while a customer workflow fails. Without evidence from each layer, a researcher should not assign one layer's status to another.

4. Customer outcomes

Customer outcome asks whether a service helped a customer achieve an intended result. That result might concern reachability, business continuity, operational effort, recovery time or another defined objective. The public records reviewed on 5 August 2026 contain no customer testimony, contract, service-level result, application measurement, support record, retention statistic or business benchmark. They do not identify any customer.

No customer-result claim is therefore available. The manuscript cannot say that Inside The Internet, Inc improved availability, reduced costs, accelerated delivery, prevented an incident or satisfied a particular market. It also cannot claim the opposite. Public routing evidence can establish that a route was observed; it cannot stand in for the customer's own end-to-end experience.

This four-level separation is not merely cautious wording. It identifies what additional evidence would be needed to move from one level to the next. Recorded identity and resource relationships support the public model. Collector and validation observations support narrow capability statements. Reliability requires repeated and defined measurement. Outcomes require evidence at the customer and application layer.

The registry is a ledger, not a complete operating picture

The relevant reality-layer principle is "registry as ledger and recordkeeper, not sovereign." In practical terms, a registry keeps authoritative records within a bounded domain. ARIN's public data connects an organization handle, company name, ASN and address resources. Those records matter because number resources must be distinguishable, traceable and transferable through documented processes.

But a registry entry does not operate the network. It does not select a BGP path, configure a router or answer an application request. The running system is visible through a different evidence surface: routing observations. The public data reviewed on 5 August 2026 happens to show agreement between the registration identity and the current origin information, but the agreement must be demonstrated rather than assumed.

This distinction creates a useful control discipline. An operator or reviewer can ask at least four separate questions:

Identity: Is the resource still recorded under the correct organization and handle?
Intent: Do routing-policy records describe the prefixes expected to be originated?
Running state: Are collectors observing the expected prefixes and origin ASN?
Security metadata: Does RPKI validation show a matching authorization for each announcement?

The public records reviewed on 5 August 2026 answer those questions differently. Identity is supported by ARIN RDAP and the WHOIS response. Intent and observed state agree for the two current prefixes in the consistency response. The running state shows both prefixes. Security metadata is mixed because one prefix is valid and the other unknown.

If those answers were compressed into "the network is registered and online," the most actionable difference would disappear. The mixed RPKI state is not a reason to invent a failure, but it is a reason to preserve prefix-level detail. Likewise, the older IRR object that is not in BGP should not be called a current announcement. It belongs to a record-consistency question, not the current two-prefix route footprint.

Why running-code evidence has priority

Documents and records describe intended state. A running network produces observable state. Neither should be ignored, but when the question is "what is being announced now?" live routing observations are more directly relevant than a registration or policy object alone.

The public evidence follows that principle by combining ARIN records with RIPEstat routing data. ARIN connects INSID-1 to the ASN, while two separate assignment records repeat the company name for the address blocks. RIPEstat reports the ASN as announced, lists the two current prefixes, gives a current routing-status observation and supplies collector paths ending at AS14473.

Running-code priority does not mean one measurement becomes absolute truth. A collector sees the routing system from its participating peers and at particular times. Its evidence is strong for the proposition that those peers observed the routes, but it is not omniscient. A careful account keeps the observer, time and scope attached to the finding. That is why the exact statement "327 of 327 RIS peers in the reviewed IPv4 routing-status response" is preferable to "visible everywhere."

The same principle applies to security metadata. A valid RPKI result for 107.0.20.0/24 is a specific result for that prefix and origin combination. The unknown result for 63.88.42.0/23 is also specific. A network-level label such as "RPKI protected" would erase the difference.

Operationally, running-code priority encourages reconciliation rather than trust in any single database. The operator compares registered resources, intended routing objects, observed announcements and authorizations. The researcher compares public claims with observable records. The customer, if evaluating outcomes, adds application and business evidence rather than assuming route visibility settles the question.

The work behind a small public footprint

Two announced prefixes and one ASN may look simple in a table. Simplicity of the visible footprint does not eliminate operational work. It concentrates attention on a small number of records whose relationships must remain coherent. The public records reviewed on 5 August 2026 do not disclose how Inside The Internet, Inc performs that work, what tools it uses or how much it costs. The following sections are therefore an analytical framework, not a report of the company's internal practices.

Supervision cost

Supervision is the work of observing the system, deciding whether an observation is normal and assigning responsibility when it is not. For an interdomain routing footprint, supervision can involve comparing expected prefixes with collector observations, checking origin AS values, reviewing validation state and noticing when public records disagree.

The evidence package itself illustrates why human interpretation remains necessary. A simple dashboard could show two routes as present. A second check is needed to distinguish the valid RPKI state of 107.0.20.0/24 from the unknown state of 63.88.42.0/23. A third check is needed to avoid treating the older 8.25.16.0/24 IRR object as a currently announced prefix.

Automation can collect and compare fields, but a person or accountable process must define what constitutes a mismatch, how long it may persist, whether the observation source is complete enough for the decision, and who is allowed to change the relevant system. A missing route at one collector could reflect a real withdrawal, a collector-specific gap, a policy choice or a transient event. The public evidence does not tell us which supervision process this company uses.

Supervision also has a scope cost. A route-level monitor does not measure the application. A registry monitor does not prove the route is visible. An RPKI validator does not tell a customer whether a service transaction completed. Every monitored layer needs a defined question, and the handoff between layers needs ownership. Without that discipline, teams may collect many green indicators while overlooking the layer where the actual failure occurs.

Integration cost

Integration is the work of keeping different systems and responsibilities connected. In this setting, the public evidence spans ARIN registration data, IRR objects, BGP collector observations and RPKI validation. These systems do not carry identical information or update through one universal transaction.

The reviewed agreement is useful: the company identity, ASN and two current prefixes line up across several records, and the current prefixes are present in both BGP and IRR. Yet the mixed RPKI result shows that consistency must be checked field by field. The public sources do not explain the workflow behind that difference, so no cause should be assigned.

An integration process generally needs stable identifiers. The organization handle INSID-1, ASN 14473 and exact prefix strings provide those keys in the public evidence reviewed on 5 August 2026. Names alone are weaker because punctuation and abbreviations can differ. The RIPEstat ASN holder field uses I3ASN1-200E - Inside The Internet, Inc, while ARIN supplies the organization handle and exact company name. The identifiers allow the records to be related without pretending every display string is identical.

Integration has timing risk as well. One system may update before another. A planned routing change may be visible in a policy registry before it is announced, or an old object may remain after the live route disappears. The 8.25.16.0/24 IRR-only item in the reviewed consistency response is a concrete example of a record that should not be elevated to current BGP state. It does not establish an error or incident; it establishes a difference that needs the right interpretation.

Maintenance cost

Maintenance is the recurring work required to keep records, authorizations, monitoring and operational procedures usable as conditions change. Number resources can persist while contacts, credentials, systems and business relationships change. The public records reviewed on 5 August 2026 do not describe any such change at Inside The Internet, Inc, but they show the public objects that would have to remain coherent through change.

Registration data must continue to point to the appropriate organization identity. Routing-policy objects must continue to describe intended announcements. BGP sessions and routing policy must continue to produce the intended origin state. RPKI authorizations, where used, must remain compatible with the prefixes and origin ASN that appear in the routing system. Monitoring rules must be revised when the expected set changes. Documentation must allow another authorized person to understand what the expected state is.

The split RPKI status makes maintenance boundaries visible. One current prefix has a valid result, while the other has no validating ROA in the response reviewed on 5 August 2026. The evidence does not say whether this is deliberate, transitional or overlooked. A maintenance process would need to know the intended policy before deciding whether to change anything. Blindly making the two statuses match would be as unjustified as ignoring the difference.

Maintenance also includes evidence quality. Observation dates and source boundaries matter because public routing responses can change. A responsible assessment should preserve what was observed rather than silently treating a later result as if it were the earlier one. That makes it possible to distinguish a change in the public record from a change in interpretation and to ask whether a conclusion remains current.

Exception cost

An exception is a case that does not follow the expected automated path and therefore needs investigation, judgment or authorized intervention. Exceptions are often where the real operating cost appears. A routine comparison can be cheap; determining why two records disagree can require access to several systems and coordination across organizational boundaries.

The public evidence reviewed on 5 August 2026 presents two difference patterns without proving that either caused operational harm. First, RPKI validation differs by current prefix. Second, an older IRR object exists without a matching BGP announcement. A useful exception process would keep these patterns separate. The first concerns security authorization metadata for an observed route. The second concerns the relationship between a policy registry and running BGP state.

Exception handling needs an evidence trail. The investigator must record the expected state, the observed state, the observation time, the source, the affected object and the decision. If a change is made, the process should also record who authorized it and how closure was verified. Public records can supply the observation layer, but they do not reveal the company's tickets, decisions or corrective actions.

Exceptions also expose authorization limits. A person who can observe a mismatch may not have permission to change registry data. Someone who can update a ROA may not control router configuration. A customer support representative may see a complaint but lack access to routing systems. Good operations depend on clear escalation paths between those roles. Nothing in the public evidence reviewed on 5 August 2026 identifies Inside The Internet, Inc's roles or escalation process, so this remains a general framework.

Failure modes the evidence framework should detect

The following failure modes are analytical scenarios. They are not allegations that any occurred at Inside The Internet, Inc. Each scenario explains what could go wrong in a network-resource control chain, what the reviewed source types could reveal, and what evidence would still be missing.

1. Registry identity drift

The organization recorded for a resource could become outdated or inconsistent across public systems. A name may change, a resource may be transferred, or a contact relationship may no longer reflect the accountable operator. In the reviewed state, ARIN RDAP and the RIPEstat-backed WHOIS data consistently connect INSID-1, AS14473 and Inside The Internet, Inc.

That agreement reduces ambiguity for this observation, but it is not permanent proof. Detecting later drift would require a new comparison. Determining whether a difference is an error, an authorized change or a display-format variation would require transaction history or authoritative confirmation not contained in public evidence.

2. Registered but not announced

An address block can remain registered while no BGP route for it is observed. Registration and reachability are separate layers. In the reviewed state, both registered blocks are also listed as current announcements from AS14473.

If a future collector no longer saw one route, that would not by itself identify the cause. It could represent a planned withdrawal, routing-policy change, session failure, upstream filtering, observation limitation or another condition. Reliable diagnosis would require time-series and operator evidence beyond this source set.

3. Announced by an unexpected origin

A prefix could appear in BGP with an origin ASN different from the expected one. The reviewed BGP-state paths terminate at AS14473 for both current prefixes, and the ASN is registered to Inside The Internet, Inc.

An unexpected origin would merit investigation, but it should not be labeled a hijack without evidence about authorization and operational context. Legitimate transitions and multi-operator arrangements can change origin information. The public sources reviewed on 5 August 2026 do not describe such arrangements for this company.

4. Route visible but RPKI not valid

A route can be visible even when no matching RPKI authorization validates its origin. That is the precise difference shown for 63.88.42.0/23: RIPEstat lists it as announced by AS14473, while the reviewed validation response classifies the combination as unknown with no validating ROA.

Unknown is not the same as invalid, and neither should be translated automatically into an outage or attack claim. The observation identifies a metadata gap relative to validated coverage. Assessing operational impact would require evidence about relying-party policy, route propagation over time and intended authorization.

5. Authorization conflicts with the live route

If a ROA authorized a different origin or prefix length than the live route, validation could become invalid. The reviewed 107.0.20.0/24 result is valid for origin AS14473, so that failure is not present for that prefix in this observation.

The valid result still does not prove that every future change will remain valid. Route and authorization changes have to be coordinated. A maintenance process should check the proposed route against authorization before and after a change rather than assuming an existing valid state will persist.

6. Policy registry and live routing diverge

An IRR object can exist without a corresponding BGP announcement, or a BGP announcement can lack the expected policy object. The reviewed consistency response lists the two current prefixes in both systems but also lists an older 8.25.16.0/24 IRR object not present in BGP.

That difference does not reveal whether the older object is intentionally retained, stale or used for another purpose. It does show why inventory systems must classify objects by evidence type. Calling every IRR object a live route would produce a false network map.

7. Collector visibility changes

Route visibility can vary across collectors or peers. The reviewed routing-status response reports 327 of 327 RIS IPv4 peers for AS14473 at the recorded observation. A later reduction would be a signal, not a complete diagnosis.

Interpreting a visibility change requires the denominator, peer set, time window and route-level details. A percentage without those details can mislead. Customer impact would require still more evidence because a routing collector is not an end-user application monitor.

8. Public route remains visible while the service behind it fails

BGP can continue to advertise a prefix even if a server, application or customer workflow behind the route is unavailable. The public sources reviewed on 5 August 2026 do not test any application or identify any hosted service. Consequently, the current routing observations cannot support a statement that a website, API, customer network or other service was functioning.

This failure mode is important because routing evidence is sometimes used as a proxy for availability. It is only one prerequisite. End-to-end testing would need a defined destination, protocol, expected response, observation point and time series.

9. Service works at one point while reliability remains unknown

A successful observation proves that success was possible under the observed conditions. It does not establish how often the operation succeeds. The current route data demonstrates observed capability; it contains no repeated application tests or duration-based service measure.

Reliability reporting would need a denominator: successful events out of all defined attempts, or available time out of a defined period, with maintenance and ambiguous intervals handled consistently. None of those ingredients is in public evidence.

10. Technical capability fails to produce a customer outcome

A route can be visible, validly authorized and operational while a customer still fails to achieve an intended business task. The cause could be elsewhere in the application, identity, data, contractual or organizational chain. Conversely, a customer may achieve a task despite a control weakness that has not yet caused visible harm.

The public records reviewed on 5 August 2026 contain no customer-outcome evidence. A responsible manuscript must therefore stop at network-control findings and explain what additional customer-side evidence would be required.

11. Monitoring generates an ambiguous alert

A monitoring system can correctly detect a difference without knowing whether the difference is harmful. The unknown RPKI state of one prefix is a good example of a condition that should be described precisely before a decision is made.

An alerting rule that translated every unknown result into "route invalid" would be technically wrong. A rule that ignored all unknown states would lose potentially useful coverage information. Exception handling must preserve the source classification and apply an intended-policy decision.

12. A corrective action changes the wrong layer

When records disagree, an operator could modify the registry, policy object, authorization or live route. Choosing the wrong layer may replace an accurate record with an inaccurate one. The public records reviewed on 5 August 2026 do not specify intended configuration beyond the observed alignments.

The safe sequence is analytical: identify the object, identify the authority for that object, establish intended state, obtain authorization, make the bounded change and verify both the changed layer and dependent layers. This sequence is a general control principle, not evidence about company practice.

What the mixed RPKI state means, and what it does not

The RPKI difference is the most important nuance in the reviewed source set because it prevents a one-line security conclusion.

For 107.0.20.0/24, RIPEstat's reviewed validation response says the route with origin AS14473 is valid. The supported statement is that a matching RPKI authorization covered that origin-prefix combination in the response.

For 63.88.42.0/23, the response says unknown and reports no validating ROA. The supported statement is that the validation system did not find a validating authorization for that origin-prefix combination in the response.

Several stronger statements are not supported:

The evidence does not show that the unknown route was invalid.
It does not show that the route was rejected by other networks.
It does not show that traffic failed.
It does not show why authorization was absent.
It does not show whether the state was intentional.
It does not show a security incident.
It does not show customer impact.

The route was nevertheless observed as announced, and the reviewed routing-status evidence reports broad visibility within the RIS peer set. That combination is exactly why capability and security metadata must remain separate fields. The routing system can propagate a route without RPKI providing a valid result. Different networks may use routing security information differently, and public evidence contains no evidence about their individual policy decisions.

The right operational question is not "Is the whole network secure?" That question is too broad for the data. Better questions are prefix-specific: What is the observed origin? What is the current validation state? What state is intended? Does the relevant authorization cover the planned route? Has the result changed? Who owns reconciliation if it differs from intent?

Reading the 327-of-327 observation correctly

The number 327 can look like a performance score, but that would be a misuse. In the reviewed routing-status response, it describes IPv4 route visibility from the RIS peers represented in the observation.

The observation supports a narrow and meaningful point: AS14473's IPv4 routing information was not limited to a small subset of the included peers at that recorded time. It is evidence of route propagation within the collector's view.

It does not establish:

100 percent service availability;
universal Internet visibility outside the observation method;
packet delivery to every address;
low latency or low packet loss;
stability across a day, month or year;
customer application success;
compliance with a service-level agreement;
absence of an outage before or after the observation.

A reliability study would collect the same or comparable metric repeatedly, specify which prefixes must be visible, define how collector changes are handled, and correlate route changes with active network and application measurements. A customer-outcome study would then connect those technical states to the customer's intended transactions. This article performs neither study.

The distinction also protects the operator from unsupported negative claims. If one peer failed to see a route in another observation, it would be premature to declare a general outage. The investigator would first determine which route, which peer, which time, which path and whether the observation persisted.

Questions for buyers, partners and operators

The public evidence is most useful when it generates precise due-diligence questions rather than a synthetic score.

Questions about recorded control

Is INSID-1 still the intended organization record for AS14473, and do the two separate customer-handle assignment records still identify the intended company?
Which roles are authorized to request changes to the organization, ASN and network records?
How are changes reviewed, approved and later audited?
How are stale contacts or inaccessible credentials recovered?

The public records reviewed on 5 August 2026 answer only the first question for their observation.

Questions about route intent and observation

Are 63.88.42.0/23 and 107.0.20.0/24 the complete intended current announcement set?
What explains any IRR object that is not currently observed in BGP?
How are unexpected origins, withdrawals or visibility changes detected?
Which observation sources and time windows are used before declaring an incident?

The public evidence shows the two current announcements and the older IRR-only object, but it does not provide internal intent or monitoring policy.

Questions about routing security

Is the RPKI-unknown state of 63.88.42.0/23 intended?
What change-control process coordinates ROAs with planned route changes?
How are invalid, unknown and valid results distinguished in alerts?
How is validation checked from more than one evidence surface when a decision is important?

The source set provides current classifications, not their operational rationale.

Questions about reliability

What service is being measured: route visibility, IP reachability, transport, an application or a customer workflow?
What is the measurement window and denominator?
Which failures are excluded, and why?
How are maintenance, third-party dependencies and observation gaps treated?
What evidence links a technical indicator to a customer result?

The reviewed public sources contain no reliability or customer-outcome dataset. These questions must be answered with additional evidence before a reliability claim is made.

Questions about operating cost

Who reviews route and registry differences?
Which comparisons are automated, and which require judgment?
How often are public records and security authorizations reconciled?
What is the escalation path when the observer cannot change the affected system?
How is closure verified after an exception?

No answer about Inside The Internet, Inc's staffing, tools or cost is available in the public records reviewed on 5 August 2026. The questions expose the work that a public routing footprint alone does not show.

What a stronger reliability study would require

The public evidence package can serve as a baseline, but not as a reliability study. To assess reliability without overclaiming, a future owner would need to define the subject and measurement before gathering more data.

First, the subject must be explicit. "The network" is too broad. A study might examine persistence of BGP announcements, reachability of selected addresses, transport behavior to a controlled endpoint or availability of a named application. Each subject has a different failure definition.

Second, the expected state must be reviewed. For routing, that would include the intended prefix set, intended origin ASN and relevant authorization state. The current package provides a two-prefix observed baseline but does not declare internal intent.

Third, observations must be repeated across a stated period. A single routing snapshot cannot yield an availability rate. The study would need a schedule, multiple observation points, gap handling and an audit trail for changes to the measurement system.

Fourth, failures need attribution boundaries. A missing collector route, failed active probe and failed application transaction are not interchangeable. The study should preserve each layer and explain when correlation is evidence of causation and when it is not.

Fifth, customer outcomes must be measured separately. A customer claim requires a defined population or case, a baseline, the intervention or service being evaluated, and a result. None should be inferred from route presence.

Finally, the study should report uncertainty. Changes in peers, routes, maintenance windows and external dependencies can alter observations. A reliable report states what was measured, what was not measured, and how ambiguous intervals were treated.

These requirements are deliberately demanding because a benchmark can influence purchasing, operational and reputational decisions. When the source material is a public registry-and-routing snapshot, the honest result is a control-surface analysis, not a customer-performance ranking.

Evidence limits and prohibited extrapolations

For clarity, this manuscript does not make any of the following claims:

It does not claim that Inside The Internet, Inc serves a particular customer or market.
It does not claim a product portfolio, network architecture, topology, facility count, geography or upstream relationship.
It does not claim traffic volume, capacity, latency, loss, uptime or availability.
It does not claim a benchmark or relative ranking.
It does not claim an outage, breach, route hijack or customer incident.
It does not claim that the RPKI-unknown prefix is invalid, unsafe or impaired.
It does not claim why the two prefixes have different RPKI states.
It does not claim that the older IRR object is erroneous.
It does not claim employee, supervision, integration, maintenance or exception costs in money or hours.
It does not claim customer savings, growth, risk reduction or return on investment.
It does not claim or propose an image depicting the company, its equipment, staff, customers or facilities.

The absence of those claims is part of the research result. Public infrastructure sources are powerful when used for the questions they answer. Their value is weakened when registration, routing, reliability and outcomes are blended into a story the evidence cannot carry.

Conclusion

Inside The Internet, Inc has a compact but observable public network-resource footprint in the public records reviewed on 5 August 2026. ARIN identifies organization INSID-1 as the registrant of AS14473. Separate ASSIGNMENT records for 63.88.42.0/23 and 107.0.20.0/24 use distinct customer handles while repeating the company name. RIPEstat observes AS14473 as announced, lists both prefixes, reports IPv4 visibility from 327 of 327 RIS peers in the reviewed routing-status response, and shows collector paths ending at AS14473.

The evidence also preserves two differences that should not be smoothed away. An older 8.25.16.0/24 IRR object is not in BGP, and RPKI validation is valid for 107.0.20.0/24 but unknown for 63.88.42.0/23. Neither difference proves a customer problem. Both demonstrate why public network evidence must be reconciled at the object level.

The larger lesson is methodological. A registry supplies a ledger of identity and resource relationships. BGP collectors show a running routing state from defined observation points. RPKI supplies prefix-and-origin authorization evidence. Together, they can demonstrate a narrow capability and expose control differences. They cannot, without longitudinal and customer-side evidence, prove reliability or business outcome.

That gap is where supervision, integration, maintenance and exception work lives. Someone must keep identifiers accurate, compare intended and observed state, interpret security metadata, handle mismatches and verify closure. The public records reviewed on 5 August 2026 do not tell us how Inside The Internet, Inc organizes or prices that work. They do show why the work exists and why an honest assessment should ask for evidence at each layer rather than rewarding a broad claim.