Summary

  • AS60633 is visible in RIPE-linked records as SWISSCOM-MPLS-TRANSIT Swisscom (Schweiz) AG, giving the directory entity a public autonomous-system identity and contact surface.
  • The captured RIPEstat view marks the AS as not announced, lists no announced prefixes, and reports no observed neighbours, so the record supports a registry/routing boundary story rather than a live transit, facility, capacity, or resilience claim.

The visible record

Swisscom (Schweiz) AG appears here through a narrow public control surface: AS60633. The number is not just a label in a directory profile. It is an autonomous system identifier that can be queried through RIPE-linked registry services and compared with public routing measurements. That makes it relevant to infrastructure readers even when the routing view is quiet. A company name attached to an AS record gives the public a place to inspect registry identity, role contacts, route visibility, and the difference between holding or naming a number resource and visibly originating traffic through it.

The directory object for TRANSIT Swisscom (Schweiz) AG gives the site a precise company anchor, but the public records do not make the operating claim broad. The AS name in RIPE RDAP is SWISSCOM-MPLS-TRANSIT. The registrant organization visible in the same RDAP response is Swisscom (Schweiz) AG. RIPEstat's AS overview uses the holder string SWISSCOM-MPLS-TRANSIT Swisscom (Schweiz) AG. Those fields allow the article to connect the directory entity to AS60633. They do not prove a customer transit service, a current MPLS platform, a live BGP adjacency, a sold product, or a physical route.

That distinction is the reason AS60633 is worth a bounded profile. The public record is strong enough to say that a Swisscom-linked autonomous-system identity exists. The current route evidence is too quiet to say that the same AS is carrying visible routes today. In infrastructure reporting, that gap is useful. It shows where a public registry surface remains inspectable while the running-route layer does not currently support delivery claims.

Registry identity before service claims

RIPE RDAP is the first identity anchor. Its autnum response returns handle AS60633, name SWISSCOM-MPLS-TRANSIT, and status active. The record includes ORG-BA8-RIPE, whose vCard names Swisscom (Schweiz) AG and places the organization in Zurich, Switzerland. The same response includes Swisscom-linked operational contact material, including Bluewin contact roles and an abuse address. For a number-resource profile, those details matter because autonomous system records are part of the public accountability surface for Internet operations.

They are still registry details, not a service brochure. An abuse contact does not prove a live customer base. A role contact does not prove a routing relationship. A postal address does not identify a data centre. A name containing MPLS or TRANSIT does not, by itself, prove that AS60633 is currently selling transit, providing MPLS handoff, or carrying traffic for downstream networks. The proper use of the RDAP evidence is narrower: it identifies the public registry record and the organization that the record names.

That narrower use protects the reader from two errors. The first error is to ignore the record because no route is visible in the current measurement. A registered autonomous system can remain important as an accountability and future-use surface even when quiet. The second error is to overread the record because the holder string sounds operational. A registered AS with a transit-like name is not the same as a measured route. AS60633 sits between those errors and has to be described in that middle position.

The RIPEstat overview changes the frame

RIPEstat's AS overview confirms the identity and changes the operating frame. It reports resource 60633, holder SWISSCOM-MPLS-TRANSIT Swisscom (Schweiz) AG, and the IANA 16-bit AS number block 60416-61439 assigned by RIPE NCC. That confirms the object belongs in a number-resource article, not in a generic Swisscom business summary. It also provides the key current-state field: announced=false.

The announced flag matters because it separates the registry layer from the routing layer. A resource can be registered, named, and contactable while not being visible as an active origin in a routing measurement. RIPEstat's overview says that is the current captured state for AS60633. The AS remains a public registry object. The current public route view, however, does not show it as announced.

That should not be converted into a motive. The evidence does not say why the AS is quiet. It does not say whether the number is reserved, retired, used only in a limited environment, held for a migration, hidden from a particular collector set, or simply not active. It only allows the visible observation: AS60633 is registry-visible and marked not announced in the captured RIPEstat overview. The article should treat that as a boundary rather than a verdict.

Announced prefixes and the missing route footprint

The announced-prefixes endpoint makes the boundary more concrete. For AS60633, RIPEstat returns an empty prefix list. Prefix origination is one of the basic ways an autonomous system becomes visible in the public routing system. When an AS originates IPv4 or IPv6 prefixes, those routes can often be seen, timed, compared, and checked against other routing-security or registry evidence. An empty list means the current source does not support a visible route footprint for this AS.

