LERA Architecture—An Architecture for Governing How Judgment Enters Real-World Execution

LERA sits between judgment and execution. Before a judgment changes a digital system, the physical world, organizational resources, or the public interest, LERA governs its rule basis, authority, responsibility, risk, and execution eligibility.

Normative Definition, Minimum Conditions, and Conformance Use of the LERA Architecture

Based on the LERA Judgment-Governance Architecture White Paper, Version 2.0

This page provides a public normative summary of the LERA Judgment-Governance Architecture, including its formal definition, architectural relationships, minimum conditions, risk levels, conformance levels, and boundaries for use of the LERA name. This page does not establish a separate definition of LERA independent of the White Paper. If any discrepancy exists between this page and the LERA Judgment-Governance Architecture White Paper, Version 2.0, the White Paper shall prevail.

I. Summary of the Normative Definition of LERA

1. What Is LERA?

The formal name of LERA is:

LERA Judgment-Governance Architecture

LERA is a judgment-governance architecture independent of any specific model, algorithm, software implementation, or hardware implementation.

It governs judgments formed by humans, AI systems, human–AI hybrid systems, multi-agent systems, and future AGI or ASI systems. Before such judgments change digital systems, physical systems, organizational resources, the public interest, or human safety, LERA determines:

• the rules on which a judgment is based;
• who holds the relevant authority;
• who bears responsibility;
• whether the consequences are acceptable;
• whether the action has execution eligibility;
• the scope and duration for which that execution eligibility remains valid; and
• whether the governance outcome can effectively constrain real-world execution.

The core question addressed by LERA is not:

Is this judgment intelligent enough?

It is:

On what basis does this judgment obtain the authority to change reality?

2. Core Principle

The core principle of LERA is:

Judgment Before Execution
Judgment must be governed before it is granted execution authority.

This principle contains four fundamental distinctions:

• the formation of a judgment is not the formation of execution eligibility;
• a logically correct judgment is not necessarily an authorized judgment;
• possessing the capability to act is not the same as possessing the authority to use that capability; and
• having been authorized in the past does not create permanent execution eligibility.

Execution eligibility is a governance state bound to a specific judgment, rule set, authority, responsibility, risk, scope, time period, and operating environment. It must be limited, revocable, and verifiable, and it must be capable of being restricted, suspended, denied, or invalidated when conditions change.

3. LERA’s Position Within a System

LERA sits between a reasoning or agent system and real-world execution. Its formal primary path is:

Judgment Root Node → LERA-J → LERA-G → ECS → Execution

This path separates judgment formation, judgment governance, execution control, and real-world execution into distinct responsibilities. It prevents a system from proceeding directly to real-world execution merely because it has formed a seemingly reasonable judgment.

4. Core Components of LERA

Judgment Root Node

The Judgment Root Node is LERA’s mandatory governance entry point. It identifies action requests that may change reality and prevents agent outputs, tool calls, instructions, plans, or recommendations from bypassing judgment governance and proceeding directly to execution. The Judgment Root Node does not form the final judgment and does not grant execution eligibility.

LERA-J

Judgment Formation Layer

LERA-J transforms an action intent, goal, request, or recommendation into a clear, complete, traceable, and governable structured judgment.

Its records include:

• the substance and object of the judgment;
• key facts and supporting grounds;
• risks, consequences, and irreversibility;
• uncertainty and alternatives;
• participants in the judgment process;
• claims of authority and authorization;
• the proposed scope of execution; and
• information relevant to responsibility.

LERA-J forms the judgment, but it does not finally validate authorization, grant execution eligibility, or directly trigger execution.

LERA-G

Judgment-Governance Layer

LERA-G receives the judgment formed by LERA-J and subjects it to independent governance.

It verifies:

• whether the judgment is complete and valid;
• whether claims of authority and authorization are valid;
• whether the action is permitted under the currently effective rules;
• whether the intensity of governance is proportionate to the risk;
• whether responsibility has been anchored;
• whether the action exceeds the proposed scope; and
• whether critical contextual conditions remain valid.

Within a clearly defined scope, LERA-G may establish, restrict, suspend, deny, or invalidate execution eligibility. It may produce governance outcomes including permission, conditional permission, blocking, escalation, or a requirement for a new judgment.

ECS

Execution Control Stack

ECS is LERA’s mandatory control structure on the real execution side. At the execution boundary, it verifies the governance state established by LERA-G and enforces the governance outcome as one of the following:

• permit;
• block;
• hold;
• escalate; or
• enter a predetermined safe state.

ECS does not reformulate the judgment or modify LERA-G’s governance decision. It must ensure that the governance outcome reaches the actual execution point within the system’s declared control boundary, such as an API, database, payment endpoint, controller, robot, industrial device, or physical actuator.

