LERA位于判断与执行之间，在判断改变数字系统、物理世界、组织资源或公共利益之前，对其规则依据、权威、责任、风险与执行资格进行治理。

LERA架构的规范性定义、最低条件与符合性使用

基于《LERA判断治理架构白皮书》Version 2.0

本页面提供LERA判断治理架构的公开规范性摘要，包括正式定义、架构关系、最低条件、风险等级、符合等级及名称使用边界。本页面不构成独立于白皮书之外的另一套LERA定义。如本页面与《LERA判断治理架构白皮书》Version 2.0存在差异，以白皮书为准。

一、LERA规范性定义摘要

1. 什么是LERA

LERA的正式名称是：

LERA Judgment-Governance Architecture 
LERA判断治理架构

LERA是一种独立于具体模型、算法、软件和硬件实现的判断治理架构。它用于治理人类、AI、人机混合系统、多Agent系统以及未来AGI或ASI所形成的判断，在这些判断改变数字系统、物理系统、组织资源、公共利益或人类安全之前，决定：

• 判断依据什么规则成立；
• 谁拥有相应权威；
• 责任由谁承担；
• 后果是否可以接受；
• 行动是否具备执行资格；
• 执行资格在什么范围和期限内有效；
• 治理结果能否真正约束现实执行。

LERA关注的核心问题不是：

这个判断是否足够聪明？

而是：

这个判断依据什么获得改变现实的执行权？

2. 核心原则

LERA的核心原则是：

Judgment Before Execution
判断必须在获得执行权之前接受治理。

这一原则包含四项基本区分：

• 判断的形成，不等于执行资格的形成；
• 判断在逻辑上正确，不等于已经取得执行授权；
• 系统具备行动能力，不等于拥有使用该能力的权威；
• 获得过授权，不等于永久拥有执行资格。

执行资格是一种与特定判断、规则、权威、责任、风险、范围、时间和环境相绑定的治理状态。它必须是有限的、可撤销的、可验证的，并可以在条件变化时被限制、暂停、拒绝或失效。

3. LERA在系统中的位置

LERA位于推理或Agent系统与现实执行之间。其正式主路径为：

判断根节点 → LERA-J → LERA-G → ECS → 执行

这条路径将判断形成、判断治理、执行控制和现实执行分为不同职责，避免系统因为已经形成了一个看似合理的判断，就默认进入现实执行。

4. LERA的核心组成

判断根节点

Judgment Root Node

判断根节点是LERA的强制治理入口。它识别可能改变现实的行动请求，并防止Agent输出、工具调用、指令、计划或建议绕过判断治理而直接进入执行。判断根节点不形成最终判断，也不授予执行资格。

LERA-J

判断形成层

LERA-J负责将行动意图、目标、请求或建议形成一项明确、完整、可追溯和可治理的结构化判断。

其记录内容包括：

• 判断内容与判断对象；
• 关键事实与依据；
• 风险、后果和不可逆性；
• 不确定性与替代方案；
• 判断参与者；
• 权威与授权主张；
• 拟议执行范围；
• 责任关联信息。

LERA-J形成判断，但不最终验证授权有效性，不授予执行资格，也不直接触发执行。

LERA-G

判断治理层

LERA-G接收LERA-J形成的判断，对其实施独立治理。它验证：

• 判断是否完整有效；
• 权威与授权主张是否成立；
• 当前有效规则是否允许行动；
• 风险与治理强度是否匹配；
• 责任是否已经锚定；
• 行动是否超出拟议范围；
• 关键情境是否仍然持续有效。

LERA-G可以在明确范围内建立、限制、暂停、拒绝或使执行资格失效，并形成允许、附条件允许、阻断、升级或重新判断等治理结果。

ECS

Execution Control Stack，执行控制栈

ECS是LERA在真实执行侧的强制控制结构。它负责在执行边界验证LERA-G形成的治理状态，并将治理结果落实为：

• 允许；
• 阻断；
• 保持；
• 升级；
• 进入预定安全状态。

ECS不重新形成判断，也不修改LERA-G的治理决定。它必须使治理结果真正到达系统所声明控制的执行位置，例如API、数据库、支付端、控制器、机器人、工业设备或物理执行器。

