Summary

  • RIPE RDAP records active AS215878 under the AS name m1cloudITC and links it to organisation ORG-MITC3-RIPE, whose public name matches M1CLOUD INFORMATION TECHNOLOGY CONSULTANTS L.L.C.
  • The same registry records the active UAE allocation 194.156.28.0-194.156.31.255. RIPEstat sees the complete 194.156.28.0/22 as one IPv4 origin containing 1,024 addresses.
  • At the captured snapshot the route was visible to 329 of 329 full-table IPv4 RIS peers. That is strong route-propagation evidence, not proof of application availability, hosting capacity, customer reachability or physical continuity.
  • RIPEstat observed one routing neighbour, AS42156. Registered policy also names AS200044, but that second relationship was not observed in BGP and cannot be presented as a live redundant path.
  • The exact 194.156.28.0/22 origin by AS215878 returned RPKI valid. The authorisation helps bind prefix and origin, but does not establish facility security, uptime, service quality or a resilient cloud platform.

One autonomous system creates a narrow public accountability surface

The strongest public fact about m1cloudITC is the agreement between its directory identity and a small set of number-resource records. RIPE's RDAP service identifies autonomous system 215878 by the AS name m1cloudITC. The same response includes organisation handle ORG-MITC3-RIPE, whose public organisation name is M1CLOUD INFORMATION TECHNOLOGY CONSULTANTS L.L.C. That is a precise bridge between the existing company identity and one Internet routing number.

The bridge matters because company names alone are poor infrastructure identifiers. Trading labels can overlap, change or be reused across jurisdictions. An ASN is unique within the global routing system. It gives other networks a stable reference for an origin, policy relationship and incident discussion. It also gives researchers a way to separate this company from unrelated services that contain similar words such as "cloud," "IT" or "consultants."

RIPE's separate IPv4 record adds a second piece of the boundary. It assigns the active range from 194.156.28.0 through 194.156.31.255 to netname AE-M1CLOUD-20180530 in the United Arab Emirates. The range is the exact /22 194.156.28.0/22, containing 1,024 IPv4 addresses. The registrant links again point to the same organisation structure used by the AS record.

This alignment is useful, but it remains administrative evidence. A registry can show which organisation is recorded against an ASN and address block. It cannot show which servers use the addresses, which legal entity signs each customer agreement, or whether any facility is owned, leased or supplied by a third party. It cannot show whether the public route serves hosted applications, corporate systems, network infrastructure, customer virtual machines or a mixture.

The public number-resource identity should therefore be treated as an accountability anchor. It identifies where questions can be directed and which route can be monitored. It does not convert a directory company's cloud-service classification into proof of a particular physical footprint. That distinction keeps the visible evidence useful without asking it to support claims it was never designed to answer.

Registry dates are not commissioning dates

The RIPE records are recent. The IPv4 allocation shows registration on 19 December 2025. The autonomous-system entity shows registration on 22 December 2025. Both records were last changed on their respective registration dates in the captured RDAP responses. These timestamps establish when public registry entities were created or modified, not when commercial service began.

Infrastructure reporting often collapses several different clocks into one. A company can incorporate before it receives number resources. An address allocation can be registered before routers announce it. Equipment can be installed before it is powered. A link can be energised before it carries production traffic. A route can be visible before customer systems are commissioned. A service can be commercially offered before its operating dependencies are fully disclosed.

RIPEstat supplies a separate routing clock. Its routing-status response says the 194.156.28.0/22 origin from AS215878 was first seen on 25 January 2026. That is more than a month after the address allocation and roughly a month after the ASN registration. The gap is consistent with an orderly transition from assignment to public routing, but the public data does not reveal what happened during it.

No conclusion about construction, installation or commissioning follows automatically. The company may have prepared routers, contracts, addressing plans and customer systems during the interval. It may have used existing facilities and transport. It may have conducted testing. Each scenario is plausible, and none is established by the dates alone.

