Summary

  • CPP JSC Center of Prospective Projects is publicly tied to AS211730 through RIPE NCC records, a Novosibirsk company site, and the persproject.ru domain, but those records should be read as a control-surface map, not as proof of commercial data-platform performance.
  • Current public routing evidence shows AS211730 originating 194.85.111.0/24, with RIPEstat recording one IPv4 prefix and no IPv6 originated space on July 13, 2026; that differs from older directory context that described the ASN as having no observed prefixes.
  • The official site presents CPP as a data-center services company that rents and maintains computing and communications equipment and says its facilities host more than 500 units of server equipment, but it does not publish architecture, customer references, audited uptime, pricing, certifications, or live service metrics.
  • The main technical risk is not that a small ASN is inherently material. It is that thin public evidence can tempt readers to overstate identity, security, market, and operational conclusions that should remain separate until routing, corporate, and service evidence converge.

A small ASN is still an operating surface

CPP JSC Center of Prospective Projects is not a household technology vendor, and the public record around it is not deep enough to support broad claims about a cloud business. The reason to cover it is narrower and more technical. An autonomous system number is a public routing identity. If it is dormant, it is still a reserved capability. If it starts originating prefixes, it becomes part of the internet's inter-domain routing surface, even if the address space is small and the holder is obscure. AS211730 is now visible enough to deserve that distinction.

The BTW directory entry framed CPP JSC Center of Prospective Projects as an entity registered in the RIPE NCC database as the holder of AS211730, with limited independent evidence and an earlier observation that no prefixes were being originated. A current check changes one important part of that picture. RIPEstat's AS overview identifies the holder as CPP JSC Center of Prospective Projects and marks the ASN as announced. RIPEstat's announced-prefixes data shows 194.85.111.0/24 visible over the 14-day window ending July 13, 2026. Its routing-status data records one IPv4 prefix, 256 IPv4 addresses, no IPv6 originated space, and broad visibility among RIPE RIS peers at the July 13 query time.

That does not turn CPP into a major network operator. It does, however, move the file from a purely latent registry item to a small live routing footprint. The technical question then becomes less dramatic and more useful: what exactly can be said about the identity behind the route, the network-control relationships around it, and the service claims adjacent to it?

For data teams, platform engineers, security analysts, and procurement teams, that question matters because many operational decisions start with thin external signals. A vendor may appear in DNS records, registry data, hosting traces, support documents, procurement filings, or address-space records long before it publishes a mature developer portal or a detailed trust center. If analysts collapse those weak signals into a confident vendor profile, they create false precision. If they ignore them, they may miss an emerging control surface. CPP is a useful case because its public evidence sits between those extremes.

The core article boundary is therefore strict. Public records show a legal and network identity, a current IPv4 announcement, a company website describing data-center services, and several third-party routing indexes that agree on the small footprint. Public records do not show first-hand performance tests, paying customers, service-level agreements, data-processing architecture, incident history, certification scope, private contracts, or the internal workloads hosted in CPP facilities. The right conclusion is not that CPP is unimportant. The right conclusion is that the reliable facts are specific, small, and operationally bounded.

Identity starts with RIPE, then narrows through the company site

RIPE's aut-num record lists AS211730 with the AS name CPP, organisation ORG-CCOP1-RIPE, sponsoring organisation ORG-RRIf1-RIPE, several import and export policy lines, administrative and technical contact CNT15-RIPE, and status ASSIGNED. The record was created on February 26, 2021 and last modified on October 21, 2024. The same record names RIPE-NCC-END-MNT, ROSNIIROS-MNT, and CPP-MNT as maintainers. Those fields establish the routing-registration boundary. They do not, by themselves, establish what services run behind the ASN.

The related RIPE organisation record is more useful for identity. It gives the organisation name as JSC Center of Prospective Projects, country RU, registration number 1055473110384, address at 42 Demakova Street in Novosibirsk, and email [email protected]. It classifies the organisation type as OTHER and shows creation on February 25, 2021, with last modification on May 13, 2026. RIPE's RDAP entity view repeats the same organisation handle, name, address, and contact domain. The role record names CPP Network Team at the same Demakova Street address, with the same RIPE contact email.