WRS

World Reliability Ruleset，世界可靠性规则集

WRS提供当前有效的现实规则基础，包括法律规则、行业规则、组织规则、风险规则、角色规则、情境规则及执行规则。WRS不是主路径中的普通串行步骤，而是贯穿判断根节点、LERA-J、LERA-G和ECS的功能治理层。

RCC

Rule Change Control，规则变更控制

RCC治理WRS及其他执行相关规则的提出、批准、修改、生效、发布、撤销和回滚。RCC防止被治理系统自行削弱、改变或绕过约束自身的规则。它是贯穿性的规则治理机制，不是每项判断都必须依次经过的运行步骤。

JFIR

Judgment-First Incident Review，判断优先事故审查

JFIR用于事故或异常执行发生后的复核。它从判断开始重建完整链条，检查判断如何形成、经过了何种治理、由谁授权、使用了哪个规则版本、执行资格为何成立，以及责任应当锚定于何处。JFIR属于事后复核机制，不属于实时执行主路径。

5. LERA适用于哪些场景

LERA不是只适用于高风险或零容错系统。只要系统输出可能进一步参与行动、调用工具、修改数据、移动资金、控制设备或产生其他现实后果，LERA原则就具有适用性。治理强度应当由执行后果决定：

• L0 — Ordinary Judgment：低后果、可逆、常规判断，可以采用快速自动治理。
• L1 — Assistive Judgment：AI提供辅助，但人类仍保持实质判断和控制。
• L2 — Structured Judgment：判断将产生显著现实后果，需要明确责任、规则验证、独立治理和非形式化的人类参与。
• L3 — Irreversible Judgment：可能产生不可逆、系统性或重大公共后果，需要最高等级治理。

低风险场景可以采用轻量化规则、快速路径和自动治理；高风险场景则需要更强的独立性、不可绕过性、默认阻断、责任锚定、连续执行控制和外部验证。因此：

LERA具有普适性，但其结构性价值和必要性在高后果场景中最为突出。

6. 责任锚定

LERA要求在高后果判断进入执行之前建立与后果相匹配的责任关系。

• 责任锚定需要识别：
• 谁对判断内容负责；
• 谁对治理过程负责；
• 谁授予或验证授权；
• 谁控制执行端；
• 谁对规则及其变更负责；
• 哪个组织或法律实体承担最终责任；
• 发生错误或事故后，责任链能否被重建。
• 责任锚定不等于要求某一个人承担全部责任。

复杂系统可以存在多层责任，但责任不能因为系统复杂、AI参与或自动化程度提高而消失。模型、算法或系统本身也不能被用作模糊、吸收或转移现实责任的替代物。单纯要求某个人点击“批准”，并不自动构成有效责任锚定。权威、信息、能力、控制力与所承担的责任必须相互匹配。

7. LERA不是什么

LERA不是：

• 某一个AI模型、Agent、算法、软件产品或硬件设备；
• 普通决策引擎、评分模型或政策过滤器；
• 仅仅增加一次人工点击的Human-in-the-Loop机制；
• 保证判断永远正确的系统；
• 对所有AI、AGI或ASI风险的充分解决方案；
• 对绝对安全或绝对不可绕过的承诺；
• 法律、监管或行业认证的替代物；
• 要求所有场景采用同一种工程实现的统一技术平台。

LERA允许模型、算法、自动化规则、人工审批、软件Gate、边缘硬件、可信执行环境和专用芯片参与工程实现。

但任何单一组件、一次审批或一个模型调用，都不能自动等同于完整的LERA判断治理架构。

二、LERA最低条件框架

《LERA判断治理架构白皮书》Version 2.0提出十一项最低条件，用于评价系统是否具备LERA判断治理能力。

这些条件不要求所有系统以相同强度部署。具体要求由判断风险、自动执行范围、系统自主性、现实后果、可绕过能力和目标符合等级共同决定。

1. LERA基础条件集

任何声称在某一范围内采用LERA的系统，至少应具备以下五项基础条件：

• 判断—执行分离；
• 声明范围内的强制治理入口；
• 可验证规则基础；
• 风险比例治理；
• 可验证治理记录。