The correct chronology is deliberately modest. The registry recorded the /22 and ASN in December 2025. RIPE RIS first saw the origin in January 2026. The route remained present in the captured July 2026 observation window. Physical deployment, first customer acceptance, commercial availability and operational handover require different evidence.

Keeping those clocks separate is more than semantic care. It prevents an allocation event from being described as delivered capacity and prevents route visibility from being described as a fully operating cloud platform. It also creates a cleaner baseline for later changes: registry updates, route changes and service announcements can be dated independently instead of being merged into one unsupported launch narrative.

One /22 is both the registered entity and the running route

The current public origin is simple. RIPEstat's announced-prefixes endpoint lists one prefix for AS215878: 194.156.28.0/22. The routing-consistency endpoint finds the same prefix in both BGP and RIPE WHOIS. Unlike cases where a registered aggregate is announced as multiple more-specific routes, the registry entity and the visible route have the same prefix length and address boundary.

That one-to-one alignment reduces one kind of ambiguity. An observer does not need to reconstruct how several announcements partition the allocation. The complete registered range appears as one origin, and the 1,024-address count reported by routing status matches the arithmetic of the /22. A withdrawal of the route would remove the entire currently visible IPv4 origin set for this ASN from the sampled control plane.

The simplicity does not imply operational simplicity. One BGP prefix can contain many internal networks, customer assignments, virtual systems or infrastructure functions. It can be delivered through several internal devices or through one. It can rely on diverse facilities or on a single room. The route table exposes none of those arrangements.

One prefix also does not mean one customer or one service. IPv4 addresses can identify router interfaces, virtual machines, shared gateways, monitoring systems, customer endpoints, hosted applications or unused inventory. Network address translation can support many users behind a small public set. Conversely, a large part of an allocation can remain reserved while only a few addresses carry traffic.

The alignment is best used as a monitoring boundary. Researchers can record whether the exact /22 remains originated by AS215878, whether visibility changes, and whether the route appears in both registry and BGP views. They can compare those fields over time without estimating private utilisation.

What they cannot do is translate 1,024 addresses into rack count, customer count, compute capacity or revenue. Prefix size and facility scale are different measurements. The route shows a public network identity in operation. It does not show how much cloud infrastructure, if any, sits behind that identity.

Full sampled visibility shows propagation, not service quality

At the captured query time, RIPEstat reports that 329 of 329 full-table IPv4 RIS peers saw the AS215878 origin. That is the maximum visibility available within that sampled set. It is strong evidence that the route was broadly propagated across the control plane observed by RIPE RIS.

The denominator defines the claim. RIS peers are routing observation points. They are not every access network, enterprise firewall, recursive resolver, customer device or application path. A route visible to all sampled full-table peers can still encounter packet loss, filtering, congestion, DNS failure, host failure or access-network problems beyond the BGP observation.

Visibility is nevertheless important. It distinguishes an ASN that merely exists in a registry from one with a current route carried through the sampled Internet. It provides a baseline for detecting a withdrawal, origin change or loss of propagation. If future observations fall sharply below 329 peers, investigators would have a measurable control-plane change to examine.

The result cannot serve as an uptime percentage. The endpoint reports a snapshot, not a continuous end-to-end service test. It does not measure latency, throughput, packet loss, application response, storage availability or customer success. It also cannot prove that every address in the /22 was reachable or in use.

The absence of an IPv6 origin supplies a complementary boundary. RIPEstat reports zero originated IPv6 prefixes and zero of 324 IPv6 RIS peers seeing a route from AS215878. The public origin surface in this snapshot is therefore IPv4-only. That does not establish that the company has no IPv6 capability. IPv6 may be used internally, supplied through another ASN, tested privately or not yet announced.

Together, the two observations define a precise external state: one widely visible IPv4 /22 and no visible IPv6 origin from AS215878. They do not justify broader conclusions about a company's cloud services. Propagation is a necessary property of a public route, but it is only one layer in the delivery chain.

One observed neighbour is a handoff boundary, not a resilience claim