WRS

World Reliability Ruleset

WRS provides the currently effective real-world rule basis, including legal rules, industry rules, organizational rules, risk rules, role rules, contextual rules, and execution rules. WRS is not an ordinary sequential step in the primary path. It is a functional governance layer that operates across the Judgment Root Node, LERA-J, LERA-G, and ECS.

RCC

Rule Change Control

RCC governs the proposal, approval, amendment, entry into force, publication, withdrawal, and rollback of WRS and other execution-related rules. RCC prevents a governed system from weakening, changing, or bypassing the rules that constrain it. It is a cross-cutting rule-governance mechanism, not an operational step through which every judgment must sequentially pass.

JFIR

Judgment-First Incident Review

JFIR is used to review incidents or abnormal executions after they occur. Beginning with the judgment, it reconstructs the full chain and examines how the judgment was formed, what governance it underwent, who authorized it, which rule version was applied, why execution eligibility was established, and where responsibility should be anchored.

JFIR is a post-incident review mechanism. It is not part of the real-time primary execution path.

5. Where Does LERA Apply?

LERA is not limited to high-risk or zero-tolerance systems.

The principles of LERA are applicable whenever system output may subsequently participate in action, call tools, modify data, move funds, control equipment, or produce other real-world consequences.

The intensity of governance should be determined by the consequences of execution:

• L0 — Ordinary Judgment: Low-consequence, reversible, routine judgments that may use rapid automated governance.
• L1 — Assistive Judgment: AI provides assistance, while humans retain substantive judgment and control.
• L2 — Structured Judgment: The judgment may produce significant real-world consequences and therefore requires explicit responsibility, rule verification, independent governance, and substantive human involvement rather than merely formal approval.
• L3 — Irreversible Judgment: The judgment may produce irreversible, systemic, or major public consequences and therefore requires the highest level of governance.

Low-risk scenarios may use lightweight rules, fast paths, and automated governance. High-risk scenarios require stronger independence, non-bypassability, default blocking, responsibility anchoring, continuous execution control, and external verification. Therefore:

LERA is universally applicable, but its structural value and necessity are most evident in high-consequence scenarios.

6. Responsibility Anchoring

LERA requires responsibility relationships proportionate to the consequences to be established before a high-consequence judgment enters execution.

Responsibility anchoring requires identification of:

• who is responsible for the substance of the judgment;
• who is responsible for the governance process;
• who grants or validates authorization;
• who controls the execution endpoint;
• who is responsible for the rules and changes to those rules;
• which organization or legal entity bears ultimate responsibility; and
• whether the responsibility chain can be reconstructed after an error or incident.
• Responsibility anchoring does not mean that one individual must bear all responsibility.

A complex system may involve multiple layers of responsibility, but responsibility cannot disappear merely because the system is complex, AI is involved, or automation has increased. A model, algorithm, or system cannot be used as a substitute that obscures, absorbs, or transfers real-world responsibility. Merely requiring someone to click “approve” does not automatically constitute valid responsibility anchoring. Authority, information, competence, control, and the responsibility assumed must be mutually aligned.

7. What LERA Is Not

LERA is not:

• a particular AI model, agent, algorithm, software product, or hardware device;
• an ordinary decision engine, scoring model, or policy filter;
• a Human-in-the-Loop mechanism consisting only of an additional human click;
• a system that guarantees judgments will always be correct;
• a sufficient solution to all AI, AGI, or ASI risks;
• a promise of absolute safety or absolute non-bypassability;
• a substitute for legal, regulatory, or industry certification; or
• a unified technical platform requiring the same engineering implementation in every scenario.

LERA permits models, algorithms, automated rules, human approval, software gates, edge hardware, trusted execution environments, and dedicated chips to participate in its engineering implementation. However, no single component, one-time approval, or individual model call is automatically equivalent to a complete LERA Judgment-Governance Architecture.

II. LERA Minimum Conditions Framework

The LERA Judgment-Governance Architecture White Paper, Version 2.0, establishes eleven minimum conditions for evaluating whether a system possesses LERA judgment-governance capability. These conditions do not require every system to deploy governance at the same level of intensity. Specific requirements depend on judgment risk, the scope of automated execution, system autonomy, real-world consequences, bypass capability, and the target conformance level.

1. LERA Foundational Condition Set

Any system claiming to adopt LERA within a defined scope must satisfy at least the following five foundational conditions:

• separation of judgment and execution;
• a mandatory governance entry point within the declared scope;
• a verifiable rule basis;
• risk-proportionate governance; and
• verifiable governance records.

An ordinary automated system that lacks these foundational conditions must not claim to use LERA merely because it adopts LERA terminology.

2. The Eleven Minimum Conditions