The first-party site at persproject.ru closes part of the identity loop. It presents the company as AO CPP, Center of Prospective Projects, and says the company works in data-center services. Its requisites page gives the full legal name as a joint-stock company, lists the same OGRN registration number 1055473110384, gives INN 5408236629 and KPP 540801001, and uses the Demakova Street address in Novosibirsk. The overlap between RIPE organisation data and the company site supports the conclusion that the RIPE holder and the public-facing company site refer to the same Russian legal entity.

That identity conclusion is narrower than a product conclusion. The site shows a company. RIPE shows routing resources. The combination supports a verified entity-resolution finding: CPP JSC Center of Prospective Projects is not merely an unexplained string in a routing database. It has a matching first-party domain, company contact surface, legal identifiers, and network contact surface. But the same evidence does not identify a public cloud service catalog, an external developer platform, or a fully documented managed-data product.

This distinction matters because route records are often copied into vendor databases, threat-intelligence systems, procurement spreadsheets, and asset inventories with too little context. A line reading "AS211730 - CPP - RU" is not enough to decide whether a supplier operates infrastructure, resells capacity, hosts internal workloads, or simply holds a delegated resource. In CPP's case, the current evidence is better than a bare route object, but it still requires careful labeling. "Russian data-center company with a small routed IPv4 footprint" is defensible.

"Cloud provider with proven data-platform performance" is not.

What changed from a latent record to a routed footprint

The initial risk around CPP was registry-only evidence. That risk still matters, but the current state is not fully registry-only. RIPEstat's announced-prefixes endpoint shows 194.85.111.0/24 for AS211730, with a timeline from June 29, 2026 to July 13, 2026 in the checked window. RIPEstat's prefix overview for 194.85.111.0/24 marks the prefix as announced and names ASN 211730 with holder CPP JSC Center of Prospective Projects. The RIPE database search for 194.85.111.0/24 returns an inetnum entity for 194.85.111.0 to 194.85.111.255, netname CPP, country RU, organisation ORG-CCOP1-RIPE, and a route object for 194.85.111.0/24 with origin AS211730.

Independent routing pages point in the same direction. BGP.tools displays AS211730 as registered to ORG-CCOP1-RIPE under RIPE, active, with one IPv4 prefix and no IPv6 prefix, and lists 194.85.111.0/24. IPIP's AS page identifies AS211730 as CPP - JSC Center of Prospective Projects in Russia, with one IPv4 prefix and 256 IPv4 addresses. Hurricane Electric's BGP page was part of the current check as another external route-index surface, though routing-index pages vary in how much detail they expose and how frequently they refresh.

The route is small: one /24, the minimum generally routable IPv4 prefix in much of the global table. A single /24 can host important services, but size alone should not imply either significance or insignificance. It could support a narrow service environment, a management surface, a data-center customer segment, an internal corporate estate, or a transitional routing arrangement. The public record does not identify which of those uses applies. The only defensible statement is that AS211730 currently has a small IPv4 route that was visible in public routing data during the checked window.

The RIPE aut-num policy fields are also meaningful but easy to over-read. The record includes import and export lines involving AS12389, AS25549, AS2854, and AS20485. RIPEstat's routing-consistency endpoint showed AS25549, AS2854, and AS20485 as present in both public BGP and whois policy, while AS12389 appeared in whois but not in BGP at the checked time. That is a routing-state observation, not a contract disclosure. It indicates how public records and observed paths aligned at that moment. It does not prove commercial transit terms, physical handoff locations, traffic volumes, or service dependencies.