RIPEstat's AS-neighbours response lists one observed left-side neighbour for AS215878: AS42156. Routing status independently reports one observed neighbour. The routing-consistency endpoint finds AS42156 in both BGP and registered import and export policy. These observations define the narrowest public view of the current routing handoff.

The label "neighbour" should not automatically become "upstream provider." BGP path adjacency shows a routing relationship but does not publish the commercial contract behind it. The relationship may be transit, peering, customer-provider service or another arrangement. The public endpoints establish adjacency and policy alignment, not price, capacity, service level or legal responsibility.

The number one also needs careful handling. One observed neighbour does not prove that the company has only one physical circuit, one router or one facility. Multiple physical links can support one AS relationship. Private or backup sessions may not appear in the collected path set. A route server or selective policy can also complicate a simple topology sketch.

The reverse is equally important. One AS neighbour cannot be presented as proof of physical redundancy. Even if several circuits exist, they may share a building, duct, power system, metro fibre segment or operational team. The public route table does not identify common failure domains or available failover capacity.

For continuity analysis, the observed handoff is the start of a question set. Where does it terminate? Which party supplies transport? Are there multiple ports, devices or sites? What happens when the relationship fails? Can another path carry the normal load, and has that condition been tested? The source set does not answer those questions.

Calling the observation a handoff boundary preserves its value. It shows where AS215878 meets another visible routing domain and which ASN appeared adjacent in the snapshot. It does not convert a logical edge into a documented physical architecture or a resilience score.

Registered AS200044 policy is not a second live path

The routing-consistency response introduces an important contrast. It lists AS200044 in registered import and export policy for AS215878, but marks the relationship absent from observed BGP. In the same response, AS42156 appears in both policy and BGP. The static and running surfaces therefore agree on one relationship and differ on the other.

This does not prove that the AS200044 relationship is false, broken or obsolete. Registered policy can describe a planned, backup, selective or currently inactive relationship. Collector visibility can miss private or conditional paths. The record may also be stale. The evidence supports only the distinction between registered policy and an observed path at the captured time.

That distinction is operationally useful. A future appearance of AS200044 in observed BGP would be a measurable change. A future removal from registered policy would be a registry change. Either event could prompt questions, but neither alone would prove a new circuit, a migration, additional capacity or improved resilience.

It would be inaccurate to count AS42156 and AS200044 as two current upstreams. Only AS42156 appears in the observed neighbour set. It would also be inaccurate to assert that no alternate relationship exists, because collector data is not a complete view of private configurations or failure-only paths.

The difference illustrates why running-code primacy should be paired with a recordkeeping layer. Registry and policy entities describe intended or documented responsibility. BGP observations show what the sampled routing system carried. When they differ, the difference should be recorded rather than resolved through speculation.

For a customer evaluating continuity, the policy entry can become a due-diligence question: Is AS200044 a backup, a future provider, a private relationship or a stale entity? If active, where does it terminate and what capacity is available? If inactive, why is it still registered? The public record creates the question but does not supply the commercial answer.

Exact-prefix RPKI validation adds one security-metadata layer

The bounded RIPEstat RPKI query for 194.156.28.0/22 originated by AS215878 returns valid. Its validating list contains an exact /22 Route Origin Authorisation with origin 215878 and maximum length 22. The route's prefix, origin and authorisation therefore align in the captured validator response.

This is a meaningful control. RPKI origin validation helps relying networks determine whether the ASN announcing a prefix is authorised by the resource holder's cryptographic record. An exact-prefix result avoids the ambiguity that can arise when a covering authorisation permits a range of more-specific announcements.

The scope remains narrow. RPKI validates route origin, not the full AS path. It does not prove that traffic reaches the intended application, that routers are securely configured, or that the company's systems are protected from compromise. It does not guarantee availability, latency, capacity or correct customer routing.

A valid ROA can coexist with an outage. The authorised origin can withdraw the route, experience congestion, lose power, misconfigure forwarding or depend on a failed facility. The public validation state says that the origin is authorised for the prefix. It is not a certificate for the physical or service chain.