LERA-MC-01: Judgment–Execution Separation Condition

The formation of a judgment must not automatically create authority for real-world execution.

LERA-MC-02: Mandatory Governance Entry Condition

Every action declared to be within the scope of LERA must pass through a judgment-governance entry point that cannot be omitted.

LERA-MC-03: Independent Governance Authority Condition

The governed subject must not be the sole authority determining whether its own judgment should be executed.

LERA-MC-04: Verifiable Rule Basis Condition

The system must be able to explain the rules under which an action is permitted, restricted, escalated, or blocked.

LERA-MC-05: Controlled Rule Change Condition

Changes to rules that affect judgment governance and real-world execution must be subject to controls proportionate to the risk.

LERA-MC-06: Non-Bypassability Condition

The governed subject must not be able to achieve the same or an equivalent outcome that has already been blocked by using an alternative interface, expanding its permissions, delegating to multiple agents, splitting the action into smaller steps, or using any other path.

LERA-MC-07: Default-Block Governance Condition

Relevant real-world execution must remain blocked until the applicable governance conditions have been satisfied. If the governance service, rule state, communication channel, or execution verification fails, the system must operate Fail-Closed.

LERA-MC-08: Risk-Proportionate Governance Condition

The governance configuration, intensity, independence, and depth of verification must be proportionate to the real-world consequences.

LERA-MC-09: Pre-Execution Responsibility Anchoring Condition

Before a high-consequence judgment enters execution, responsibility relationships proportionate to the consequences must be established.

LERA-MC-10: Continuous Execution Control Condition

The governance outcome must extend continuously to the real execution point within the system’s declared control boundary.

LERA-MC-11: Verifiable Governance Record Condition

The system must retain records sufficient to demonstrate that judgment governance actually occurred before execution.

III. LERA Conformance Levels

LERA uses C0–C4 to describe a system’s judgment-governance capability. “C” stands for Conformance.

C0–C4 are distinct from L0–L3:

L0–L3 describe the consequence level of a judgment entering execution.

C0–C4 describe the governance capability a system has implemented.

C0 — Not Conformant

The system has not established the basic judgment-governance relationships required by LERA.

A C0 system cannot claim to have adopted LERA.

C1 — LERA Foundational

C1 is suitable for L0 judgments, low-risk reversible scenarios, a single software boundary, limited pilots, and ordinary assistive agents.

C1 requires, at minimum, satisfaction of the five LERA foundational conditions.

C2 — LERA Scoped Operational

C2 is suitable for L1 judgments, enterprise agents, content publication, ordinary data operations, low-value transactions, and constrained software automation.

In addition to the foundational conditions, C2 generally requires functionally independent governance, basic rule change control, non-bypassability of primary paths, default blocking, clearly identified responsible entities, control over the primary execution chain, and linked governance records.

A C2 conformance claim must explicitly identify system boundaries that are not covered.

C3 — LERA High-Consequence Operational

C3 addresses L2 judgments with significant real-world consequences.

C3 requires the eleven minimum conditions to form a complete operational chain. It also requires a complete rule environment, formal rule change control, pre-execution responsibility anchoring, continuous control through to the real execution endpoint, JFIR capability, and foundational adversarial testing.

C4 — LERA High-Assurance Control

C4 addresses L3 judgments, critical infrastructure, life-safety systems, strategic finance and resources, highly autonomous robotics, and AGI- or ASI-level real-world execution environments.

C4 requires all eleven conditions to be implemented with high assurance. It further requires multilayer governance independence, strict Fail-Closed operation, adversarial verification of non-bypassability, multi-agent and long-horizon testing, trusted execution anchors, independent third-party evaluation, and periodic re-evaluation.

C4 does not indicate absolute safety. It indicates that, within a clearly defined scope, the system has implemented the complete LERA condition set with high assurance and continues to verify it.

The recommended relationship between risk and conformance levels is:

• L0: C1;
• L1: C1 or C2;
• L2: C3; and
• L3: C4.

This relationship is not a mechanical one-to-one mapping. A higher-conformance system may govern lower-risk judgments, but a lower-conformance system cannot claim the capability to govern higher-risk judgments.

IV. Use of the LERA Name and Conformance Claims

1. Permitted Descriptions

LERA-Informed

The system design references some LERA principles but has not completed a formal conformance evaluation.

LERA-Aligned

The system adopts LERA’s foundational relationships within a clearly defined scope but has not received independent certification.

LERA-Conformant

The system has undergone formal evaluation and achieved a specified C level within a clearly defined scope.

Any such claim must identify the system, version, scenario, risk scope, execution boundary, conformance level, evaluation evidence, and exclusions.

LERA-Certified

This term applies only to a system formally certified by a recognized independent body under an effective LERA certification program.