The change from no observed prefixes to one visible prefix is exactly why registry leads need dated evidence. A directory note can be true at a snapshot and stale weeks later. Analysts should carry the timestamp with the conclusion. On July 13, 2026, the reliable current evidence says AS211730 is announced, with 194.85.111.0/24 visible and no IPv6 originated space in the checked RIPEstat data. A future check could show withdrawal, additional prefixes, different upstream visibility, or a larger public footprint. The monitoring entity is therefore not a static company profile.

It is the relationship between a legal identity, route registration, observed BGP state, and first-party service claims.

The company claims data-center services, not a public hyperscale platform

The official site is the strongest source for CPP's own service positioning. Its homepage says the company works in the market for data-center services and describes three main activity areas: technical services, maintenance and leasing of computing and communications equipment, and placement of that equipment in its own data centers, including engineering support and fiber-optic lines. The same page describes the company's data centers as high-technology centers for storage and processing of data with protected network infrastructure, reliability, fault tolerance, channel capacity, and information-protection claims.

It also says CPP's data-center premises contain more than 500 units of server equipment, ranging from small one-unit servers to high-end servers supporting databases for processing, billing, and banking systems.

That first-party text is operationally relevant. It connects the routing identity to a plausible infrastructure business. It also points to the kind of work CPP might perform for customers or internal affiliates: equipment hosting, communications equipment rental, technical maintenance, and support for compute-heavy systems. Those are not the same thing as a public cloud platform.

The site does not publish virtual-machine types, entity-storage classes, managed database products, Kubernetes services, API documentation, developer onboarding, self-service dashboards, customer case studies, status pages, security attestations, or a public tariff schedule. The article should therefore not translate "data-center services" into "cloud provider" without qualification.

The software page adds another small clue. It lists two corporate information systems with exclusive rights held by CPP: CPP-Kandidat and CPP-KORP. The page shows no entry in the Russian software registry for those products in the captured text. That is enough to say CPP publicly identifies some proprietary internal or corporate software assets. It is not enough to say those systems are sold commercially, deployed at scale, integrated with the routed network, or relevant to external data teams. Their presence mainly reinforces that CPP is not only a passive registry holder; it presents itself as an operating organisation with internal software and data-center activity.

The requisites page is a stronger identity source than a product source. It lists legal identifiers, address, email, activity code 77.33.2 for rental and leasing of computing machines and equipment, and IT activity code references under a Russian digital ministry order. Those fields support the view that CPP's legal and commercial posture is infrastructure-related. They still do not establish quality of service. Public company data can say what a firm is organized to do; it rarely says how well the firm does it, which customers rely on it, or how resilient its systems are under repeated load.

For technology buyers, the distinction is practical. A data-center operator can be essential without having a developer-facing product. It may host databases, billing systems, payment-processing environments, telemetry stores, or enterprise applications that customers never see directly. Its failure modes are physical, network, administrative, and procedural as much as they are software-centric. The public evidence around CPP points more toward that facility-and-equipment world than toward a SaaS-style data platform.

If a customer or partner were evaluating CPP, the diligence questions would center on data-center controls, access management, network redundancy, backup and recovery processes, equipment custody, incident response, and route-security governance.

The data-infrastructure lens: freshness, governance, queryability, recovery

The commercial question in this batch is whether storage, compute, migration, lock-in, and data-quality labor beat the current stack. For CPP, the public answer is necessarily incomplete because the company does not publish a measurable public product. But the lens is still useful. Any data-center or hosted-compute operator sits beneath repeated operational decisions. If databases, billing systems, processing workloads, or banking support systems sit in a facility, users care about freshness, query latency, failure recovery, and controlled access even if the operator does not sell a branded analytics service.

Freshness in this context has two meanings. First, route and registry data must be fresh enough for external monitors to know what AS211730 is originating and who is responsible. RIPE's current data is fairly fresh: the organisation entity changed in May 2026, RIPEstat's routing checks are time-stamped on July 13, 2026, and the official site carries 2026 footer text and a recently modified privacy-policy PDF endpoint. Second, any customer workload hosted by CPP would need its own data freshness guarantees. The public site does not publish those guarantees.