The result is still valuable for monitoring. An invalid or unknown state in a later snapshot would be a distinct change even if the BGP route remained visible. A prefix change or origin change would also require the authorisation to be reconsidered. Recording those fields separately makes the baseline more useful.

The broader lesson is that security metadata should be neither ignored nor exaggerated. For AS215878, the exact /22 has a positive origin-authorisation signal. That strengthens the public accountability surface. It does not prove that a cloud customer has resilient compute, protected data or a recoverable workload.

A cloud-service label does not reveal a data-centre footprint

The directory classifies the company under cloud service. That is a useful navigation category, but it cannot substitute for evidence about facilities and operating dependencies. The public source set used here contains number-resource and routing records. It contains no verified list of data centres, racks, server clusters, storage systems, power feeds or customer environments.

The distinction matters because the same public network identity can support many delivery models. A company can own facilities, lease racks, buy managed infrastructure, resell another provider's services, operate virtual capacity or combine those approaches. AS215878 and its /22 do not identify which model applies.

The records also do not show location. The registry country is the United Arab Emirates, and the organisation address is in Dubai. Those fields identify registration and contact context. They do not prove where equipment is installed, where customer data resides, or where traffic is processed.

No capacity figure can be derived from the address block. A /22 contains 1,024 addresses, but address count does not measure CPU, memory, storage, rack power, floor space, bandwidth or available customer inventory. Virtualisation, shared gateways and private addressing further weaken any attempted conversion.

Operational responsibility remains equally opaque. The source set does not name the party responsible for facility maintenance, hardware replacement, storage recovery, customer support, network transport or incident escalation. It does not establish whether one vendor controls the full service or whether several suppliers form the delivery chain.

The correct public description is therefore a network identity associated with a cloud-service company, not a documented cloud footprint. That framing follows the visible dependency without inventing the hidden layers. It also makes future evidence easier to integrate: a verified facility, provider agreement or operational disclosure can be added without rewriting the meaning of the ASN record.

The physical dependency chain remains mostly private

A hosted workload depends on more than a route. It needs functioning compute, storage, power, cooling, physical security, network transport, DNS and operational staff. If the service is virtualised or resold, it may also depend on an upstream platform, licensing system, management plane and contractual access to customer data.

None of those layers appears in the RIPE source set. The ASN and prefix describe external routing responsibility. The neighbour view describes a visible logical handoff. The registry gives public contacts and organisation handles. The RPKI response describes origin authorisation. These are valuable, but they are only parts of a larger delivery chain.

Ownership is one missing field. A company can control an ASN while relying entirely on leased infrastructure. Leasing is not inherently weak; many reliable services use specialised facilities and carriers. The continuity question is whether responsibilities, access rights, escalation paths and recovery commitments are explicit and tested.

Power is another missing field. A route can remain visible while a customer workload loses power, and a facility can remain powered while an external route fails. Backup generation, fuel contracts, maintenance procedures and power-distribution design require direct operational evidence. None can be inferred from BGP visibility.

Recovery is similarly separate. Restoring a route, replacing a server, recovering storage and communicating with customers are different tasks. They may have different owners and time objectives. A valid ROA does not shorten a storage rebuild, and a second registered policy peer does not restore a failed application.

Following the physical dependency means preserving these unknowns. The public network layer is the part that can be independently measured now. It defines where routing responsibility sits and where external connectivity appears to leave the ASN. The rest of the chain needs evidence from contracts, facilities, operating procedures and tested recovery outcomes.

One route can still expose several different failure modes

The current baseline is compact enough to express as a failure ledger. The /22 can disappear from BGP. Its origin can change. Its visibility can fall. The observed AS42156 relationship can disappear. The registered AS200044 policy can change. RPKI status can become unknown or invalid. Each event affects a different public field.

A route withdrawal would be the most obvious control-plane event. It would remove the only currently visible IPv4 prefix from AS215878. The customer impact would depend on what uses the addresses and whether traffic moves through another origin, neither of which is established here.