That absence is meaningful, but it is not limitless. Public routing collectors do not prove every private arrangement, internal use, or future plan. A route may also appear later, disappear after a historical period, or be visible through a different measurement surface. The right conclusion is therefore not that Swisscom has no network or that AS60633 never mattered. The right conclusion is that no announced prefixes are visible in the captured RIPEstat announced-prefixes view, so live route-origination claims cannot be made from this evidence.

That distinction is important for a company article because Swisscom is a large incumbent operator with many possible services and historical records. The article is not about every Swisscom network. It is about the exact directory entity and the exact AS60633 record. The empty prefix list narrows the topic to registry visibility and route silence. It should not be stretched into a claim about Swisscom's broader infrastructure, emergency services, private 5G, managed networks, security products, or tower economics.

Routing status as running-code check

The routing-status endpoint provides the running-code check. At the recorded query time, RIPEstat reports zero IPv4 RIS peers seeing the ASN and zero IPv6 RIS peers seeing it. It reports zero announced IPv4 prefixes, zero announced IPv6 prefixes, zero observed neighbours, and a resource value of 60633. Those fields align with the overview and announced-prefixes data. The public routing sample is quiet.

That quiet state is where the Heng.lu doctrine card fits the piece. A registry is a ledger and recordkeeper; it is not the running network itself. Running-code primacy means the route table has to be inspected separately from the registered number. AS60633 has a public registry identity, but the captured route table does not show the AS originating public prefixes or appearing with observed neighbours. The evidence therefore supports the distinction between a number-resource record and an operating route.

This distinction is not academic. Many infrastructure claims fail because they move too quickly from a registry label to an operational conclusion. An AS name may sound like a service. A contact role may sound like a network operations function. A directory profile may sound like a company footprint. But the live route evidence must still be checked. For AS60633, that check does not currently support live transit delivery.

Historical route traces without current visibility

RIPEstat's routing-status data also records historical route observations. It lists a first-seen prefix, 195.186.128.0/17, with origin 60633 in 2016, and a last-seen prefix, 213.3.80.0/21, with origin 60633 in 2024. Those fields make the profile more interesting because the AS is not merely an empty registry line in the public tooling. The historical fields show that RIPEstat has seen routing activity associated with the origin in the past, even though the current visibility counters are zero.

The historical traces still do not prove current service. They make the article more precise: AS60633 has a registry identity, past route-observation signals in RIPEstat, and no current announced prefixes in the captured sample. That combination is different from an AS with no observed history and different from an AS with an active current footprint. The publication should keep all three layers visible.

A careful reader can understand the practical meaning. The AS may have been active in earlier periods, may have been used in a context no longer visible, or may have changed role. The records here do not explain why. They only establish a dated boundary between past visibility and present silence. That is valuable because it prevents the article from treating a quiet current state as proof of permanent absence, while also preventing old observations from being turned into present-tense service claims.

The Swisscom brand boundary

The production precheck identified existing Swisscom-related coverage. That matters because a new Mara article about this directory entity must not become a duplicate Swisscom brand profile. Prior articles have covered tower pricing, private 5G, router-level home protection, managed networks, incumbent economics, and emergency-call outages. Those are different editorial lenses. Plan895 has to stay on the AS60633 number-resource surface and the public route-silence boundary.

The existence of those broader articles should not be used as evidence for AS60633. A private 5G story does not prove the current status of this AS. A router-security story does not prove route origination. A tower-pricing story does not prove Swisscom's use of this number resource. A redundancy or emergency-call story does not prove that AS60633 is active, resilient, or customer-facing. Those records only tell the writer where not to go.

This is a useful commissioning discipline. Large operators generate many records, but not every record supports every claim. The AS60633 piece should be small and exact. It should speak about a RIPE-registered autonomous system and its current route visibility. It should not use the Swisscom name as permission to write a general telecom profile.

What the directory route contributes

The public directory route contributes identity and reachability. It shows an existing directory page for transit-swisscom-schweiz-ag and gives the article an exact object to link. That is necessary because Mara articles are supplements to existing directory entries, not substitutes for directory records. The article should therefore bind to the entity and leave the directory as the company anchor.

The directory route does not replace the registry and routing evidence. Public directory copy can summarize, normalize, or lag behind underlying records. The strongest source for the AS identity remains RIPE RDAP, while the strongest source for route visibility remains RIPEstat. The directory route is used to prove that the site has an exact company object and that the reader can navigate back to that object. It is not used to invent facility claims, route activity, customer relationships, or service quality.

