摘要
- 公共网络记录显示 Elysia Network 与 AS151494 关联。有用的问题不是该名称是否出现在注册信息中，而是该记录能否对应到中国境内可运行、可恢复的客户服务。
- 本次检查中 RIPEstat 未显示当前宣告的前缀；RIPEstat 历史记录最后一次看到 2406:840:feda::/48 是在 2026-03-15T08:00:00。这意味着不应将历史或注册证据视为当前托管工作负载的证明。
- 互联证据表明：针对该 ASN 查询未返回 PeeringDB 网络配置文件。邻居证据表明：RIPEstat 邻居视图中当前无可视邻居。这些记录有助于定位运营表面，但不能证明物理路径多样性或商业转接独立性。
- 客户面临的风险在于注册容量与可用容量之间的差距。一个活跃的 ASN 仍可能因单个机架、单个上游、一次远程手工排障队列、一次账单锁定或一次迁移陷阱而失效；而一个休眠的 ASN 仍可能被营销宣传得超出公共证据所能支持的程度。
- 证据等级为弱至中等。这些记录支持一个网络学习/资源持有者的足迹，而非传统的零售托管业务。任何买家在将其视为托管容量之前，都应要求提供付费服务、支持责任和连续性安排的证明。
云服务账单最终仍落在物理空间
误解 Elysia Network 最简单的方式就是停留在“云”这个词上。云或托管账户只是包装了处理器、内存、存储、路由器、地址资源、设施访问以及能在故障时介入的人员的商业外壳。公共路由表仅展示这种布局的控制平面边缘。它不会显示电缆桥架、上锁的机柜、电源馈线、备用的光模块或能在午夜进入现场的工程师。
对于 Elysia Network 来说，当前路由信号是受限的。本次采集未发现任何当前宣告的前缀，RIPEstat 历史记录最后一次看到 2406:840:feda::/48 是在 2026-03-15T08:00:00。这种缺失应被视为证据，因为托管容量的主张依赖于当前的可达性、当前的支持和当前的运营义务。
托管服务的经济契约在于：提供商将杂乱的物理资产转化为按月收费。客户得到一个接口和一份账单；提供商则掌握着机架布局、运营商合同和维修计划。这种安排或许合理，但它集中了判断力。当 Elysia Network 负责可达性时，客户必须追问：当第一条良好路径消失时，还剩下什么真正可用？
公开证据的起点包括RDAP、RIPEstat 概览、路由状态、宣告前缀、邻居、路由历史、PeeringDB、Cloudflare Radar、BGP.tools、Hurricane Electric、IPinfo、RPKI 验证。这些记录并非营销文案，而是机械性的观测结果，有助于将实际路由足迹与需要合同证据的主张区分开来。
身份记录有用，但不等于服务本身
AS151494 标识的是一个网络边界，而非 Elysia Network 旗下的每个法律实体、员工、数据机房或产品。这一区别很重要，因为责任可能被拆分。注册对象可能指定一个持有人，PeeringDB 可能使用一个交易名称，网站可能描述更广泛的服务，而客户合同则可能由另一家关联企业签署。
在本次简要抓取中，RIPEstat 概览里的持有人标签信息量有限。该标签有助于将该 ASN 与标的关联起来，但并非服务水平承诺。它表明号码资源证据指向何处，却未说明客户获得的是裸金属托管、虚拟机、IP 转接、托管网络服务还是内部企业网络功能。
最重要的事实是：一个在技术上引人关注的 ASN，与缺少公开证据的商业云资产之间存在不匹配。因此，买家应将以下三个问题分开：谁控制着号码资源？目前有哪些服务（如果有的话）在使用它？当服务失效时，谁在合同中承担责任？公开数据能帮助回答第一个问题，而第二和第三个问题则需要实时的技术与商业证明。
对于带有托管品牌色彩的名称来说，这种区分尤为重要。托管术语可能在服务器迁移、客户转走或 ASN 闲置后依然保留。该标签应激发追问，而非替代追问。
路由历史不应被过度解读
历史路由证据有用，但不应被包装成当前容量来兜售。RIPEstat 列出的首次观测路由是 2406:840:9150::/44 于 2023-07-06T16:00:00，末次观测路由是 2406:840:feda::/48 于 2026-03-15T08:00:00。
历史记录有助于识别连续性风险。一家公司可能因迁移客户、更换上游、出售资产、外包交付或停止某项服务而停止发起某条前缀。每个原因对客户而言意义不同。在没有运营商声明或当前流量证据的情况下，路由收集器无法加以区分。
因此，路由历史视图最好用作时间线。它可以显示路由是短暂测试过、长期运行、间歇出现，还是在某一时段后撤回。但它无法证明服务器位于何处、客户是否受影响，以及同一组织是否仍控制着该服务。
对于采购而言，规则很简单：不要用过去的 BGP 数据来购买当下的弹性。历史宣告可以支持身份和过去的运营情况，但无法确立当前容量、备份路径或事件响应。
RPKI 有助于应对源端风险，而非所有故障
路由源验证问的是一个具体问题：AS151494 是否被授权发起给定的前缀？就 Elysia Network 而言，本次抓取中的验证快照显示，当前没有可用于路由源验证的前缀。此处所用的第一个验证 URL 是RIPEstat RPKI 验证。
有效的源数据之所以有用，是因为它能降低路由被实施路由源验证的网络拒绝的可能性。它还表明，某个有权使用号码资源控制权限的人已采取管理步骤来发布授权。对于同一条活跃前缀来说，这比未知或无效的源状态要好。
RPKI 无法解决所有故障。它不能证明服务快速、冗余、本地化、人员充沛或物理上多样化。它无法防止接入光纤被切断、上游过载、电力切换失败、防火墙配置错误或工单等待远程手工处理等情形。它保护的是控制平面的一个局部，而非整个服务。
更宽泛的方法在RFC 6811以及APNIC和ARIN提供的操作资料中有所描述。这些文件解释了为什么源验证属于韧性对话的一部分，同时明确它只是众多控制措施中的一项。
对等和设施线索并非容量审计
针对 ASN 查询的PeeringDB API未返回任何 PeeringDB 网络配置文件。
PeeringDB 之所以有价值，是因为它常常暴露互连的实际语汇：策略、交换中心数量、设施数量、大致的宣告前缀数量，有时还有 looking glass。对于 Elysia Network，这些字段有助于判断其公开足迹看起来像一个孤立的路由块，还是一个连接到交换中心的网络，或是一个更广泛的互连参与者。
但 PeeringDB 并非审计报告。一份配置文件可能是旧的、稀疏的或仅表达志向的。设施数量并不能保证客户工作负载就在那些建筑内运行。连接到交换中心并不证明付费转接具有多样性。open、selective 或 restrictive 之类的通用策略既不说哪些路由被接受，也不说哪些会话具备默认路由能力，更未说明故障后如何处理拥塞。
实际用途是将公开信息转化为问题：所列哪个设施实际用于客户入口？是否有两台路由器、两个电源域和两路光纤入口？是否有交换中心的路由服务器会话承载关键流量，还是仅针对特定目的地的免结算对等？如果设施、交换中心或某个上游不可用，提供商能否保持服务在线？
转接多样性需经两层证明
转接多样性必须在路由层和物理层都得到证明。RIPEstat 邻居视图中，AS151494 当前无可视邻居。这告诉我们公共 BGP 能看到什么，却不能说明这些邻居是上游、对等方、客户还是从交换中心学到的路径，也无法揭示会话底下的管道或交叉连接。
一个网络可能有两个逻辑上游却共享同一栋楼的入口；可能有两台路由器却插在同一个插线板上；可能有备份转接合同，但在最繁忙时段容量太小无法承载流量；可能 BGP 表看起来多样，却仍依赖同一台交换中心交换机、同一条远程手工排障队列或同一台管理跳板机。
因此，客户需要区分不同的术语。路由多样性意味着控制平面有替代路径；运营商多样性意味着不同的商业和运营对手；物理多样性意味着光纤路径、入口、机架和电力安排不会同时失效；容量多样性意味着剩余路径能够承载关键负载而不丢弃流量。
MANRS和RFC 7454在此构成有用的背景。它们定义了良好的路由行为和运营卫生，但并未证明 Elysia Network 已购买或测试过客户可能需要的每一条多样路径。
安装容量不等于客户可用的容量
故障期间，安装容量与可用容量会迅速拉开距离。安装容量是看似存在的东西：可路由前缀、端口、服务器、存储、转接承诺和设施合同。可用容量是当某个部件宕机、维护窗口开始或上游撤回路由后仍可运作的部分。可恢复容量是能在客户的运营截止时间前恢复的部分。
对于 Elysia Network，公开证据可以描述地址空间和一些互连线索，却无法告诉我们有多少虚拟机管理程序在运行、存储如何镜像、备件光模块和服务器是否在站，或者有多少客户工作负载能够同时迁移。即便拥有有效路由和公开信息，如果恢复站点规模不足或支持队列过载，网络仍可能缺乏可恢复容量。
IPv6 同理。可见的 IPv6 聚合前缀可表明技术成熟度，却不能证明客户应用、监控、支持工具和接入网络同样就绪。双栈运营只有在两个协议栈都得到运营维护，且单个协议栈失效不会令关键服务停摆时，才能增加弹性。
买家应按层级询问可测量的余量：客户接入、汇聚、边缘路由、存储、计算、备份和支持。一个简单的平均利用率数字过于粗糙。重要的数字是在受测故障期间还剩多少，而非在平静时段曾有多少。
电力、备件和人力决定修复时钟
物理修复是服务抽象变得具体的地方。如果路由器线卡故障，需要有人有备件和权限去更换；如果服务器失去一路电源，需要有人进入机房；如果交叉连接失效，设施运营商可能控制着工单；如果云存储卷变得不一致，提供商可能需要一支专家团队而非现场技术人员。
公开记录极少发布这些细节，Elysia Network 也不例外。这种缺失是正常的，但不应被忽视。购买托管容量的客户同时也买下了提供商的出入安排、维护合同、供应商关系和人员配置模式。故障时钟在正式事件通知之前就已启动，它从检测、分诊和现场访问开始时就走起了。
修复问题应当用运营时间来提问，而非使用宣传册上的语言。从告警到有资质负责人接手需要多久？到达设施需要多久？本地库存备有哪些部件？哪些维修需要第三方工单？变更窗口的人员是否与应急恢复人员相同？如果支持门户本身就在受影响系统内，客户如何收到通知？
这些问题对于规模较小或聚焦区域的网络尤为重要。庞大的足迹可能掩盖薄弱的本地流程；而小巧的足迹若具备严谨的备件管理、清晰的上报路径和诚实的容量上限，同样可以具备弹性。公开路由证据并不能裁定这个问题。
数据本地性是一个布局问题，而非国家代码
数据本地性常被简化为公司或 ASN 附带的国家代码，但这过于简单。此处 Elysia Network 与中国关联，但托管工作负载可能将客户数据、日志、备份、管理访问和支持记录置于不同位置。ASN 所在国并不自动等于存储所在国、支持所在国或法律签约所在国。
客户需要一份布局矩阵：主服务在哪里？恢复副本在哪里？备份存储在哪里？哪些供应商可以访问系统？日志和工单驻留在何处？哪个国家的法律管辖访问请求和删除？网络路由可能在客户毫无察觉的情况下跨越国境，而支持工程师可能从与机架不同的司法管辖区访问系统。
数据主权还涉及恢复维度。如果提供商倒闭或客户退出，客户能否以可用格式获取完整数据？在主服务降级期间能否生成导出？导出是否包括文件、元数据、日志和配置，还是仅包含数据库提取？终止后的导出窗口有多长？
此处引用的公开记录无法回答这些合同层面的问题，它们只能表明这些问题为何重要：地址资源和互连是服务表面的一部分，但客户的运营依赖通常延伸至存储、身份、计费和支持等 BGP 无法看见的流程。
支持条款是基础设施的一部分
支持并非基础设施的软性附加项，而是将不可见的故障转化为已修复服务的机制。提供商即便拥有有效路由，若工单受理缓慢、上报路径不清，或有权实施变更的团队在事件期间无法到场，仍可能令客户陷入困境。
最重要的支持事实应是可度量的：谁能宣布重大事件？哪些症状可以获得电话升级资格？状态通道是否独立于生产控制平面？客户能否查看路由、设施或存储事件的细节，还是只能看到一份笼统的停机说明？在正常控制台不可用时，支持人员能否执行数据导出？
计费和账户状态同样属于基础设施。账户暂停、支付失败、域名过期、控制面板锁定或支持权益争议，都可能像断纤一样中止服务。托管容量既依赖技术连续性，也依赖行政连续性。
对于 Elysia Network，公开网络证据足以提出这些支持方面的问题，却不足以回答它们。这正是公开研究的合理边界：不应虚构服务水平，也不应让公开细节的缺失掩盖运营风险。
监控将路由转化为运营信号
AS151494 的实际价值在于它能够被观察。客户可以从多个位置监控前缀集合、路由源验证、邻居变化和基本可通性。这不能替代提供商自身的监控，但为客户提供了一种独立的方式来查看公开边缘是否发生了变化。
监控应区分不同的症状。路由撤回不同于服务器宕机，国际链路上的丢包不同于设施故障，控制面板中断不同于客户工作负载丢失。买家在事件发生前越能区分这些层面，在事件发生时浪费的时间就越少。
本文使用的公开工具之所以有用，是因为它们位于提供商自己的叙事之外。RIPEstat、PeeringDB、Cloudflare Radar 以及公共 BGP 聚合器各自看到边缘的不同部分。彼此一致会增加信心；不一致未必是故障，但能告诉客户下一步该追问哪里。
监控计划还需要有人担当。必须有人决定哪些变化重要、由谁联系提供商、捕获哪些证据，以及何时将业务切换到备用方案。没有这种运营习惯，公开路由数据就只是有趣但无用的摆设。
变更控制是一项隐性依赖
即使客户不做任何操作，托管容量也会发生变化。路由器接收策略变更、服务器打补丁、证书续期、存储池扩容、过滤器调整，以及供应商执行维护。每次变更既能保护服务，也可能引入新故障。客户极少看到完整的变更日历，因此他们需要明确的提前通知和回滚预期。
就 Elysia Network 而言，本文回顾的公开记录均未发布变更策略。这很正常，但也凸显合同语言的重要性。客户应了解紧急变更如何获批、影响客户的维护是否提前告知、变更是否先在较小范围内测试，以及提供商如何沟通回滚。
公开证据单薄时，变更控制也变得危险。如果提供商无法展示当前路由、设施或支持边界，客户可能不知道存在哪些变更域。上游、设施、经销商或云供应商的变更都可能影响服务，即使账单上的品牌名称毫无变化。
良好的变更实践并不能消除事件，但能让事件变得可诊断。它保存了变更内容、审批人、监控所见以及安全的恢复步骤等历史记录。这段历史正是客户所购买容量的一部分。
迁移是最终的弹性测试
对托管容量的最终测试是客户能否离开。仅在提供商健康时才能工作的服务，给客户的是效率而非独立性；而能够导出完整记录、配置和运营证据的服务，即使主平台不可用或在商业上不合适，也能为客户提供退路。
对于 Elysia Network，公开网络层无法展示导出路径，只能说明它们为何重要。如果提供商的路由边缘、支持渠道或计费系统发生故障，客户可能需要在压力下迁移 DNS、地址、备份、应用数据和访问控制。迁移规划属于弹性评估的一部分，而非仅仅放在终止条款里。
客户应询问哪些数据可在无需专业服务的情况下导出、哪些需要提供商协助、导出数据保留多久、是否包含日志和附件，以及提供商能否在生产事件进行期间生成导出。应在依赖导出之前，先在一个小但完整的工作负载上测试导出流程。
迁移并非对提供商的威胁，而是提供商理解客户依赖性的证据。一个有弹性的托管服务应在故障期间让客户能力更强，而非使其更加受困。
买家应如何验证这些主张
买家应首先要求提供在线服务的证明：询问哪些面向客户的服务使用 AS151494，哪些前缀指派给该产品，以及是否还涉及提供商分配或云服务商的地址。将答案与RIPEstat 宣告前缀以及BGP.tools或Hurricane Electric等独立观测结果进行比对。
接着要求提供站点模型。提供商应明确指出生产设施或云区域、恢复站点、备份位置以及网络入口。应说明站点是双活、主备还是仅备份，并解释当某一站点被隔离时会发生什么，以及恢复后如何调和客户数据。
第三，要求提供测试结果。从未迁移过流量或恢复过工作负载的弹性计划只是一个假设。客户应当看到近期的演练日期、测得的恢复时间、数据丢失结果、事件沟通样本，以及是否依赖第三方远程手工或云支持。
最后，要求提供退出证据。提供商应展示客户如何取回数据、在别处重建服务，以及在托管服务降级时如何保持关键记录可用。没有这些证据，客户就只拥有依赖性，而缺乏实际脱身之道。
证据等级
本文给予 Elysia Network 弱至中等的证据等级。该等级并非对公司品质的评判，而是对公开证据所能支撑程度的评判。此处有用的公开事实包括：AS151494、本次检查未发现当前宣告前缀且 RIPEstat 历史最后一次看到 2406:840:feda::/48 于 2026-03-15T08:00:00、本次抓取无当前前缀可用于路由源验证、针对 ASN 查询未返回 PeeringDB 网络配置文件，以及邻居证据显示 RIPEstat 邻居视图中当前无可视邻居。
这些事实展示了一个依赖候选对象，以及在当前路由情形下的运营表面，但它们还不足以构成弹性证明。公开路由的可见性可以告诉客户从何处开始测试，却无法展示每个机架、电源馈线、备件、支持人员排班或合同边界。这一差距正是托管容量采购应以证据为导向而非以品牌为导向的原因所在。
具有实用性的结论虽然狭窄但有用：记录支持的是网络学习/资源持有者足迹，而非传统的零售托管业务。任何买家在将其视为托管容量之前，都应要求提供付费服务、支持责任和连续性安排的证明。客户应将可见的网络足迹视为一张开局地图，而不是一份已经完成的保障报告。
这家公司之所以重要，是因为故障并非抽象之物。如果托管服务或网络边缘发生故障，客户可能失去可达性、管理访问、数据流动、计费控制或迁移选项。公开记录有助于命名这种依赖性，但合同和测试必须证明它如何生存下来。
谁会感受到故障
Elysia Network 最直接的用户可能是客户管理员、经销商、开发者、远程员工或依赖该托管边缘的其他网络运营商。然而，故障的影响很少止步于首先看到超时的那个人。路由撤回、存储故障或支持延迟可能导致配置开通、监控、发票访问、软件部署、客户门户、备份或原本旨在降低别处风险的迁移统统停止。
这种传播效应正是为何小型基础设施名称值得关注的原因。一组有限的可见前缀仍可能承载管理服务或面向客户的端点。一支小规模的支持团队仍可能成为短暂事件与一整天临时应对之间的分界线。一份稀疏的公开记录仍可能支撑着下游公司视为常规且看不见的服务，直到它发生故障。
对于中国的客户来说，品牌与基础设施之间的距离尤为重要。AS151494 所附带的国家或地区并不会自动告诉他们数据位于何处、使用哪条运营商路径、哪个法院或监管机构有管辖权，或者本地支持渠道能否无需等待另一家供应商即可行动。故障首先是运营层面的，然后才是法律或合同层面的。
实际的问题并非每种依赖都不好。托管服务之所以存在，是因为共享基础设施或许比许多客户自有的系统更便宜、人员更精干且更安全。实际的问题是客户是否知道它接受了哪种依赖，以及提供商能否展示恢复能力，而非仅仅描述可用性。
公开证据可能如何误导
公开网络证据之所以强大，是因为它独立于销售方案；但它也容易被过度解读。AS151494 可能可见，而客户服务实际上运行在另一张网络上；某个前缀可能被宣告，但只有某个管理组件在使用它；PeeringDB 上的配置文件可能由某个技术联系人维护，却不能反映当前的客户产品；一个休眠的 ASN 可能在其底层服务早已迁移之后许久仍保留在记录中。
最安全的解读方式是分层进行。注册证据支持身份；路由收集器证据支持某一时刻的公开可达性；路由源验证支持一种形式的路由授权；PeeringDB 支持互连发现。但这些层面无一能单独证明站点冗余、可用计算、存储持久性、客户布局、服务台权限或导出就绪度。
这种分层解读既保护 Elysia Network，也保护读者。它避免仅仅因为一家公司对设施细节保密就指责其薄弱，也避免仅因一个公开层面看起来健康就给予其不应得的弹性赞誉。公开证据应当让下一个问题变得更锐利，而非将答案变成口号。
严谨之处在于清晰地说明不确定性。当前路由就是当前路由，有效源就是有效源，邻居就是观测到的邻居，设施数量就是一个目录字段。这些术语之所以有用，正因其范围狭窄。一旦被拉伸为更宽泛的保证，读者也就丧失了证据的价值。
供应商边界决定恢复
托管服务可能在提供商自有的部分、租赁的部分或供应商运营的部分发生故障。这一区别很重要，因为修复路径会随之改变。一台提供商自有路由器可由其自己的工程师修复；一次托管空间的电力事件可能依赖楼宇人员；一次云配额或存储事件可能依赖超大规模服务商的支持渠道；一次光纤故障可能依赖运营商和民用抢修队伍。
围绕 Elysia Network 的公开记录并未揭示这些供应商边界。这就是为何买家应要求提供一份责任地图，而非泛泛的正常运行时间承诺。该地图应明确由谁控制设施、由谁控制路由器、由谁控制存储、由谁控制备份、由谁控制 DNS、由谁控制身份，以及由谁批准紧急变更。
供应商边界同时也是财务边界。一家提供商或许技术实力强劲，但与设施或上游之间的支持权益却有限；客户或许与提供商签有强力的合同条款，但对实际控制着故障组件的供应商并无直接权利。此时恢复就依赖于公开路由数据中不可见的上报关系。
最清晰的提供商会将这些边界视为服务的一部分。他们能解释哪些是内部的、哪些是外包的、哪些承诺可以传递、哪些不能，以及当供应商成为限速步骤时如何让客户知情。这种解释本身就是一种容量，因为它能减少故障期间因困惑而损失的时间。
恢复必须经过演练
从未演练过的恢复计划只不过是一种理论。演练不必大张旗鼓，可以是一次受控的客户工作负载切换、一次从备份恢复到隔离环境、一次路由撤回测试、一次支持升级演练或一次数据导出预演。重要的是，提供商测量了时间，客户看到了哪些地方会出问题。
对于 Elysia Network，公开证据无法展示演练结果，因此客户应直接索取。有用的证据是近期、具体且谦逊的：测试了什么、哪里失败了、哪里改进了、恢复用了多长时间、丢失或重放了哪些数据，以及需要客户执行哪些操作。一份光鲜的高可用性宣称，远不如一份坦诚的演练报告有用。
演练还能暴露隐性的先后顺序：备份或许恢复得快，但需要更改 DNS；路由或许切换得快，但监控仍指向旧地址；支持团队或许知道技术修复方法，但缺乏联系设施的授权；客户或许拥有数据，但没有在降级模式下操作的人员训练。这些并非极端情形，而是恢复的常态纹理。
发现这些依赖性的最佳时机是在事件发生之前。一旦客户离线，每项缺失的权限、过期的联系方式、未文档化的步骤都会变得更昂贵。演练将弹性从一种承诺转变为一种训练有素的运营习惯。
狭窄的结论更有用
对 Elysia Network 较为狭窄的结论比宽泛的结论更有力，因为它是可测试的。公开证据标识出 AS151494，给出路由和注册基线，展示哪些互连数据可见或不可见，并框定了在客户将服务视为有弹性的托管容量之前必须回答的问题。
这一结论并不要求对隐藏的资产有确定性，不要求猜测设施或虚构客户，它只是承认，现代基础设施常常将物理层隐藏于服务标签之后，而公开网络数据能够重新揭开该层的足够部分，以便严肃的买家提出知情的问题。
余下的工作属于提供商和客户。提供商必须展示当前的服务布局、路径多样性、支持权限、恢复演练和数据退出能力；客户必须决定哪些故障它可以容忍、哪些必须通过合同转移出去、哪些必须用自己的后备流程来处理。
如果这些证明能够提供，证据等级就可以提高；如果不能，公开记录则应继续作为依赖的地图，而非弹性的证书。这并非胆怯的结论，而是唯一尊重证据价值与局限的结论。
接下来关注什么
接下来要关注 Elysia Network 的具体公开变化包括：新增或撤回的前缀、AS151494 的持有人标签变更、PeeringDB 更新、路由源验证变化、新出现的可视邻居，或者列出生产位置和支持责任的网站与服务页面。每项变化都会改变对该足迹的实际解读。
买家还应留意沉默。如果配置文件停滞不变，而提供商却在营销增长，这一差距本身就构成问题。如果路由发生变化而客户通告未见，客户应当追问此次变动是否经过计划、测试并包含在协议范围内。
未来最强的证据将是公开与私有证据的结合：当前 BGP、有效的路由源授权、持续维护的互连记录、具名的设施、经过测试的恢复能力，以及数据导出演示。在汇集起这些证据之前，最稳妥的立场是保持有纪律的好奇心。
通俗易懂的运营尽职调查
对 Elysia Network 进行通俗的尽职调查测试，就是要求提供循着依赖性而来的证据，而非仅仅重复品牌的证据。客户应能够指明其购买的服务、承载该服务的地址或上游服务、托管它的位置或提供商类别、修复它的支持路径，以及允许客户离开的导出路径。若其中任何一环模糊不清，风险就只是移出了视线。
在发生实质性变更后，应重复同样的测试。新的上游、不同的设施、修订后的支持计划、新的备份目标、变更的计费平台或改名的产品，都可能在标题服务未变的情况下改变风险特征。客户往往只在发生中断时才发现这些变化，而那时实际的问题已不再是承诺过什么，而是谁能行动以及能多快行动。
一家好的提供商无需向公众暴露敏感图表就能作答。它可以分享机密的架构说明、当前责任矩阵、近期的恢复演练、状态通道设计以及数据返还流程。它还可以解释自己不会承诺什么。这种坦诚是有价值的，因为它能让客户决定哪些需要自行复制、投保、监控或接受。
对于 Elysia Network，公开网络证据提供了一张起始地图。该地图之所以有用，是因为它标识了公开边缘及其周围的缺口；但若把它当作整片领土，就毫无用处。公开记录应开启一场围绕路由可见性、站点布局、电力、转接、支持和退出的务实对话，而不应终止这场对话。