An origin change would create a different question. It could be authorised and planned, such as a migration, or it could be accidental or hostile. RPKI would provide one signal, but the complete explanation would require operator confirmation and path analysis.

A neighbour change could reflect transit maintenance, policy adjustment, failover or collector variation. It should be recorded before a cause is assigned. The appearance of AS200044 in BGP would be particularly notable because it is already present in registered policy.

An application outage might produce no BGP change at all. Compute, storage, DNS, authentication or customer configuration can fail while the route remains visible to every RIS peer. That is why route visibility cannot serve as a complete health check.

The failure ledger is useful because it prevents one layer from masking another. A company can maintain a valid, visible route while a hosted service fails. It can also run functioning systems while a route problem blocks external access. Good continuity analysis asks which layer changed, who controls it and how recovery is verified.

The 1,024-address figure is a monitoring count, not a business metric

Routing status reports one IPv4 prefix containing 1,024 addresses. The number matches the registered /22 and is arithmetically exact. Its most defensible use is to define the complete visible IPv4 origin set at the captured time.

The count does not reveal utilisation. Some addresses may be assigned to customer systems, some to infrastructure, some to shared services and some to inventory. Private addressing and network address translation can support many more endpoints than the public count. Virtual hosting can place many applications behind one address.

It also cannot reveal customer scale. One enterprise might use many addresses, while many customers might share a small number. A hosted service may expose only gateways publicly and keep most systems on private networks. Without allocation and service records, converting addresses into customer estimates would be guesswork.

Capacity is even less connected. Bandwidth depends on circuits, ports, equipment, traffic engineering and commercial commits. Compute depends on processors, memory, storage and oversubscription. Facility capacity depends on power, cooling and space. None of those quantities follows from prefix size.

The count remains useful when it changes. A new prefix could expand the public origin set. A more-specific announcement could alter routing policy without adding addresses. A partial withdrawal could reduce visibility for part of the allocation. Each change would be measurable before its customer effect is known.

This separation between measurement and interpretation is essential. The /22 gives the company a bounded public number-resource surface. It is not a proxy for the size, value or resilience of the business behind it.

IPv4-only visibility creates a precise unanswered question

RIPEstat reports no IPv6 origin from AS215878 in the captured snapshot. The routing-status response counts zero IPv6 prefixes and zero IPv6 /48 equivalents. Its visibility field reports zero of 324 IPv6 RIS peers seeing an announcement.

The observation does not establish that the company has no IPv6 capability. IPv6 may be delivered through another ASN, used internally, tested privately or planned. Customer systems may obtain IPv6 from a platform or upstream provider that is not visible under AS215878.

The absence matters because a public IPv6 origin is an independently observable deployment milestone. It requires address resources, routing policy and external acceptance to reach the global control plane. Without such an origin, outside observers cannot verify those layers for this ASN.

For a cloud-service customer, the practical questions are direct. Is IPv6 supported? If so, which ASN originates it, which addresses are assigned, and which party owns troubleshooting? Does the service provide dual-stack access, private IPv6 only or no IPv6? How are security controls and logs maintained across both protocols?

No answer should be invented from the IPv4 route. The accurate statement is simply that AS215878 had one visible IPv4 /22 and no visible IPv6 origin at the snapshot. That bounded finding creates a due-diligence question without turning absence of evidence into a capability verdict.

Future monitoring can close part of the gap. A new IPv6 announcement would be a measurable event. Registry records could then be checked against the origin, visibility and RPKI state. Until that occurs, IPv6 remains outside the verified public origin surface.

Continuity depends on contracts and control, not just routes

The visible handoff raises contractual questions that BGP cannot answer. If AS42156 supplies transit, what service level, capacity and escalation commitments apply? If the relationship has another commercial form, who is responsible for restoration? Where does the responsibility boundary sit between the companies?