That separation keeps the article inside the directory-centered model. The directory object supplies the company boundary. RDAP and RIPEstat supply the number-resource and routing boundary. The article explains what the public can see between those layers. It does not declare itself to be the directory record, and it does not use article prose to rewrite the company object.

Why PeeringDB is only auxiliary here

The PeeringDB API attempt for ASN 60633 returned HTTP 404 in this environment. That result is kept only as an auxiliary unavailable signal. It is not a finding that Swisscom lacks peering, interconnection, exchange presence, traffic policy, or network relationships. A missing or unavailable API response is not a negative measurement of the Internet.

This limitation is worth naming because peering and transit language can easily become overconfident. If PeeringDB had returned a clear record, it might have provided additional public context about network interconnection. It did not. The article must therefore stay with RDAP and RIPEstat. The absence of PeeringDB evidence means less can be said, not that the opposite claim has been proved.

A good public copy choice is to avoid the word peering except as a boundary. The records do not support a peering fabric claim. They do not support a transit relationship claim. They do not support a policy description beyond what RIPEstat and RDAP show. The article can say that the PeeringDB query did not provide usable auxiliary evidence in this environment and that no peering conclusion is drawn from it.

Reading route silence responsibly

Route silence can be a tempting phrase because it sounds dramatic. In this article, it should mean only one thing: the captured RIPEstat views do not show AS60633 as announced, do not list announced prefixes, and do not report observed neighbours. That is a measurement statement. It is not an accusation, an outage report, or a business-status judgment.

The distinction matters for Swisscom because the company has many live network operations outside this exact AS record. A quiet AS60633 observation cannot be generalized to Swisscom's whole network. It cannot even be generalized to every possible use of AS60633 outside the captured public view. It is a bounded observation about a particular autonomous system in a particular set of public tools at a particular time.

That boundedness is also what makes the piece durable. If the AS becomes announced later, a future update can compare the new route table with the current record. If it remains quiet, the current article gives a baseline. Either way, the publication should not overstate what a single captured view can prove.

Number-resource accountability without advocacy

The public-interest argument is not that every quiet AS is suspicious. The argument is that number-resource records deserve accurate reading. Autonomous system numbers organize routing identity. RDAP exposes registrant and contact metadata. RIPEstat exposes measurement views that can confirm or limit operating claims. A directory object can help readers connect the technical record to a named company. Together, those layers create an accountability surface.

For AS60633, the accountability surface is useful precisely because it is incomplete. The registry names a Swisscom-linked record. The current route view does not show activity. The public can inspect that gap. A writer does not need to advocate for a policy outcome, accuse the operator, or imply hidden failure. The job is to show the reality layer: what is visible, where it appears, and which claims remain unsupported.

That approach respects the Heng.lu principle map. The registry acts as a recordkeeper, not as a sovereign proof of operational reality. Running-code evidence remains primary for claims about live routing. Number resources require accuracy, contactability, and operational continuity, but those ideals have to be checked through evidence rather than asserted as rhetoric. AS60633 gives a compact example of why those distinctions matter.

What future evidence would change

Future evidence could change the article's frame. If AS60633 begins originating prefixes visible to RIPEstat or another public collector, the story would shift from route silence to route activation. If observed neighbours appear, the relationship between the AS and the surrounding routing system could be described with more confidence. If RPKI or route-origin authorization data appears for active prefixes, a security-metadata layer could be added. If Swisscom publishes a clear statement about the role of AS60633, that statement could be compared with the public route data.

Those future conditions are not present in the current evidence. The current captured data supports a quiet route state. It supports Swisscom-linked registry identity. It supports historical route-observation fields. It does not support service delivery, resilience, traffic, facility, customer, or topology claims. A later article can say more only if later evidence shows more.

This future-oriented framing is useful because it prevents the article from becoming stale advocacy. It does not claim the route will remain quiet. It does not claim Swisscom should or should not use the AS. It simply records a current boundary and names the public checks that would matter if the boundary changes.

Why the image stays generic

The featured image must stay generic for the same reason the prose stays narrow. The source evidence does not document a Swisscom facility, a router room, a fibre path, a customer handoff, a data centre, or a route map. A documentary-looking image with a logo, map, dashboard, or identifiable facility would add a claim that the records do not support.