缺少这些基础条件的普通自动化系统，不应仅通过采用LERA术语而声称使用了LERA。

2. 十一项最低条件

LERA-MC-01：判断—执行分离条件
判断的形成不得自动产生现实执行权。

LERA-MC-02：强制治理入口条件
被声明纳入LERA范围的行动必须进入不可省略的判断治理入口。

LERA-MC-03：独立治理权威条件
被治理主体不能成为判断自身是否应当执行的唯一权威。

LERA-MC-04：可验证规则基础条件
系统必须能够说明行动依据什么规则被允许、限制、升级或阻断。

LERA-MC-05：规则变更受控条件
影响判断治理和现实执行的规则变化必须受到与风险相匹配的控制。

LERA-MC-06：不可绕过条件
被治理主体不得通过备用接口、权限扩张、多Agent委托、动作拆分或其他路径实现已经被阻断的相同或等效后果。

LERA-MC-07：默认阻断治理条件
在适用治理条件尚未成立时，相关现实执行应保持阻断；治理服务、规则状态、通信或执行验证失败时，应采取Fail-Closed运行。

LERA-MC-08：风险比例治理条件
治理组合、强度、独立性和验证深度必须与现实后果相匹配。

LERA-MC-09：执行前责任锚定条件
在高后果判断进入执行前，必须建立与后果相匹配的责任关系。

LERA-MC-10：连续执行控制条件
治理结果必须持续到系统所声明控制的真实执行位置。

LERA-MC-11：可验证治理记录条件
系统必须保留足以证明判断治理在执行前真实发生的记录。

三、LERA符合等级

LERA使用C0—C4描述系统的判断治理能力，C代表Conformance。

C0—C4与L0—L3不同：L0—L3描述一项判断进入执行后的后果等级；C0—C4描述一个系统已经实现的治理能力。

C0 — Not Conformant

系统没有建立基本的LERA判断治理关系。

C0系统不能声称采用LERA。

C1 — LERA Foundational

适用于L0判断、低风险可逆场景、单一软件边界、小范围试点和普通辅助型Agent。

C1至少需要满足LERA五项基础条件。

C2 — LERA Scoped Operational

适用于L1判断、企业Agent、内容发布、一般数据操作、低金额交易及受限软件自动化。

C2除基础条件外，通常还需要功能性独立治理、基础规则变更控制、主要路径不可绕过、默认阻断、明确责任主体、主要执行链控制和关联治理记录。

C2符合声明必须明确未覆盖的系统边界。

C3 — LERA High-Consequence Operational

面向L2显著现实后果。

C3要求十一项最低条件形成完整运行链，并具备完整规则环境、正式规则变更控制、执行前责任锚定、连续控制到真实执行端、JFIR能力及基础对抗性测试。

C4 — LERA High-Assurance Control

面向L3判断、关键基础设施、生命安全系统、战略金融与资源、高自主机器人以及AGI或ASI级现实执行环境。

C4要求十一项条件全部以高保障方式实现，并增加多层治理独立性、严格Fail-Closed、对抗性不可绕过验证、多Agent与长时序测试、可信执行锚点、独立第三方评价和定期重新评价。

C4不表示绝对安全。它表示系统已经在明确范围内，以高保障方式实现并持续验证LERA完整条件体系。

建议的风险—符合等级关系为：

• L0：C1；
• L1：C1或C2；
• L2：C3；
• L3：C4。

这一关系不是机械对应。高等级系统可以治理较低风险判断，但低等级系统不能声称具备治理高风险判断的能力。

四、LERA名称与符合性表述

1. 可以使用的表述

LERA-Informed

系统设计参考了LERA的部分原则，但尚未完成正式符合性评价。

LERA-Aligned

系统在明确范围内采用了LERA基础关系，但尚未获得独立认证。

LERA-Conformant

系统经过正式评价，在明确范围内达到指定的C等级。

任何此类声明必须同时说明系统、版本、场景、风险范围、执行边界、符合等级、评价证据和排除范围。

LERA-Certified

仅适用于由获得认可的独立主体，按照已经生效的LERA认证程序完成正式认证的系统。

在正式认证计划建立并公布之前，不得以可能造成官方认证或授权误解的方式使用“LERA-Certified”。