It says the facilities support high-performance storage and processing of data, but it does not provide replication lag, recovery-point objectives, backup cadence, or customer-facing monitoring data.

Governance is similar. The public routing records identify administrative and technical contacts, an abuse contact in RDAP, maintainers, and a route object. Those are useful external accountability markers. They do not tell us who can change route policy, who approves access to racks, how customer data is segmented, how privileges are reviewed, or how incident authority is assigned inside CPP. For a buyer, those internal controls would be decisive. For a public analyst, they remain open questions.

Queryable evidence is better at the network layer than at the product layer. Anyone can query RIPE DB, RDAP, RIPEstat, and independent BGP pages to confirm the ASN, organisation handle, route object, and visible prefix. That makes AS211730 monitorable. The service side is less queryable. The company site describes data-center activity, but it does not provide API endpoints, service metadata, uptime history, technical documentation, or public machine-readable operational data. A monitoring program can track the routing surface, but it cannot infer hosted workload quality from that alone.

Recovery is the largest public-evidence gap. Data-center marketing language often emphasizes reliability and fault tolerance; CPP's site does so as well. But a public claim about reliability is not a recovery test. There is no public evidence here of disaster-recovery exercises, failover design, backup restore results, customer incident reports, or post-incident reviews. If CPP hosts databases for processing, billing, or banking systems as its site suggests, recovery is the central diligence issue. The public record does not let readers measure it.

This is where the article should resist a common shortcut. Because AS211730 is live and the company site mentions data centers, one might be tempted to treat the ASN as evidence of the data-center service's reliability. That would be wrong. Routing visibility proves reachability of an announced prefix through observed paths. It does not prove application uptime, storage durability, backup integrity, data quality, workload isolation, or support response. The ASN is a signal to monitor, not a substitute for private technical diligence.

Route security is relevant, but the public record is incomplete

Route security is part of the CPP story because a small routed prefix can still be misoriginated, hijacked, leaked, or misconfigured. The public evidence shows a RIPE route object for 194.85.111.0/24 with origin AS211730, and RIPEstat confirms that the prefix is in BGP and in whois. That alignment is better than a route that appears in BGP with no matching registry evidence. It gives monitors a basis for asking whether the origin is expected.

RPKI evidence is less complete in the current public checks. Hurricane Electric's AS page was inspected as an external view, and a RIPEstat rpki-by-as query returned an error rather than a usable list of route-origin authorizations. That means this article should not assert a complete RPKI state for CPP. The safer statement is that RPKI should be part of any follow-up check, and that the public evidence used here was not sufficient to prove a positive route-origin authorization posture for AS211730.

The reason this matters is not theoretical. A /24 can carry management access, customer systems, DNS, mail, monitoring endpoints, or payment and billing infrastructure. If a route is propagated globally with little filtering, a mistaken or malicious origin can redirect traffic or blackhole services. RPKI does not solve every routing-security problem, but it gives networks a cryptographic way to validate whether a given AS is authorized to originate a prefix. For a company presenting itself as a data-center operator, route-origin hygiene is part of operational credibility.

The RIPEstat routing-consistency result also invites a more specific monitoring pattern. Public whois policy lists several potential import and export relationships. At the checked time, RIPEstat saw three of them in public BGP and one only in whois. That is not inherently suspicious. Routing policies can be stale, backup links can be inactive, and public collectors can miss some state. But drift between declared and observed relationships should be watched because it can reveal stale documentation, temporary failover, provider changes, or cleanup gaps.

For readers outside network engineering, the practical translation is simple. CPP's public routing surface is small enough that a clean evidence table should be easy to maintain: AS211730; organisation ORG-CCOP1-RIPE; prefix 194.85.111.0/24; country RU; route object present in RIPE; current BGP visibility present; IPv6 originated space absent in RIPEstat; RPKI state unresolved in the frozen public check; PeeringDB record not found. If any one of those fields changes, the operational interpretation may change.