The approved image is therefore a generic editorial illustration of network equipment and fibre interconnection. It helps readers understand the registry and routing theme without pretending to show AS60633 itself. The caption and alt text must say it is non-documentary. The image should not be used as proof of Swisscom's assets, topology, operating centre, customer links, capacity, or live transit service.

That visual restraint is not cosmetic. Images can smuggle in claims as easily as sentences can. A company-logo rack implies access. A map implies geography. A fake route diagram implies topology. A facility photo implies physical evidence. The image boundary keeps the visual layer aligned with the public records.

The practical reader's checklist

A practical reader can reproduce the boundary in a few steps. First, inspect RIPE RDAP for autnum 60633 and confirm the handle, name, active status, and Swisscom organization reference. Second, inspect RIPEstat AS overview for AS60633 and check the holder and announced flag. Third, inspect announced-prefixes and routing-status for current prefix and neighbour visibility. Fourth, keep the directory route as the company anchor rather than the proof of live operation.

Those steps give a clear result. AS60633 is visible as a registry object linked to Swisscom (Schweiz) AG. The current RIPEstat overview marks it not announced. The announced-prefixes list is empty. The routing-status counters show no visible prefixes and no observed neighbours. The public article should follow that result without adding unsupported inferences.

The checklist also explains why this kind of profile matters. Infrastructure readers often need to distinguish between a company that is visible in a registry and a company that is visibly operating a route. The first can be true while the second is not shown. AS60633 gives a clear case of that separation.

A narrow thesis that still moves the record

A narrow thesis can still move the public record if it is exact. The article does not need to claim that AS60633 is large, active, critical, or failing. It can say something more useful: the Swisscom-linked registry identity exists, and the current public route view is quiet. That small claim is evidence-backed and meaningful because it marks the boundary between administrative visibility and running-route observation.

The reason this belongs in a Mara Voss infrastructure slot is that public infrastructure depends on these boundaries. Number-resource systems have to be accurate enough for other networks and readers to inspect. Routing data has to be treated as running evidence rather than assumed from names. Directory records have to bind articles to existing company objects without becoming a substitute for operational proof. AS60633 brings those three requirements together.

That is also why the conclusion should remain restrained. A reader should not leave thinking Swisscom has been shown to operate a live AS60633 transit product. A reader should leave knowing that AS60633 names Swisscom in public registry data and that the captured route table does not show present announcements. The distinction is the story.

The final operating boundary

The final operating boundary is simple. The public record names AS60633 and connects it to Swisscom (Schweiz) AG. The current RIPEstat evidence does not show announced prefixes or observed neighbours. Historical route fields suggest the AS has appeared in route observations before, but they do not prove current use. PeeringDB did not provide a usable auxiliary record in this environment. Existing Swisscom articles do not change the AS60633 evidence.

Everything else is outside the source boundary. Current transit service is unproved. Customer dependency is unproved. Route diversity is unproved. Capacity is unproved. Facility location is unproved. A decommissioning or outage narrative is unproved. The publication should keep those denials visible because they are not caveats; they are the difference between evidence and speculation.

AS60633 therefore belongs in the public record as a registry-visible, route-silent number-resource profile. It shows how a company can be named in the Internet's administrative layer while the running control plane remains quiet in the captured view. That is not a complete operating profile. It is a useful boundary, and it is the boundary the evidence supports.

Why the quiet record should be kept watchable

A quiet public AS record should remain watchable because the route table can change. If prefixes appear, the article's baseline becomes the before state. If the AS remains quiet, the article remains a record of the administrative surface that still exists. If contacts or holder strings change, the directory and registry relationship may need a new check. Public infrastructure evidence is often cumulative; the value of one bounded snapshot is that it makes the next check easier.

For Swisscom, that watchability is especially important because the broader company has many network roles. A narrow AS record can disappear inside a large operator's brand unless the record is kept exact. AS60633 should not be inflated into a company-wide claim, but it also should not be ignored simply because current route visibility is absent. It is a discrete number-resource surface with its own public evidence.

The watchable fields are clear: RDAP holder and contact data, RIPEstat announced state, announced prefix list, routing-status visibility, and any future auxiliary interconnection evidence. Those are the fields that would support a future update. Until they change, the safest line remains unchanged: AS60633 names Swisscom in the registry while the route table goes quiet.

Reading a Swiss incumbent through one small AS

Swisscom's scale outside this record makes the narrowness of AS60633 more important, not less. A large incumbent can appear in many infrastructure stories at once: consumer broadband, mobile access, enterprise services, wholesale arrangements, security products, public-safety reliability, data-centre connectivity, and regulated national networks. None of those frames automatically explains a single autonomous system record. The fact that a company is operationally important in other settings does not make every registry identifier a live service surface.