The registered AS200044 policy raises a second set. Is it a backup relationship, a planned connection or a stale record? If it is intended for failover, is it physically separate and tested under realistic load? Does it depend on the same facility, transport provider or power domain as the observed path?

Cloud-service continuity adds layers beyond transit. Customers need to know who controls compute and storage, how backups are isolated, how credentials are recovered, and how data can be exported during a provider failure. They also need to know which dependencies are subcontracted and what rights survive a commercial dispute.

The public records do not answer these questions, but they help organise them. The exact ASN and prefix identify the current external route. The observed neighbour identifies one visible boundary. The valid ROA identifies origin authorisation. Each field points to a specific responsibility rather than a generic request for "more resilience."

Evidence can be provided without exposing sensitive topology. An operator can describe the number of independent sites, common failure domains, tested failover process, backup ownership and recovery objectives. It can distinguish owned assets from leased services and state which obligations belong to third parties.

Until that evidence exists, the responsible conclusion remains limited. The company has a clear and active public network identity. The continuity of the cloud service associated with that identity is not established by the route alone.

A practical monitoring baseline should keep the layers separate

AS215878 is well suited to a compact public baseline. The record can include the exact entity slug, ASN, organisation handle, registered /22, observed prefix, RIS visibility, observed neighbour, registered policy peers, IPv6 origin count and RPKI status. Each field has a clear source and can change independently.

Registry updates should be recorded separately from routing changes. A contact or maintainer change affects accountability metadata. A prefix or origin change affects the running control plane. An RPKI change affects authorisation metadata. Combining them into one undated status would obscure what actually changed.

The baseline should also preserve observation times. The route was visible across the announced-prefix interval and present at the routing snapshot, but that is not a continuous availability measurement. Future comparisons should use like-for-like endpoints and note collector differences.

Alerts should be field-specific. A route withdrawal, origin change, sharp visibility drop, new neighbour, lost neighbour, IPv6 appearance or RPKI change deserves a different response. The same event may be benign or serious depending on operator confirmation and customer impact.

The monitoring record must not become advocacy copy. A stable route does not endorse the provider, and a changed route does not automatically condemn it. The purpose is to create a reality layer: a dated, evidence-led description of the public network boundary and the exact points where private evidence is still required.

That discipline benefits both operators and customers. Operators can correct stale public records and explain planned changes. Customers can ask narrower questions and avoid relying on broad claims. Researchers can distinguish what the routing system shows from what a company says about its service.

Due diligence should follow the dependency from ASN to workload

A prospective customer can begin with identity. Does the contracting company match the organisation controlling AS215878 and 194.156.28.0/22? If another group company operates the service, which entity holds operational and data-protection responsibility?

The next step is connectivity. What does AS42156 provide, where does the handoff terminate, and what alternate path exists? What is the role of AS200044 in registered policy? Are circuits, facilities and power domains independent, and can failover carry normal demand?

Facility and platform questions follow. Where are workloads hosted? Which racks, servers, storage systems and network devices are owned or leased? What power and cooling dependencies apply? Who can physically access equipment during an incident?

Recovery questions are equally concrete. How are backups isolated and tested? What are the recovery time and recovery point objectives? Can customers export data and configurations if the service is unavailable or the commercial relationship ends? Which support channels operate outside normal hours?

The public route cannot answer these questions, but it prevents them from becoming abstract. The route identifies the current external network boundary. A change there can be monitored independently from a platform failure. A stable route during an application outage would direct attention further inside the service chain.

Good diligence therefore follows the dependency rather than stopping at the ASN. It starts with the public number-resource identity because that is measurable. It then moves through transport, facility, platform, operations and customer recovery, requiring evidence at each layer.

Change records should preserve cause, scope and operator confirmation

A useful change record should begin with the smallest observable event. If 194.156.28.0/22 disappears from RIPE RIS, the first fact is a route withdrawal at a recorded time, not a service outage. The withdrawal could reflect maintenance, collector visibility, a policy change, a provider transition or a fault. Customer impact requires separate evidence from the service surface. Keeping those statements separate prevents a control-plane event from being inflated into an unsupported operational conclusion.