The PeeringDB API returned an entity-not-found response for ASN 211730. That is another bounded signal. It does not mean CPP has no peering or transit. PeeringDB is voluntary and incomplete. It does mean that a common network-operator directory did not provide a richer self-maintained public profile for this ASN at the time checked. In a thin-evidence case, absence from PeeringDB should lower confidence in public network-detail claims, not become a claim about the private network itself.

The most important uncertainty is service outcome, not legal identity

CPP's legal and routing identity is now reasonably well tied together. The harder uncertainty is service outcome. The public record supports a statement that CPP is a Russian joint-stock company in Novosibirsk, connected to the persproject.ru domain, with a data-center services website, RIPE organisation records, and AS211730 currently originating one IPv4 /24. It does not support statements about external customer satisfaction, workload mix, revenue, market share, cloud competitiveness, internal architecture, or operational maturity.

The company's own homepage says its premises host more than 500 units of server equipment and references database, processing, billing, and banking-system workloads. Those are important claims because they place the company in the operational-data economy, not merely the real-estate economy. But they remain first-party marketing claims unless corroborated by customer documentation, procurement records, certifications, audited reports, or independent technical tests. A reader should understand them as declared scope, not as verified performance.

The same caution applies to the domain and website. persproject.ru being reachable over HTTPS shows a public web presence. The response headers observed during the check indicated a Tilda-hosted site protected by ddos-guard, with a SharePoint-hosted privacy-policy PDF endpoint under doc.persproject.ru. Those hosting details are not proof of CPP's customer infrastructure. They are simply part of the public-facing web stack. A company can host its marketing site on a builder platform while operating separate data-center facilities; it can also use marketing language that exceeds public technical documentation.

The public site should be read as one source, not as a complete system map.

There is also a language and jurisdiction issue. The official site is Russian-language, the company is registered in Russia, and the RIPE records are in the RIPE NCC region. International readers may see an English transliteration, a route object, and a sparse routing page and assume the identity is weaker than it is. In this case, the local-language company site and legal identifiers materially strengthen entity resolution. But jurisdictional clarity does not remove sanctions, procurement, compliance, or operational-risk questions that a buyer would need to answer separately.

The safest editorial posture is therefore calibrated confidence. High confidence: AS211730 is assigned to CPP, the related RIPE organisation is JSC Center of Prospective Projects, the same registration number and address appear on the company's website, and 194.85.111.0/24 was visible in current public routing data. Medium confidence: CPP operates or presents itself as operating data-center services in Novosibirsk and has some proprietary corporate systems.

Low confidence: any claim about customer count beyond the site's equipment statement, workload quality, public cloud capability, resilience, price competitiveness, or data-governance maturity.

That structure is useful beyond CPP. Many infrastructure companies appear first as resource holders, not as polished software vendors. The analyst's job is to separate name resolution, resource control, service claims, and service outcomes. CPP has enough evidence for the first three categories to be discussed. It does not have enough public evidence for the fourth category to be scored as if a hands-on product evaluation had happened.

What a buyer or monitor should ask next

If a platform team encountered CPP as a supplier, host, counterparty, or network dependency, the diligence path should start with the narrow facts. Confirm the legal entity and registration number against official corporate sources, not only RIPE and the company website. Confirm the current address, beneficial ownership, sanctions exposure, licenses, certifications, and authority to provide the relevant service. Confirm whether the service under evaluation is colocation, equipment leasing, managed hosting, network transport, private cloud, software operation, or some combination. Each product boundary carries different risk.

At the network layer, ask for the current routing design: which prefixes are originated, which upstreams are active, which are standby, whether route-origin authorizations exist, who controls RIPE maintainer credentials, how changes are approved, how route leaks are detected, and how quickly the organisation can withdraw or correct a bad announcement. The public record shows one route and several policy relationships; it does not show the internal change-control process.