AS60633 therefore needs to be read as its own object. Its public name includes MPLS and TRANSIT, but the current routing evidence does not let that name become a service statement. Its organization link points to Swisscom (Schweiz) AG, but the current routing evidence does not let that organization link become a topology statement. Its status is active in RDAP, but the current routing evidence does not let active registry status become active route origination. Each term answers a different question.

This is the point that matters for readers who use directory profiles to understand infrastructure. A directory company can be real and important while a particular resource tied to it remains quiet. The company object is the anchor; the resource record is the lens. The route data is the check. If any of those layers is missing or silent, the article should describe the missing or silent layer rather than filling it with assumptions drawn from the company brand.

What active status does and does not say

The RDAP status field says active. In a registry context, that is a meaningful fact. It means the autnum object is not presented as removed or unavailable in the response that was captured. It gives the record a current public existence and allows contact and holder fields to be read as live registry metadata. That is enough for a company-linked number-resource profile because it gives the public a record to inspect.

Active status does not tell the reader that the AS is announcing routes. That is why the article has to move from RDAP to RIPEstat. Registry status and routing status are related but not identical. A resource can stay active in the registry even when it is not visible in the route table. It can also become visible in routing while registry data remains incomplete or stale. The public interest is in checking both layers and keeping them separate.

For AS60633, the two layers point in different directions. RDAP shows an active registry object. RIPEstat's current overview and routing-status endpoints show no public route visibility. That split is the core evidence. It means the record can be discussed as a live registry object and a quiet routing object at the same time. The article should not choose one layer and erase the other.

Contactability as accountability surface

The contact information in RDAP is also part of the accountability surface. Abuse and technical contacts matter because public networks require a way to direct complaints, questions, and operational coordination. A contact role does not prove traffic flow, but it does give other operators and researchers a named channel in the registry record. In a number-resource story, that is more than background detail.

The Swisscom-linked contacts around AS60633 show that the resource is not merely a random string detached from an organization. The vCard data names Swisscom (Schweiz) AG and contact roles associated with Swisscom network operations. That supports the company identity boundary. It does not tell the reader how packets move, whether any customer depends on the AS, or whether the AS has a current route origin.

This is a useful difference. Contactability is administrative accountability. Route visibility is operational evidence. Both matter, but they are not substitutes for each other. AS60633 has the first in the captured RDAP response and lacks the second in the captured RIPEstat route view. The article's value comes from holding that distinction without softening it.

The empty prefix list as a discipline

An empty prefix list can make an article feel thinner, but it is also a discipline. It tells the writer which claims are unavailable. No prefix means no sourced route origin to describe. No prefix means no sourced address space to count. No prefix means no sourced visible customer handoff to infer. It removes the easy paragraphs about geography, reach, capacity, or traffic because those paragraphs would need a routed footprint that is not present.

The remaining story is more administrative, but still infrastructural. Number resources can be assigned, maintained, contactable, historically observed, and currently quiet. That condition matters because the Internet's public control systems are not only about traffic volume. They are also about traceability, responsibility, and the ability to distinguish an observed route from a dormant or unobserved record. AS60633 is a small case where that distinction has to be visible.

The empty list also creates a useful warning for future monitoring. If a future query returns prefixes, that change will be significant because the present baseline is empty. If a future query remains empty, the record continues to be a quiet registry surface. Either way, the article establishes a clean point of comparison without pretending to explain why the state exists.

Historical observations and present tense

The historical first-seen and last-seen fields should be handled carefully. They show that RIPEstat has route history for AS60633, which keeps the record from being read as purely hypothetical. But historical route observation is not present-tense route observation. A prefix seen in 2016 and another last seen in 2024 do not prove a route in 2026. The current overview and routing-status fields still control the current-tense claim.

This is a common problem in infrastructure writing. Historical records can make an operator look active even when current visibility has changed. Conversely, current silence can make a record look empty even when it has a past. The better approach is chronological: say what was historically observed, say what the current measurement shows, and do not blend the two into one operating statement.

For AS60633, the chronology is straightforward. RIPEstat's historical fields show prior observations. Its current fields show no announced prefixes and no observed neighbours. The piece can use that timeline to say that the AS has a public route-history trace but no current visible route footprint in the captured sample. That statement is narrower than a service profile and stronger than a generic directory summary.