An origin change needs the same discipline. A future observation of the /22 behind another ASN would be significant because the public control relationship changed. It would not, by itself, establish a transfer of ownership or a change in the contracting company. The registry record, routing observation and operator explanation would need to be compared. RPKI status would also need to be checked against the exact new origin rather than carried forward from the present AS215878 result.

Neighbour changes should be described as visible handoff changes. If AS42156 disappears and another neighbour appears, the evidence would show a different observed path into the public routing system. It would not show whether the commercial transit agreement changed, whether the physical circuit moved, or whether both paths existed during a transition. Those questions require operator confirmation and, where continuity matters, evidence about physical and contractual independence.

The registered AS200044 relationship provides a useful comparison point. If it becomes observed later, the event can be measured against the current snapshot: one previously unobserved registered relationship has become visible. That still would not prove tested failover or additional usable capacity. A responsible record would ask whether the path is intentional, whether traffic can move in both directions as expected, and whether the alternate path avoids common facilities, power domains and upstream dependencies.

Visibility changes also need context. The current 329-of-329 sample is a broad observation across participating collectors, but a lower number can have several causes. Collector churn, path filtering, maintenance and route instability can all affect the result. A monitoring note should preserve both numerator and denominator, the endpoint used and the observation time. It should avoid treating a single sample as a percentage guarantee for customer reachability.

RPKI changes are narrower still. A transition from valid to invalid would identify an authorisation mismatch between the observed origin and the published ROA data. It would be an important security and routing-policy signal, but not proof of malicious activity. A transition to not-found would mean that the exact authorisation record was no longer available to validators. In either case, the appropriate response is to verify the origin, contact the responsible operator and preserve the dated registry and routing evidence.

Registry changes should be logged without confusing administration with operation. A new contact, maintainer or status can improve or weaken the accountability trail, yet the route may continue unchanged. Conversely, the route can change while the registry remains static. The strongest public record keeps both layers and records when they disagree. That makes stale metadata visible without pretending that a registry field commands the running network.

Operator confirmation completes the record when it is specific enough to test. A statement that a route change was planned is more useful when it names the affected prefix, time window and restored state. A continuity claim is more useful when it identifies the independent path or failure domain without exposing sensitive topology. The aim is not to demand unrestricted disclosure. It is to connect a public event to an accountable explanation and a verifiable recovery state.

This approach gives customers and researchers a stable method for future comparisons. Each update can state what changed, which source observed it, what the evidence does not establish, and what confirmation remains outstanding. That structure preserves uncertainty while still making the operator boundary more visible. It also prevents a sequence of unrelated observations from being compressed into a single narrative of success or failure.

The public record is strong because its limits are visible

AS215878 provides a clean example of what public network evidence can and cannot establish. RIPE binds the ASN and /22 to the same named organisation. RIPE RIS sees the route through one observed neighbour with complete sampled IPv4 visibility. Registered policy adds a second, currently unobserved relationship. RPKI validates the exact origin.

Those facts create a useful accountability surface. The entity is not merely a brand name in a company listing. It controls a specific number-resource identity with a current route and public security metadata. Changes can be detected and discussed using exact identifiers.

The same evidence leaves the cloud-delivery boundary open. No source here establishes a data centre, rack, server, capacity figure, customer count, support model or recovery process. The registry does not prove sovereign control over every dependency. BGP does not show physical topology. RPKI does not certify service quality.

This is not a weakness in the evidence. It is the reason the evidence can be trusted. Each source is used for the surface it actually records. Registry fields identify responsibility. Running routes show control-plane behaviour. Policy data records intended relationships. RPKI records origin authorisation. The cloud-delivery boundary requires different evidence.

The result is a reality layer rather than an endorsement. m1cloudITC has one visible IPv4 route and a valid origin record. The infrastructure and obligations behind the service remain to be demonstrated through direct operational evidence. That boundary is the most important finding.

Sources