一个仓库不止于其在 GitHub 上的存在：大多数可复用软件经由软件包注册表交付，而注册表持有 GitHub 无法展示的采用与维护证据—— 真实的下载量、发布新近度、弃用状态。inspect.software 解析仓库所发布的软件包，并将注册表数据汇入两项指标： 生态采用与 软件包维护。
目前读取的注册表
| 生态系统 | 注册表 | 采用数据 |
|---|---|---|
| JavaScript / Node | npm | 月度下载量 |
| Python | PyPI | 月度下载量 |
| PHP | Packagist | 月度下载量 |
| Rust | crates.io | 月度下载量 |
| Ruby | RubyGems | 历史累计下载量 |
| Elixir / Erlang | Hex | 下载数据 |
| .NET | NuGet | 历史累计下载量 |
| Go | Go module proxy | 无公开下载计数 |
| Java / JVM | Maven Central | 无公开软件包下载计数 |
全部九个注册表都向软件包维护贡献已发布软件包的事实——最新版本、发布新近度、版本历史、弃用状态。当注册表不发布月度下载数字时（RubyGems、NuGet），采用指标回退到 历史累计下载量——注册表实际提供哪一项就用哪一项，因此没有任何生态在结构上处于劣势。Go 模块代理与 Maven Central 不发布任何形式的下载统计。对 Go 而言，维护证据因此成为唯一信号；对 Maven Central，deps.dev 发布的被依赖项目数提供了可比的采用度量。
NuGet 通过其官方目录源（catalog feed）增量发现。其公开搜索元数据提供历史累计下载量，用于目录收录阈值。Maven Central 通过官方 Maven Central Indexer 增量发现。Central 不发布软件包下载计数，因此收录资格改为依赖 deps.dev 的被依赖项目数以及声明的 GitHub 源码地址；达到被依赖数阈值的软件包与其他生态一样自动进入队列。
Go 模块发现
目录工作进程还读取官方公开的 Go Module Index 以发现新的稳定发布版本。该索引公布模块路径、版本与时间戳，但不含下载/采用计数。因此自动收录的 Go 候选需要直接的 github.com/owner/repo 模块路径，以及最近 730 天内发布的稳定版本；它们按发布新鲜度排序，而非依据虚构的下载数字。常规的低优先级目录队列与扫描仍会在仓库进入公开记录之前对其进行核验。
声明的依赖
独立于软件包发布之外，检验过程会解析跨生态的依赖清单——npm、 PyPI、Packagist、crates.io、Go、Maven、RubyGems、NuGet 与 Hex—— 并在每份报告中记录声明的直接依赖列表。将这些依赖对照注册表与漏洞数据库进行解析（新鲜度、已知 CVE）已列入公开的方法论路线图。
全部依赖
在直接依赖列表之外，检验过程还从 GitHub 的依赖图中记录仓库的 完整解析依赖集——直接加间接（传递）依赖；只要仓库提交了锁定文件，依赖图即覆盖传递闭包。报告分别列出直接与间接依赖的数量，并注明解析集的来源。这项采集尽力而为：当依赖图不可用时，报告会明确说明，检验的其余所有环节不受影响地继续进行。
不发布软件包的仓库
应用、基础设施仓库与文档项目往往不向任何注册表发布内容。对它们而言，两项依赖注册表的指标为 null：从其类别中排除并重新归一化权重，绝不按零计入。不发布软件包的仓库纯粹依据其其他证据度量—— 缺失数据规则参见健康指数。
软件包与仓库的匹配
只有当注册表条目可验证地指回某个仓库时，该软件包才会计入这个仓库的报告。声称源自其他仓库的软件包会列入报告，但被标记并排除在计算之外——以防采用数字被借用或伪造。
多生态、多语言仓库
一个代码库完全可以正当地同时存在于多个生态——一个 Rust 核心带 Python 绑定与 npm 封装的项目，会从同一个仓库发布到 crates.io、 PyPI 与 npm。评分对此已有稳妥处理：下载量在每个经核验的软件包间求和。而在公开记录列出仓库生态之处——目录卡片、筛选器、报告标签——顺序反映的是证据强度，而非字母表：拥有经核验已发布软件包的生态排在前面，按下载量排序；仅见于依赖清单的生态随后。指向其他源仓库的软件包绝不会领衔列表。
语言遵循同样的纪律。仓库所展示的语言，是按代码量占比至少 10% 的那些语言，从大到小排列——因此 CI 脚本与生成的标记语言不会冒充项目语言，而真正的双语代码库会如实呈现。目录卡片每个仓库最多显示三个生态与三种语言。