Why the headline must stay bounded

The headline direction should not use words that imply a live product. Phrases such as carries traffic, expands transit, reaches customers, powers routes, restores resilience, or strengthens Swiss connectivity would all go beyond the evidence. The strongest headline is quieter: AS60633 names Swisscom in the registry while the route table goes quiet. That tells the reader there is both an identity and a limit.

A bounded headline also protects the body from drifting. Once a headline implies live transit, the paragraphs tend to follow it. They start looking for customers, capacity, resilience, and outage angles that the records do not support. A registry-and-route-silence headline keeps the article honest from the first line. It prepares the reader for a piece about evidence boundaries rather than a profile of a live network service.

That matters because Swisscom's name carries weight. Readers may assume that a Swisscom-linked AS is necessarily part of a large, active production network. The headline should interrupt that assumption and bring the reader back to the exact public evidence. The company is named. The AS is active in the registry. The route table, in the captured view, is quiet.

Category and topic discipline

The category and topic should follow the evidence. The article can sit under a regional ISP or network-infrastructure category because the subject is a company-linked autonomous-system record in the RIPE service region. But the topic should remain network-resource evidence, not cloud services, cybersecurity, emergency communications, tower economics, or general telecom strategy. Those broader topics would make the piece look more complete than it is.

Topic discipline also helps avoid duplicate coverage. Existing Swisscom pieces already occupy other lenses. Plan895 should not compete with them. It should add a precise resource-level observation that those articles do not cover. The contribution is not another Swisscom business story. It is a dated AS60633 boundary check.

If a later preflight or taxonomy check says the category needs a different smallest active leaf, that is a production gate to handle later. It should not change the source claim. The source claim remains the same: AS60633 is a Swisscom-linked registry record whose current public route visibility is absent in the captured RIPEstat data.

What a safe follow-up would ask

A safe follow-up would not ask whether Swisscom is a good or bad operator based on AS60633. It would ask more concrete questions. Is AS60633 currently originating any prefix in a later RIPEstat query? Are there observed neighbours after the current quiet sample? Does any RPKI or routing-policy evidence line up with a future active prefix? Has Swisscom published any statement about the role of this AS? Do the directory and registry records continue to name the same company object?

Those questions are useful because each has an evidence path. They can be answered or left unanswered without turning into speculation. They also show how a quiet profile can become part of a monitoring sequence. The first article names the boundary. Later checks can test whether the boundary moved.

That is the right way to treat AS60633. The record should stay visible, but the interpretation should stay conditional. If routes return, the evidence changes. If they do not, the registry surface remains watchable. The current article should not decide the future state in advance.

Evidence restraint as reader service

Evidence restraint is a service to the reader because it explains what the reader can safely repeat. A reader can repeat that RDAP returns AS60633, that the name is SWISSCOM-MPLS-TRANSIT, that Swisscom (Schweiz) AG appears in the organization fields, and that RIPEstat currently reports the AS as not announced. A reader can repeat that no prefixes or neighbours were visible in the captured RIPEstat view. A reader cannot repeat that Swisscom is currently carrying traffic through this AS.

That distinction is not just legal caution. It is operational clarity. Infrastructure systems are layered, and the credibility of coverage depends on naming the layer. Registry evidence is registry evidence. Route evidence is route evidence. Contact evidence is contact evidence. Directory evidence is directory evidence. AS60633 allows all of those layers to be named, but only some of them are active in the captured data.

The public copy should keep that structure visible so readers do not have to reverse-engineer the boundary. Each section should tell them which evidence is being used and which claim it supports. If a claim would require a missing source, it should not appear. That is the discipline that turns a small quiet ASN into a useful infrastructure record.

Conclusion

AS60633 makes Swisscom (Schweiz) AG visible in the number-resource layer, but it does not make a current transit service visible in the captured public route view. RIPE RDAP returns the autonomous system as active and names SWISSCOM-MPLS-TRANSIT with Swisscom organization linkage. RIPEstat names the holder, marks the AS as not announced, returns no announced prefixes, and reports no observed neighbours at the captured time.

That combination is not empty. It gives readers a real registry object, a company anchor, and a public measurement boundary. It also stops short of the claims that would require stronger evidence: live customer routes, current transit delivery, topology, capacity, route diversity, resilience, outage, or facility control. The honest profile is narrower and stronger: a Swisscom-linked AS record remains publicly visible, while the current running-route surface is quiet.

Sources