译文
译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。
规范性用语与要求卡片¶
ASILO 0.1 和 MILPA 0.1 共用的规则。
用途¶
只有知道什么约束、约束谁、何时约束、如何检查，一条规则才能被遵守、审计或讨论。本页提出词汇表和最小要求卡片，供本站中 ASILO 和 MILPA 的要求使用。
关键词¶
本仓库将 BCP 14 的准则（RFC 2119 和 RFC 8174）改编为西班牙语。它并不声称符合这些 RFC，因为它们定义的是英语词汇。所提出的对应关系如下：
| 本站用词 | 对应的 BCP 14 | 含义 |
|---|---|---|
| DEBE（中文：必须） | MUST / REQUIRED / SHALL | 在该要求的范围内，没有替代方案的义务。 |
| NO DEBE（中文：不得） | MUST NOT / SHALL NOT | 在该范围内，没有替代方案的禁止。 |
| DEBERÍA（中文：应当） | SHOULD / RECOMMENDED | 期望得到遵守；偏离须登记理由并接受风险。 |
| NO DEBERÍA（中文：不应当） | SHOULD NOT / NOT RECOMMENDED | 期望避免；若要这样做，须登记理由并接受风险。 |
| PUEDE（中文：可以） | MAY / OPTIONAL | 允许的选项；不产生义务。 |
依照 RFC 8174 的规则，这些词仅在以大写形式出现时才具有规范含义（西班牙语原文中为大写；中文译文中对应加粗的“必须”“不得”“应当”“不应当”“可以”）。以小写形式出现时，保持其普通含义。
只要某项要求处于 proposed 状态，其中的“必须”描述的是它被接受后将承担的义务；目前它不约束任何人。 任何审计都不能宣称某项未被接受的要求未得到满足。
状态¶
| 状态 | 含义 | 由谁指定 |
|---|---|---|
draft |
文本在起草中；可能不经通知而变化。 | 作者 |
proposed |
已完整起草、可追溯、可供决策。不具约束力。 | 作者，附来源 |
accepted |
自某个明确的版本起，在其范围内具有约束力。 | 仅限人类负责人，附已登记的决定 |
deprecated |
已被取代或撤销；为可追溯而保留。 | 人类负责人 |
historical |
说明来源；不具治理效力。 | 人类负责人或策展人 |
来源文档中的标签（例如“canon”）不等同于 accepted：权威由负责人登记在案的决定来确定，而不是由标签来确定。
最小要求卡片¶
每项要求登记以下字段：
| 字段 | 包含什么 |
|---|---|
| ID | 稳定的标识符（ASILO-R-NNN、MILPA-R-NNN）。即使要求被撤销也不会重复使用。 |
| 状态 | 上述状态之一。 |
| 类别 | 与技术无关的原则、与技术无关的要求、技术应用配置或示例。 |
| 问题 | 它预防什么故障或损害。 |
| 范围 | 所涉及的系统、工件或活动。 |
| 责任人 | 对履行负责的人类角色。 |
| 适用条件 | 何时生效；在此之外不适用。 |
| 可验证的表述 | 规则本身，关键词使用大写。 |
| 预期证据 | 可用于检查是否遵守的工件。 |
| 例外 | 如何授权偏离，以及须登记什么。 |
| 残余风险 | 即使遵守了该要求，它仍然无法避免的内容。 |
| 来源 | 原始来源及其修订版本，以及带版本的外部来源。保存在方法的登记中；公开页面可以省略。 |
| 待决事项 | 在接受之前须由一个人决定的内容。接受之后称为未来决定，收录留待其他版本处理的开放事项。 |
原则、应用配置与示例¶
- 与技术无关的原则： 无论语言、平台或模型提供方如何都成立。
- 与技术无关的要求： 由原则推导出的可验证义务；不指名任何技术。
- 技术应用配置： 针对某个情境（例如 TypeScript 或某类项目）对要求的选取与具体化。应用配置不修改基础方法。
- 示例： 用于说明；绝不产生义务。
如果某个来源只描述了一个应用配置，提取出的规则就留在该应用配置中。要将其转为与技术无关的要求，须说明为什么它在该情境之外也适用。
例外¶
对已被接受的要求的例外，须登记人类负责人、理由、范围、期限、风险、回滚和复审日期。