At the data-center layer, ask for facility tier claims, power redundancy, cooling design, fire suppression, physical-access controls, visitor logging, rack custody, remote-hands procedures, carrier diversity, fiber entry points, backup power tests, and incident history. The official site mentions engineering support, protected network infrastructure, reliability, fault tolerance, and channel capacity. Those claims should be mapped to evidence. Marketing text is a starting point for diligence, not a replacement for it.

At the data layer, ask what data classes are stored or processed, where backup copies live, how access is logged, how customer data is segregated, what happens during partial failures, and how recovery is verified. If the company supports billing or banking-system databases as the site suggests, then recovery-point and recovery-time objectives matter more than broad claims about high performance. A buyer should ask to see restore evidence, not just uptime promises.

At the commercial layer, ask whether the service reduces total operational burden or adds hidden supervision costs. A small provider can be attractive if it offers local control, physical proximity, tailored support, and simpler procurement. It can be risky if customers must supply their own monitoring, integration, security review, route monitoring, backup verification, and escalation paths. The public evidence around CPP does not answer that cost-benefit question. It only tells a buyer where to start asking.

At the monitoring layer, track a small set of objective signals. Does AS211730 continue to originate 194.85.111.0/24? Does it add or withdraw prefixes? Do upstream relationships change? Does a PeeringDB profile appear? Do RIPE maintainer, organisation, route, or contact records change? Does the official site publish richer service details, certifications, customer references, or status information? Does the software page add registry entries or public documentation? Those changes would be more meaningful than generic brand coverage.

How the file should be monitored

The simplest monitoring plan is a small evidence register rather than a broad brand watch. The register should separate identity, resource control, routing state, company positioning, and service outcome. Identity fields would include the legal name, registration number, address, company domain, RIPE organisation handle, and contact handles. Resource-control fields would include AS211730, the route object for 194.85.111.0/24, the relevant maintainers, and the administrative and technical role entities.

Routing-state fields would include whether the prefix is visible, which upstream relationships are observed, whether IPv6 originated space appears, and whether route-origin authorization evidence becomes available. Company-positioning fields would include the data-center claims, equipment-rental activity, proprietary software page, and any future public service catalog. Service-outcome fields should remain blank unless public, verifiable evidence appears.

That separation makes the evidence useful without inflating it. If a monitor sees a new prefix, the event belongs first in routing state. It may or may not change the service-outcome view. If CPP publishes a new product page, the event belongs first in company positioning. It may or may not change the routing view. If a public procurement record names CPP for hosting, that would improve market evidence, but it would not by itself prove resilience. If a certification appears, the useful questions would be scope, date, auditor, covered facility, and covered service. The important habit is to avoid letting one field silently populate another.

A network monitor could refresh the RIPEstat announced-prefixes and routing-status views daily or weekly and compare them with the RIPE DB route object. A compliance monitor could watch the company requisites page, RIPE organisation entity, and contact records for address, email, or registration changes. A security monitor could check whether RPKI evidence becomes machine-verifiable and whether the prefix appears in routing-leak, hijack, spam, or abuse datasets. A procurement analyst could watch for public customer references, tender notices, certifications, or service terms. These are different monitoring tasks.

Putting them into one undifferentiated "vendor risk" bucket would hide the specific evidence needed for each decision.

The watch list should also include negative changes. If AS211730 stops originating 194.85.111.0/24, the article's current route-state conclusion would expire. If the prefix moves to a different origin, the entity-resolution question would reopen. If the official site removes the data-center description or changes legal identifiers, the company-positioning and identity confidence should be revisited. If the company adds a public status page, trust center, or product catalog, the evidence file would become richer but still would need verification. In thin-evidence infrastructure work, both additions and removals matter.

This monitoring approach is deliberately modest. It does not require intrusive probing or private access. It relies on public registry, routing, and first-party pages. That is appropriate for a public article because it respects the boundary between observable infrastructure and customer-specific operations. It also gives future updates a concrete structure: the story should change only when a named evidence field changes, not because the company name appears in a generic technology list.