2. 符合声明必须包含的内容

任何LERA符合声明至少应说明：

• 系统及版本；
• 使用场景；
• 判断风险范围；
• 现实执行边界；
• 符合等级；
• 适用条件；
• 评价证据；
• 排除范围；
• 评价日期；
• 有效期限；
• 重新评价触发条件。

推荐表述：

本系统在指定企业数据库写入场景中，针对L0—L1判断达到LERA C2符合等级。生产管理员直连接口不在本次评价范围内。

不推荐表述：

本企业全面符合LERA。

或：

本系统符合LERA，因此能够控制所有AI风险。

3. 不得声称采用或符合LERA的情形

存在以下任一情形时，系统不得声称达到LERA符合等级：

• 判断结果未经治理便直接进入现实执行；
• 没有明确的判断治理入口；
• 被治理Agent能够自行批准、关闭或降低治理；
• 不存在可验证的规则来源和规则状态；
• Agent能够自行修改约束自身的规则；
• 主要执行路径可以被轻易绕过；
• 没有可识别的责任主体或组织责任；
• 治理结果没有到达真实执行位置；
• 无法提供执行前治理的可验证记录；
• 仅使用某个LERA Pattern、术语或局部组件，却把它表述为完整系统符合；
• 在没有正式认证的情况下使用“LERA-Certified”。

4. 关于自动化判断与自动执行

LERA不禁止AI形成判断，也不禁止风险适配的自动治理或自动执行。L0和部分L1场景可以采用预先批准的快速路径、自动规则验证和自动执行控制。但必须满足：

• 判断与执行在结构上分离；
• 行动必须经过声明范围内的治理入口；
• 执行依据来自当前有效规则；
• 治理不能完全依赖被治理Agent的自我判断；
• 执行资格必须在明确范围内成立；
• 真实执行端必须验证治理状态；
• 条件不明、验证失败或资格失效时必须阻断或进入安全状态。

因此，LERA禁止的不是“自动化”，而是：

未经治理的自动执行。

5. 关于组件和模块引用

引用LERA-J、LERA-G、WRS、RCC、ECS或JFIR时，必须保持其在白皮书2.0中的职责边界。特别是：

• LERA-J形成判断，但不授予执行资格；
• LERA-G治理判断并形成执行资格状态；
• WRS提供当前有效规则；
• RCC治理规则变化；
• ECS验证并强制落实治理结果；
• JFIR用于事后复核；
• Execution Eligibility、Authorization和Responsibility Anchoring是治理状态或治理职能，不是独立技术模块。

一个组件可以被表述为支持某些LERA条件，但组件能力不能自动等同于整个系统达到LERA符合等级。

五、标准、认证与法律边界

《LERA判断治理架构白皮书》Version 2.0提出的最低条件、风险等级、符合等级、评价方法和认证机制，是LERA标准化与符合性评价体系的基础方案。现阶段，它们不应被理解为：

• 已经生效的国家标准；
• 已经生效的国际标准；
• 法定认证制度；
• 政府或监管机构批准；
• 对适用法律法规的合规证明；
• 对系统绝对安全的保证。

LERA不替代模型对齐、网络安全、功能安全、法律制度、组织治理、行业标准、专业判断或人类监督。符合LERA表示系统在明确范围内具备相应的判断治理能力，不表示该系统已经满足所有法律、监管、技术或行业要求。

六、规范性来源与名称说明

本页面所称LERA，专指：

LERA Judgment-Governance Architecture
LERA判断治理架构

“LERA”一词最早来源于Linda Energy Reliability Architecture的缩写，该缩写形成的名称LERA可能在其他行业、组织或研究领域中存在既有用法，但与本页面所述架构无关。规范性来源：

Jing (Linda) Liu. (2026).《LERA判断治理架构白皮书》（Version 2.0，中文版本）. Zenodo.
https://doi.org/10.5281/zenodo.21442713

更多公共研究与架构资料：

https://lera.institute
https://lera.systems

本页面为公开定义与符合性使用参考，不构成法律、监管、投资或特定工程实施意见。本架构涉及的部分方法和技术方案已进入专利申请程序。公开披露不构成任何知识产权的明示或默示许可。