这一领域的每种工具都用一个数字回答这个问题——距上次提交的天数——而它们都在同一批项目上判断错误。一个小而完备的库三年无需改动，并非被弃置，而是已经完成。把它标记为死亡，恰恰会在最值得信赖的软件上损害记录本身的可信度。
因此沉默在这里从不构成判定。评估依据的是另一个命题：
弃置是未履行的义务，而非没有动静。
当外部的工作送达时，项目便承担了义务——等待评审的拉取请求、等待答复的问题、其所分发之物的漏洞已发布的修复。一个没有此类需求的安静项目不欠任何人，也就无从辜负任何人。而一个安静的项目若有十五个两年无人过目的拉取请求，以及一份一年前的安全公告、其补丁当周即已发布，那它并非在休息。
- 类别：活跃度（类别内权重 0%）
- 作用： 对总体评级的乘数，在最严重的状态下还附带上限
- 指标键：
abandonment
评估读取什么
已声明。 维护者自己说了。GitHub 的归档标记，或覆盖该仓库所发布全部包的注册表弃用声明。无需推断，也无需佐证——记录只是在引述其对象。
枯水期。 长期没有人类提交。刻意不采用仓库的推送时间，因为那会把依赖机器人的版本更新算作生命迹象：某些项目全年唯一的活动就是自动更新，其最后推送却显示为几天前。作者身份逐条提交读取，自动化作者被排除在外。枯水期是必要条件，本身从不构成判定。
未履行的义务。 佐证信号——拉取请求无人回应、问题无人回应、已发布的修复未被采用、发布停滞、持续集成损坏、唯一维护者缺席，或 OpenSSF Scorecard 独立判定其缺乏维护。每一项都是项目明显未在履行的职责。
保全理由。 表明仍有人在、或无人有所求的证据：维护者仍在回应、没有待答复的开放事项、一年内有发布、没有受影响的依赖。无论触发了多少义务信号，两条保全理由都会将结果止步于判定之前，因为「有人在回应」与「无人在询问」两种解读都足以完整解释沉默。
各状态的含义
| 状态 | 含义 |
|---|---|
maintained | 人类工作是近期的；无判定 |
unverified | 已采集的证据无法回答该问题 |
dormant | 安静但可解释——由保全理由维持，或本无所欠 |
abandoned | 枯水期加上未履行的义务，且无反证 |
declared | 维护者已归档项目或将其包标记为弃用 |
数据无法回答的一切均记为 unverified，对仓库毫无代价。未认证的扫描既读不到提交样本，也读不到事务队列，因而无法得出结论——这被记录为证据的缺席，而非缺席的证据。
如何解读结果
- 提示会列出其证据。 枯水期长度与义务并列呈现，使判定可被核验而非仅供采信。
- 枯水期可能只是下限。 提交样本有界；当其中完全没有人类提交时，真实间隔早于该窗口，因而以「至少」的形式报告。
- 一项判定不是对维护者的评判。 项目因寻常缘由被弃置——工作变动、兴趣转移、人会生病。记录陈述使用者会看到什么，而不解释为什么。
- 自动化在此既不拯救项目，也不谴责项目。 机器人提交被排除在枯水期计算之外，因此由依赖机器人维持温度的仓库，读起来与它实际的安静程度一致。密集的自动化若与近期人类工作并存，根本不构成信号——参见开发活跃度。
如何改善
- 回应开放的事项，或将其关闭。无人回应的队列是构成判定的最强单一因素。
- 为依赖采用已发布的安全修复，或说明其为何不适用。
- 如果项目是已完成而非被弃置，请予以声明：归档、或将其包标记为弃用，能以事实取代推断。