The same structure helps avoid false negatives. A thin public file is not the same as an empty one. CPP has enough public evidence to identify a legal entity, a network resource, a routed prefix, a company domain, and a declared data-center business. Those facts are useful for asset inventories, supplier screening, route monitoring, and jurisdictional review. What remains missing is not "all evidence"; it is the evidence needed to move from external observability to operational judgment. A monitor should therefore preserve the small confirmed facts while keeping stronger claims pending.

That is slower than collapsing everything into a single risk score, but it is more accurate for a company whose public surface is compact and technical.

Why overstatement is the main failure mode

The risk in a CPP article is not only missing a fact. It is overstating a fact. A registry record can be mistaken for a service. A routed /24 can be mistaken for a large network. A data-center marketing page can be mistaken for verified operational performance. A company registration number can be mistaken for commercial traction. Each overstatement would make the article less useful to readers who need an evidence-based view of infrastructure risk.

The opposite mistake is also possible. A small routed footprint can look trivial, but small network resources can sit under important applications. A single /24 may host access gateways, billing endpoints, monitoring tools, authoritative services, or customer systems. The public evidence does not tell us whether CPP's 194.85.111.0/24 hosts any of those things. It does tell us that the prefix exists as an observed routing surface linked to a company that publicly claims data-center activity. For monitoring purposes, that is enough to keep it on the map.

This is why the article's framing is the control surface, not the product. AS211730 is a public control point because someone can maintain route objects, operate or delegate origin announcements, manage contacts, and expose an address block to global routing. The company site is a commercial control point because it tells counterparties what sort of services CPP wants to be associated with. The gap between those two surfaces is where diligence belongs.

In a mature vendor profile, one would expect more public artifacts: service terms, product pages, architecture diagrams, security certifications, support commitments, customer references, developer documentation, network maps, maintenance windows, and incident disclosures. CPP's current public record does not have that depth. It has identity, contact, legal, data-center positioning, software-name hints, and route-state evidence. A good intelligence note should not pretend that is more than it is.

That restraint also protects the company from unfair claims. There is no public evidence in the checked material of an incident, attack, breach, outage, or customer failure. There is no evidence that the single /24 is misused. There is no evidence that its routing is abnormal beyond the ordinary limitations of sparse public data. The correct critique is about evidence limits and due-diligence needs, not about misconduct.

The bottom line

CPP JSC Center of Prospective Projects is a small but concrete infrastructure case. RIPE records connect AS211730 to JSC Center of Prospective Projects. The company's own site connects the same legal registration and Novosibirsk address to data-center services, equipment leasing and maintenance, and proprietary corporate systems. Current public routing data shows one IPv4 /24, 194.85.111.0/24, originated by AS211730 and visible in BGP. That is enough to say CPP has a live routing-control surface adjacent to a first-party data-center business claim.

It is not enough to say the company operates a publicly verified cloud platform, that its facilities meet a particular reliability standard, that its software products are externally deployed, or that its data services outperform a buyer's current stack. None of those conclusions appears in the public evidence used here. The practical value of the file is more modest: it gives analysts a clean starting point for entity resolution, route monitoring, route-security questions, and diligence around a Russian data-center operator whose public network footprint is now observable.

The article should therefore be read as a boundary-setting assessment. CPP matters if AS211730, 194.85.111.0/24, persproject.ru, and the company's Novosibirsk data-center claims intersect with a reader's supplier, traffic, hosting, or risk map. It should not be treated as a broad market profile. The next material update would come from additional prefixes, stronger route-security evidence, a richer PeeringDB or network-operator profile, public certifications, customer or procurement evidence, or company documentation that turns high-level data-center language into measurable operational commitments.

Until then, the best working view is precise and limited: CPP JSC Center of Prospective Projects is a verified Russian infrastructure entity with a small current BGP footprint, first-party data-center positioning, and unresolved public evidence gaps around performance, customers, governance, and recovery.