分布式系统中的裁决点
The Inevitability of Adjudication: Bridging the Gap Between Theoretical Consensus and Physical Reality in Distributed Systems
1. Executive Summary and Core Thesis
1.1 The Necessity of an External Adjudicator
EN:
The transition of distributed systems from an "idealized" theoretical model to a "realistic" engineering practice leads to a singular, inevitable conclusion: the structural necessity of a "Manual Adjudicator." This requirement is not a reflection of insufficient engineering capability, immature technology, or flawed code. Rather, it is a fundamental constraint dictated by the nature of the problem itself. When we rigorously analyze the mathematical limitations of distributed consensus—specifically the FLP Impossibility Theorem—alongside the physical fallibility of hardware, such as Silent Data Corruption, it becomes evident that a purely automated, closed-loop system cannot handle all possible failure modes. The system requires an external agent—an adjudicator—to resolve ambiguity and rectify state when the "mathematical ideal" collapses under "physical reality."
CN:
分布式系统从“理想化”的理论模型走向“现实”的工程实践的过程中，导向了一个单一且必然的结论：即“人工裁决者”在结构上的必要性。这一要求并非反映了工程能力的不足、技术的不成熟或代码的缺陷。相反，这是由问题本身的性质所决定的根本约束。当我们严谨地分析分布式共识的数学局限性——特别是 FLP 不可能性定理——以及硬件的物理不可靠性（如静默数据损坏）时，显而易见的是，一个纯粹自动化的闭环系统无法处理所有可能的故障模式。当“数学理想”在“物理现实”下崩塌时，系统需要一个外部代理——即裁决者——来消除歧义并修正状态。
EN:
This report structures the evidence for this conclusion into three distinct, interconnected logical layers, synthesizing theoretical proofs with empirical engineering data:
The Theoretical Limit: The FLP Impossibility Theorem proves that in an asynchronous network, no consensus algorithm can simultaneously guarantee Termination (Liveness), Agreement (Safety), and Fault Tolerance. We are forced to sacrifice one, usually liveness or safety, during partitioning. This creates "undecidable" states that necessitate an external mechanism to handle the edge cases we must mathematically exclude.
The Physical Reality: Even if consensus logic is theoretically perfect, the underlying storage substrate is not. "Silent Data Corruption" (bit rot, firmware bugs, phantom writes) creates scenarios where the database's committed state diverges from reality, undetectable by standard crash-recovery protocols (like Write-Ahead Logs). This forces us to distrust the "current state" of the database.
The Operational Solution: To mitigate these inevitable failures, we must adopt Event Sourcing and Manual Adjudication. Event Sourcing provides the "Replay" capability—a time machine to reconstruct state from intent—while Manual Adjudication provides the cognitive decision-making power to resolve complex, non-deterministic anomalies that automated rules cannot process.
CN:
本报告将支持这一结论的证据梳理为三个清晰且相互关联的逻辑层级，将理论证明与经验工程数据相结合：
理论极限： FLP 不可能性定理证明，在异步网络中，没有任何共识算法能够同时保证终止性（活性）、一致性（安全性）和容错性。我们被迫牺牲其中之一，通常是在分区期间牺牲活性或安全性。这创造了“不可判定”的状态，必然需要一个外部机制来处理我们在数学上必须排除的边缘情况。
物理现实： 即使共识逻辑在理论上是完美的，底层的存储基质却并非如此。“静默数据损坏”（位衰减、固件漏洞、幽灵写入）会导致数据库的已提交状态与现实发生偏离，这是标准的崩溃恢复协议（如预写日志）无法检测到的。这迫使我们不信任数据库的“当前状态”。
操作方案： 为了缓解这些不可避免的故障，我们必须采用事件溯源和人工裁决。事件溯源提供了“重放”能力——一种从意图中重建状态的时光机——而人工裁决则提供了认知决策能力，以解决自动化规则无法处理的复杂、非确定性异常。
2. The Theoretical Ceiling: FLP Impossibility and Engineering Trade-offs
2.1 The Impossibility Triangle
EN:
In the architectural design of distributed systems, the FLP Impossibility Theorem (Fischer, Lynch, and Paterson) serves as a foundational, unbreakable constraint. It posits that in an asynchronous network model—where message delays are unbounded and unpredictable, and processors operate at varying speeds—it is impossible to achieve a deterministic consensus algorithm that satisfies three specific properties simultaneously. This theorem is not merely a suggestion; it is a mathematical proof that defines the upper bound of what is computable in a distributed environment.
CN:
在分布式系统的架构设计中，FLP 不可能性定理（Fischer, Lynch 和 Paterson）作为一个基础的、不可打破的约束条件而存在。它指出，在异步网络模型中——即消息延迟无界且不可预测，且处理器以不同速度运行的情况下——不可能实现一个同时满足三个特定属性的确定性共识算法。这个定理不仅仅是一个建议；它是一个数学证明，定义了在分布式环境中可计算内容的上限。
EN:
The "surprise factor" of the FLP theorem is its severity: it demonstrates that the impossibility of consensus takes effect even if only one single node failure occurs.1 This counter-intuitive result implies that in a truly asynchronous environment, a healthy node cannot distinguish between a crashed peer and a peer that is simply very slow due to network latency. Therefore, any algorithm that waits for the slow node risks violating Termination (hanging forever), while any algorithm that proceeds without it risks violating Agreement (forking the state). Thus, a perfect algorithm that never hangs and never diverges is mathematically impossible if we also want to tolerate even a single fault.1
CN:
FLP 定理的“惊人之处”在于其严厉性：它证明了即使只发生一个单节点故障，共识的不可能性也会生效 1。这一反直觉的结果意味着，在真正的异步环境中，一个健康的节点无法区分其对等节点是崩溃了，还是仅仅因为网络延迟而非常缓慢。因此，任何等待慢速节点的算法都面临违反终止性（无限期挂起）的风险，而任何在没有该节点参与下继续进行的算法都面临违反一致性（状态分叉）的风险。因此，如果我们希望容忍哪怕是一个故障，那么一个永不卡死且永不分叉的完美算法在数学上是不可能存在的 1。
2.2 Engineering Implications: CAP and Consensus Protocols
EN:
Since we cannot satisfy all three properties, real-world engineering requires pragmatic sacrifices. This leads to the CAP Theorem (Consistency, Availability, Partition Tolerance), which is often viewed as the "practical, engineering side" of the FLP family.1 While FLP states "consensus is impossible," CAP states "you must choose your failure mode." Engineers must choose to relax constraints to meet business needs, effectively pushing the complexity of the "impossible" scenarios to a different layer of the stack.
CN:
由于我们无法满足所有三个属性，现实世界的工程实践需要务实的牺牲。这引出了 CAP 定理（一致性、可用性、分区容错性），它通常被视为 FLP 家族中“实用、工程化的一面” 1。虽然 FLP 指出“共识是不可能的”，但 CAP 指出“你必须选择你的故障模式”。工程师必须选择放宽约束以满足业务需求，实际上是将“不可能”场景的复杂性推向了技术栈的另一层。
EN:
Different consensus protocols navigate this trade-off differently, but none escape the fundamental limit:
Proof of Work (PoW): Used in blockchain (e.g., Bitcoin), PoW achieves Fault Tolerance and Liveness but sacrifices absolute deterministic Safety (Finality) in the short term. It relies on probability; a malicious actor would need overwhelming computational power to alter history. The system allows temporary forks (disagreement), resolving them over time through the "longest chain" rule. This means consensus is never 100% instant, only asymptotically probable.3
Raft / Paxos: These algorithms prioritize Safety (Consistency) and Fault Tolerance. They achieve Liveness by relying on leader election and heartbeats. However, during a partition or leader failure, the system may temporarily halt (sacrificing Liveness) until a new leader is elected. If a majority cannot be reached, the system simply stops processing writes. It prefers to be unavailable rather than incorrect.3
CN:
不同的共识协议以不同的方式应对这种权衡，但没有一个能逃脱这一根本限制：
工作量证明（PoW）： 应用于区块链（如比特币）中，PoW 实现了容错性和活性，但在短期内牺牲了绝对的确定性安全性（最终性）。它依赖于概率；恶意行为者需要压倒性的计算能力才能篡改历史。系统允许暂时的分叉（不一致），并通过“最长链”规则随时间解决这些分歧。这意味着共识永远不是 100% 即时的，而只是渐进概率性的 3。
Raft / Paxos： 这些算法优先考虑安全性（一致性）和容错性。它们通过依赖领导者选举和心跳机制来实现活性。然而，在分区或领导者故障期间，系统可能会暂时停滞（牺牲活性），直到选出新的领导者。如果无法达到多数派，系统将简单地停止处理写入。它宁愿不可用，也不愿出错 3。
EN:
This theoretical boundary establishes the first pillar of our thesis: The system cannot be perfect. There will always be scenarios—network partitions, extreme latency, or leader crashes—where the automated consensus mechanism either stalls (denial of service) or forks (split brain). In these "impossible" states, the system creates ambiguity that code cannot resolve. It requires an external intervention—an adjudicator—to restore order and decide which history is "true".2
CN:
这一理论边界确立了我们论点的第一个支柱：系统不可能完美。 总是存在某些场景——如网络分区、极端延迟或领导者崩溃——会导致自动化共识机制要么停滞（拒绝服务），要么分叉（脑裂）。在这些“不可能”的状态下，系统产生了代码无法解决的歧义。它需要外部干预——即裁决者——来恢复秩序并决定哪段历史是“真实的” 2。
3. The Physical Floor: Silent Data Corruption and Hardware Reality
3.1 The Reality of Hardware Failure
EN:
While FLP deals with logical impossibility, "Silent Data Corruption" (SDC) represents the physical betrayal of the storage infrastructure. A fundamental assumption in many database designs is that data written to disk is durable and correct—that fsync() guarantees permanence. However, reality contradicts this assumption. Silent data corruption occurs when a read operation returns different data from what was written, and these errors are not caught by the hard drive's internal mechanisms or standard operating system checks.5 This is the "Physical Floor" where the abstraction of reliable storage dissolves.
CN:
虽然 FLP 处理的是逻辑上的不可能性，但“静默数据损坏”（SDC）代表了存储基础设施在物理层面的背叛。许多数据库设计中的一个基本假设是：写入磁盘的数据是持久且正确的——即 fsync() 保证了持久性。然而，现实却与此假设相悖。当读取操作返回的数据与写入的数据不同，且这些错误未被硬盘内部机制或标准操作系统检查捕获时，就会发生静默数据损坏 5。这就是可靠存储抽象溶解的“物理地板”。
EN:
SDC manifests in severe, insidious ways that defy standard monitoring:
Bit Rot: Data degrades over time on the physical medium due to magnetic decay or electrical leakage, flipping bits randomly.
Firmware Bugs: The disk controller acknowledges a write ("Commit") but fails to persist it physically. This leads to "phantom" transactions that vanish after a restart. The application believes the data is safe, but the disk has silently discarded it.6
Verification Failures: Standard ECC (Error Correcting Code) on disks does not catch all errors, and non-checksummed file systems (like standard ext4 without extra protections) will happily serve corrupted data to the application.5
CN:
SDC 以严重且隐蔽的方式表现出来，甚至能够规避标准监控：
位衰减： 由于磁性衰减或漏电，数据随时间推移在物理介质上发生退化，导致比特随机翻转。
固件漏洞： 磁盘控制器确认写入（“提交”），但未能将其物理持久化。这导致“幽灵”事务在重启后消失。应用程序认为数据是安全的，但磁盘已经静默地将其丢弃 6。
校验失败： 磁盘上的标准 ECC（纠错码）无法捕获所有错误，且没有校验和的文件系统（如没有额外保护的标准 ext4）会愉快地将损坏的数据提供给应用程序 5。
3.2 Mitigation and Its Limits (PostgreSQL & ZFS)
EN:
To combat this, advanced storage technologies have been developed. File systems like ZFS employ end-to-end consistency via checksums, self-healing capabilities, and copy-on-write transactions to detect and repair corruption on the fly.5 Similarly, PostgreSQL offers a data_checksums parameter. When enabled, it allows the database to detect silent corruption during cluster initialization or runtime by verifying page integrity upon read.7
CN:
为了对抗这种情况，人们开发了先进的存储技术。像 ZFS 这样的文件系统采用了基于校验和的端到端一致性、自愈能力以及写时复制事务，以便即时检测和修复损坏 5。同样，PostgreSQL 提供了 data_checksums 参数。启用后，它允许数据库在读取时通过验证页面完整性，在集群初始化或运行时检测静默损坏 7。
EN:
However, these defenses are not absolute and come with performance penalties. Turning off checksums to improve speed (a common optimization) exposes the system to unrecoverable corruption.8 More critically, a failure mode exists involving the Write-Ahead Log (WAL) and ZFS Intent Log (ZIL). If a transaction is committed to the log but that specific log block is lost due to a partial write or corruption before being flushed to the main data file, the database may restart in an inconsistent state.
CN:
然而，这些防御措施并非绝对的，且伴随着性能代价。为了提高速度而关闭校验和（一种常见的优化）会将系统暴露在不可恢复的损坏风险中 8。更为关键的是，存在一种涉及预写日志（WAL）和 ZFS 意图日志（ZIL）的故障模式。如果一个事务已提交到日志，但该特定日志块在刷新到主数据文件之前因部分写入或损坏而丢失，数据库可能会在重启时处于不一致状态。
EN:
Consider the "Lost Commit" scenario in a financial system:
Transaction $X$ (Credit Card Approval) is committed.
The system crashes.
Due to a firmware bug or ZIL corruption, the record of Transaction $X$ is lost.
The system restarts. Transaction $X$ is gone.
However, Transaction $Y$ (Shipping Instruction), which depended on $X$, might have been successfully persisted in a different subsystem or log.
This creates a logical paradox: The product was shipped (Transaction $Y$ exists) for a payment that never happened (Transaction $X$ is missing). Automated recovery tools (like WAL replay) cannot fix this because they rely on the integrity of the log itself. If the log is the victim of corruption, the "truth" is lost.6
CN:
考虑金融系统中的“丢失提交”场景：
事务 $X$（信用卡审批）已提交。
系统崩溃。
由于固件漏洞或 ZIL 损坏，事务 $X$ 的记录丢失。
系统重启。事务 $X$ 消失了。
然而，依赖于 $X$ 的事务 $Y$（发货指令）可能已成功持久化在另一个子系统或日志中。
这产生了一个逻辑悖论：产品已发货（事务 $Y$ 存在），但对应的付款从未发生（事务 $X$ 缺失）。自动恢复工具（如 WAL 重放）无法修复这个问题，因为它们依赖于日志本身的完整性。如果日志本身是损坏的受害者，“真相”就丢失了 6。
EN:
In such catastrophic cases, the database administrator cannot simply "restart" to fix the issue. The solution requires forensic analysis: identifying the missing transaction and manually applying archived logs, or restoring from a backup and accepting data loss. This reinforces the need for a mechanism that allows for the reconstruction of reality from an external, immutable source: Event Replay.6
CN:
在这种灾难性情况下，数据库管理员无法简单地通过“重启”来解决问题。解决方案需要取证分析：识别丢失的事务并手动应用归档日志，或者从备份恢复并接受数据丢失。这进一步强化了对一种能够从外部、不可变来源重建现实的机制的需求：事件重放 6。
4. The Mechanism of Rectification: Event Sourcing
4.1 Events as the Source of Truth
EN:
To bridge the gap between theoretical consensus failures (FLP) and physical storage corruption (SDC), we must adopt Event Sourcing as a core architectural pattern. In a traditional CRUD (Create, Read, Update, Delete) system, the database stores only the current state of an entity. If that state is corrupted or incorrect due to a logic bug, the history is lost. In Event Sourcing, the "application state" (e.g., the current balance of an account) is merely a secondary derivative or a cached view. The primary, authoritative source of truth is the log of Domain Events (e.g., UserRegistered, UserChangedPassword, UserPublishedAnArticle).10
CN:
为了弥合理论共识故障（FLP）与物理存储损坏（SDC）之间的鸿沟，我们必须采用事件溯源作为核心架构模式。在传统的 CRUD（创建、读取、更新、删除）系统中，数据库仅存储实体的当前状态。如果该状态因逻辑错误而损坏或不正确，历史记录就会丢失。而在事件溯源中，“应用状态”（例如，账户的当前余额）仅仅是次级衍生物或缓存视图。首要的、权威的真理来源是领域事件日志（例如，UserRegistered（用户已注册），UserChangedPassword（用户更改了密码），UserPublishedAnArticle（用户发布了文章））10。
EN:
These events share critical properties that make them suitable for rectification:
Immutability: Once an event is written, it is never changed. We do not update a record; we append a new event correcting the previous one.
Chronological Ordering: Events form a strict sequence, representing the flow of time and causality.
Intent Capture: Unlike state (which shows "what"), events capture "why" and "how" (the user's intent).11
CN:
这些事件具有使其适合修正的关键属性：
不可变性： 事件一旦写入，就永远不会改变。我们不更新记录；我们追加一个新的事件来修正前一个。
时间顺序： 事件形成严格的序列，代表时间流和因果关系。
意图捕获： 与状态（显示“是什么”）不同，事件捕获了“为什么”和“怎么做”（用户的意图）11。
4.2 The Power of Replay
EN:
The definitive advantage—or "super power"—of Event Sourcing is Replayability. By discarding the potentially corrupted current state and re-processing the event log from zero (or a known good snapshot), we can reconstruct the system exactly as it should be. This capability acts as "version control for data's intent".12
Complete Rebuild: We can wipe the application state (e.g., drop the SQL tables) and rebuild them by re-running all events. This effectively cures "Silent Data Corruption" in the state view, assuming the event log itself remains intact (often stored in a simpler, append-only, highly replicated manner).11
Temporal Query: We can determine the state of the system at any past point in time. We can ask, "What did the system look like at 10:00 AM before the bug triggered?"
Retroactive Correction: If a past event was incorrect (or corrupted), we can insert a "Compensating Event" or fix the event stream, and then replay all subsequent events to compute the correct current state. This allows for "Time Travel" debugging and fixing.11
CN:
事件溯源的决定性优势——或者说“超能力”——是可重放性。通过丢弃可能已损坏的当前状态，并从零（或已知良好的快照）开始重新处理事件日志，我们可以精确地将系统重建为它应有的样子。这种能力充当了“数据意图的版本控制” 12。
完全重建： 我们可以清除应用状态（例如，删除 SQL 表），并通过重新运行所有事件来重建它们。这有效地治愈了状态视图中的“静默数据损坏”，假设事件日志本身保持完整（通常以更简单的、仅追加的、高度复制的方式存储）11。
时态查询： 我们可以确定系统在过去任何时间点的状态。我们可以问：“在 10:00 AM 漏洞触发之前，系统是什么样子的？”
追溯修正： 如果过去的某个事件不正确（或已损坏），我们可以插入一个“补偿事件”或修复事件流，然后重放所有后续事件以计算出正确的当前状态。这允许进行“时间旅行”式的调试和修复 11。
4.3 Engineering Challenges of Replay
EN:
However, implementing replay is non-trivial and introduces significant engineering overhead.
Schema Evolution: As the software evolves, the structure (schema) of events changes. A UserRegistered event from 2020 might lack fields required in 2025. The system must maintain "Upcasters"—handlers that translate old event versions into new formats on the fly during replay. This adds a maintenance burden: bug fixes might require changes across multiple version handlers.13
Determinism: Replay logic must be strictly deterministic. If the original processing involved external calls (e.g., checking a third-party credit score) or random number generation, replaying strictly from logs without caching those external responses will yield different results. To solve this, external responses must also be captured as events ("Gateway Events"), increasing storage volume and complexity.14
Performance: Replaying millions of events is slow. Systems often use "Snapshots" to cache state at regular intervals (e.g., every 1000 events) to speed up recovery. However, if the snapshot itself contains the corruption, one must revert to the raw log, necessitating a high-performance replay engine.13
CN:
然而，实施重放并非易事，并引入了巨大的工程开销。
模式演进： 随着软件的演进，事件的结构（模式）也会发生变化。2020 年的 UserRegistered 事件可能缺少 2025 年所需的字段。系统必须维护**“升级器”**——在重放期间将旧事件版本即时转换为新格式的处理程序。这增加了维护负担：错误修复可能需要在多个版本处理程序中进行更改 13。
确定性： 重放逻辑必须是严格确定性的。如果原始处理涉及外部调用（例如，检查第三方信用评分）或随机数生成，那么在没有缓存这些外部响应的情况下严格从日志重放将产生不同的结果。为了解决这个问题，外部响应也必须被捕获为事件（“网关事件”），从而增加了存储量和复杂性 14。
性能： 重放数百万个事件是很慢的。系统通常使用“快照”定期缓存状态（例如，每 1000 个事件）以加速恢复。然而，如果快照本身包含损坏，则必须回退到原始日志，这就需要高性能的重放引擎 13。
Despite these costs, for systems requiring high auditability and recovery from "silent" failures, the trade-off is justified. The ability to "Replay" is the only mechanism that provides the raw material for the Adjudicator to do their job.
尽管存在这些成本，但对于需要高可审计性和从“静默”故障中恢复的系统来说，这种权衡是合理的。“重放”能力是唯一能为裁决者提供履行其职责所需原材料的机制。
5. The Synthesis: Manual Adjudication as a System Component
5.1 Defining the Role of the Adjudicator
EN:
The convergence of FLP limits (which guarantee occasional ambiguity), hardware risks (which guarantee occasional corruption), and the capability of Event Replay (which allows inspection) mandates the integration of Manual Adjudication as a formal, first-class system component. This is not merely an operational "fix" or a fallback for bad code; it is a permanent architectural design pattern.
The system must be explicitly designed to:
Identify Exceptions: Detect claims, transactions, or states that fail automatic adjudication due to rule ambiguity, data inconsistency, or low confidence.15
Route to Queue: Isolate these exceptions and route them to a specialized human work queue, prioritized by severity or difficulty.15
Empower with Context: Provide the human agent with the full data context—generated via Event Replay—including the timeline of what happened, what failed, and why.16
Inject Decision: Accept the human's decision as a new, authoritative "Adjudication Event" that resolves the conflict and allows the automated system to resume processing.17
CN:
FLP 极限（保证了偶尔的歧义）、硬件风险（保证了偶尔的损坏）以及事件重放能力（允许检查）的融合，要求将人工裁决整合为一种正式的、一等的系统组件。这不仅仅是一个运维上的“补丁”或代码缺陷的后备方案；它是一种永久性的架构设计模式。
系统的设计必须明确能够：
识别异常： 检测因规则歧义、数据不一致或置信度低而导致自动裁决失败的索赔、事务或状态 15。
路由至队列： 隔离这些异常并将它们路由到专门的人工工作队列，并按严重性或难度进行优先级排序 15。
赋能上下文： 为人工代理提供完整的数据上下文——通过事件重放生成——包括发生了什么、什么失败了以及原因的时间线 16。
注入决策： 接受人工的决策作为一个新的、权威的“裁决事件”，该事件解决冲突并允许自动化系统恢复处理 17。
5.2 Case Studies in Necessity and Implementation
EN:
Case Study 1: Insurance and Healthcare Claims
In health insurance claims processing, "Manual Adjudication" is a standard, mature workflow. Systems like Oracle Health Insurance process massive volumes of data from varying formats, languages, and origins. Automation handles the clear-cut cases. However, when a claim involves complex policy exceptions or data that cannot be systematically validated (e.g., a "placeholder" error code like OHI-002), it is routed to a desktop interface for a human user. The system supports this by allowing messages and error codes to be attached to claim lines, guiding the adjudicator.15
Recent research validates this hybrid model. A study on heart failure hospitalization adjudication showed that while NLP models are efficient, they are not perfect. A strategy where the NLP model adjudicates high-confidence cases and defers uncertain ones (approx. 20%) to humans yielded 94% accuracy while reducing manual effort by 80%. This proves that the "Adjudicator" maximizes system accuracy where pure automation would fail.18
CN:
案例研究 1：保险与医疗理赔
在健康保险理赔处理中，“人工裁决”是一个标准且成熟的工作流程。像 Oracle Health Insurance 这样的系统处理来自不同格式、语言和来源的海量数据。自动化处理那些清晰明确的案例。然而，当索赔涉及复杂的保单例外情况或无法进行系统验证的数据（例如，像 OHI-002 这样的“占位符”错误代码）时，它会被路由到人工用户的桌面接口。系统通过允许将消息和错误代码附加到索赔行来支持这一点，从而指导裁决者 15。
最近的研究验证了这种混合模型。一项关于心力衰竭住院裁决的研究表明，虽然 NLP 模型很高效，但它们并不完美。一种策略是让 NLP 模型裁决高置信度案例，并将不确定的案例（约 20%）推迟给人工处理，这种做法在保持 94% 准确率的同时减少了 80% 的人工工作量。这证明了在纯自动化会失败的地方，“裁决者”最大化了系统的准确性 18。
EN:
Case Study 2: Distributed Cognitive Systems (Defense)
In military contexts (e.g., MUNI-KASS), the system is viewed as a "distributed cognitive system" where the adjudicator is an active agent, not just a passive monitor. Hierarchical Task Analysis (HTA) is used to map the adjudicator's domain. As unmanned and automated systems proliferate, the interaction complexity increases. Contrary to the belief that AI eliminates humans, the increased speed and lethality of automated systems make manual adjudication more critical to manage the "fog of war" and mitigate system errors or hallucinations. The human provides the contextual understanding and ethical reasoning that algorithms lack, acting as the final safety valve.16
CN:
案例研究 2：分布式认知系统（国防）
在军事背景下（例如 MUNI-KASS），系统被视为一个“分布式认知系统”，其中裁决者是一个主动的代理，而不仅仅是被动的监视者。层次任务分析（HTA）被用于映射裁决者的领域。随着无人和自动化系统的激增，交互复杂性增加。与 AI 消除人类的观念相反，自动化系统的速度和杀伤力的增加使得人工裁决在管理“战争迷雾”以及缓解系统错误或幻觉方面变得更加关键。人类提供了算法所缺乏的上下文理解能力和伦理推理，充当了最终的安全阀 16。
EN:
Case Study 3: Software Development (Static Analysis)
Even in software engineering itself, manual adjudication is required for Static Analysis. Automated tools generate "meta-alerts" for potential code flaws. However, false positives are common due to the inability of algorithms to perfectly understand code intent. "Manual adjudication" of these alerts is technically challenging but necessary. The lesson here is that even in deterministic logic domains (code analysis), ambiguity exists that requires human judgment to resolve.19
CN:
案例研究 3：软件开发（静态分析）
即使在软件工程本身，静态分析也需要人工裁决。自动化工具会针对潜在的代码缺陷生成“元警报”。然而，由于算法无法完美理解代码意图，误报是很常见的。对这些警报进行“人工裁决”在技术上具有挑战性，但却是必要的。这里的教训是，即使在确定性逻辑领域（代码分析），也存在需要人类判断来解决的歧义 19。
6. Conclusion
6.1 The Inevitability of the Loop
EN:
The journey from distributed system theory to practice confirms that the "Adjudicator" is not an optional luxury but a structural necessity.
FLP Impossibility guarantees that we cannot have a perfectly safe and live system in an asynchronous world; we must handle the stalls and partitions where the algorithm fails to decide.
Silent Data Corruption guarantees that even our durable storage will occasionally lie to us, creating logical paradoxes that automated recovery cannot solve.
Event Sourcing provides the technical capability (Replay) to enable reconstruction and debugging, serving as the "evidence recorder."
Manual Adjudication supplies the cognitive authority to resolve the ambiguity that the system cannot mathematically or physically resolve itself.
CN:
从分布式系统理论到实践的旅程证实，“裁决者”并非一种可有可无的奢侈品，而是一种结构性的必然。
FLP 不可能性 保证了我们在异步世界中无法拥有一个完美安全且具有活性的系统；我们必须处理算法无法做出决定时的停滞和分区。
静默数据损坏 保证了即使我们的持久化存储偶尔也会对我们撒谎，从而产生自动恢复无法解决的逻辑悖论。
事件溯源 提供了实现重建和调试的技术能力（重放），充当了“证据记录仪”。
人工裁决 提供了认知权威，以解决系统在数学上或物理上无法自行解决的歧义。
EN:
Therefore, the ultimate conclusion for the architect is to stop striving for a system that never fails—a mathematically impossible goal. Instead, the goal is to build a system that confesses its failures to an adjudicator. The system must recognize when it has hit the theoretical wall (FLP) or the physical floor (Corruption), pause, and present the immutable evidence (Events) to the human in the loop. This interaction pattern—Machine for scale, Human for exception—is the only viable path from "Ideal" to "Reality."
CN:
因此，对于架构师而言，终极结论是停止追求一个从不故障的系统——这是一个数学上不可能实现的目标。相反，目标是构建一个能够向裁决者坦白其故障的系统。系统必须识别它何时撞上了理论的高墙（FLP）或跌落到物理的地板（损坏），暂停，并将不可变的证据（事件）呈现给环路中的人类。这种交互模式——机器负责规模，人类负责异常——是从“理想”通往“现实”的唯一可行路径。
Works cited
History of the Impossibles - CAP and FLP – Anh Dinh – Senior Lecturer, accessed December 12, 2025,
Practical Understanding of FLP Impossibility for Distributed Consensus | by Melodies Sim, accessed December 12, 2025,
FLP Impossibility and Blockchain Consensus Protocols - Sarin Madarasmi - Medium, accessed December 12, 2025,
Distributed Consensus: Beating Impossibility with Probability One - Marc's Blog, accessed December 12, 2025,
ZFS: Love Your Data, accessed December 12, 2025,
ZFS - 2x3tb as one raidz member | Page 3 - The FreeBSD Forums, accessed December 12, 2025,
Tuning PostgreSQL for High Performance and Minimal Risk - CloudThat, accessed December 12, 2025,
PostgreSQL Documentation: full_page_writes parameter - PostgresqlCO.NF, accessed December 12, 2025,
Possible data loss on postgres failover (#7282) · Issue - GitLab, accessed December 12, 2025,
Event-sourcing and the event-replay mystery - DEV Community, accessed December 12, 2025,
Event Sourcing - Martin Fowler, accessed December 12, 2025,
Event Sourcing as a creative tool for engineers : r/softwarearchitecture - Reddit, accessed December 12, 2025,
Event Sourcing pattern - Azure Architecture Center | Microsoft Learn, accessed December 12, 2025,
Event sourcing - event replaying - Stack Overflow, accessed December 12, 2025,
US20080040164A1 - System and Method for Facilitating Claims Processing - Google Patents, accessed December 12, 2025,
A Digital Adjudication Tool as a Cognitive Artifact: Design and Evaluation in a Tactical Simulation Environment, accessed December 12, 2025,
Messages :: Oracle Health Insurance Claims Adjudication and Pricing (3.21.1), accessed December 12, 2025,
Natural Language Processing for Adjudication of Heart Failure Hospitalizations in a Multi-Center Clinical Trial - PubMed Central, accessed December 12, 2025,
To overcome barriers to using automated classifiers during CI, we designed a system that enables classification to be used in CI builds, including cascading adjudications. - Software Engineering Institute - Carnegie Mellon University, accessed December 12, 2025,