Until a formal certification program has been established and published, “LERA-Certified” must not be used in any manner that could create the false impression of official certification or authorization.

2. Required Content of a Conformance Claim

Every LERA conformance claim must state, at minimum:

• the system and version;
• the use scenario;
• the judgment risk scope;
• the real-world execution boundary;
• the conformance level;
• applicable conditions;
• evaluation evidence;
• exclusions;
• the evaluation date;
• the period of validity; and
• triggers for re-evaluation.

Recommended wording:

Within the specified enterprise database write scenario, this system achieves LERA C2 conformance for L0–L1 judgments. Direct interfaces used by production administrators are outside the scope of this evaluation.

Not recommended:

Our entire organization conforms to LERA.

or:

This system conforms to LERA and can therefore control all AI risks.

3. Circumstances in Which a System Must Not Claim to Adopt or Conform to LERA

A system must not claim to have achieved a LERA conformance level if any of the following applies:

• a judgment proceeds directly to real-world execution without governance;
• no clearly defined judgment-governance entry point exists;
• the governed agent can approve itself or disable or reduce governance;
• no verifiable rule source or rule state exists;
• the agent can modify the rules that constrain it;
• primary execution paths can be easily bypassed;
• no identifiable responsible individual, entity, or organization exists;
• the governance outcome does not reach the real execution point;
• the system cannot provide verifiable records of pre-execution governance;
• the system uses only a LERA Pattern, term, or local component but represents this as full-system conformance; or
• “LERA-Certified” is used in the absence of formal certification.

4. Automated Judgment and Automated Execution

LERA does not prohibit AI from forming judgments, nor does it prohibit risk-adapted automated governance or automated execution.

L0 and some L1 scenarios may use pre-approved fast paths, automated rule verification, and automated execution control. However, the following conditions must be met:

• judgment and execution must be structurally separated;
• the action must pass through the governance entry point within the declared scope;
• the basis for execution must come from currently effective rules;
• governance must not depend entirely on the governed agent’s self-assessment;
• execution eligibility must be valid within a clearly defined scope;
• the real execution endpoint must verify the governance state; and
• if conditions are unclear, verification fails, or eligibility becomes invalid, execution must be blocked or the system must enter a safe state.

Therefore, LERA does not prohibit automation. It prohibits:

Ungoverned automated execution.

5. References to Components and Modules

Any reference to LERA-J, LERA-G, WRS, RCC, ECS, or JFIR must preserve the boundaries of responsibility established in the White Paper, Version 2.0.

In particular:

• LERA-J forms the judgment but does not grant execution eligibility;
• LERA-G governs the judgment and establishes the execution-eligibility state;
• WRS provides the currently effective rules;
• RCC governs changes to rules;
• ECS verifies and enforces the governance outcome;
• JFIR is used for post-incident review; and
• Execution Eligibility, Authorization, and Responsibility Anchoring are governance states or governance functions, not standalone technical modules.

A component may be described as supporting specific LERA conditions, but the capability of a component is not automatically equivalent to the entire system achieving a LERA conformance level.

V. Boundaries Relating to Standards, Certification, and Law

The minimum conditions, risk levels, conformance levels, evaluation methods, and certification mechanisms proposed in the LERA Judgment-Governance Architecture White Paper, Version 2.0, form the foundational framework for LERA standardization and conformity assessment.

At this stage, they must not be understood as:

• an effective national standard;
• an effective international standard;
• a statutory certification regime;
• approval by a government or regulatory authority;
• proof of compliance with applicable laws and regulations; or
• a guarantee of absolute system safety.

LERA does not replace model alignment, cybersecurity, functional safety, legal institutions, organizational governance, industry standards, professional judgment, or human oversight. Conformance to LERA means that a system possesses the relevant judgment-governance capability within a clearly defined scope. It does not mean that the system has satisfied every applicable legal, regulatory, technical, or industry requirement.

VI. Normative Source and Name Clarification

On this page, LERA refers specifically to:

LERA Judgment-Governance Architecture

The name “LERA” was originally formed as an abbreviation of Linda Energy Reliability Architecture. The name LERA may have existing uses in other industries, organizations, or fields of research, but those uses are unrelated to the architecture described on this page.

Normative source:

Jing (Linda) Liu. (2026). LERA Judgment-Governance Architecture White Paper (Version 2.0, Chinese edition). Zenodo.
https://doi.org/10.5281/zenodo.21442713

Additional public research and architectural resources:

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

This page is a public reference for the definition of LERA and the proper use of LERA conformance terminology. It does not constitute legal, regulatory, investment, or project-specific engineering advice.

Certain methods and technical solutions associated with this architecture are the subject of pending patent applications. Public disclosure does not constitute any express or implied license to intellectual property.