fix(aodb): harden MVP high-level design

Clarify SSOT authority boundaries, core entity model, event contract and consistency, resource assignment rules, northbound API contract, observability/capacity baselines, and Go/No-Go gates.

Made-with: Cursor

airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md

@@ -23,16 +23,16 @@
 
 | 层级         | 主要能力                                 | 代表组件                                                           |
 | ------------ | ---------------------------------------- | ------------------------------------------------------------------ |
-| 接入层       | 外部系统接入、协议解析、统一 API         | API Gateway、协议适配器、SSIM 导入器                               |
+| 接入层       | 外部系统接入、协议解析、统一北向入口     | Kong Gateway、Apache Camel、SSIM 导入器                            |
 | 业务层       | 航班管理、资源分配、里程碑管理、告警处理 | Flight Service、Resource Service、Milestone Service、Alert Service |
-| 事件与计算层 | 事件总线、规则计算、基础预测             | Kafka、规则引擎、轻量预测服务                                      |
+| 事件与计算层 | 事件总线、流处理与预测、规则判定与编排   | Kafka、Flink、Drools、Temporal                                     |
 | 数据层       | 事务存储、时序存储、缓存、检索           | PostgreSQL、TimescaleDB、Redis、OpenSearch                         |
-| 平台层       | 身份认证、部署运行、监控告警             | Keycloak、Kubernetes、Prometheus/Grafana                           |
+| 平台层       | 身份认证、部署运行、观测与服务治理       | Keycloak、Kubernetes、Prometheus/Grafana、Jaeger、Loki、Linkerd    |
 
 ### 3.2 核心模块职责
 
 - Flight Service：维护航班计划、动态状态和历史记录。
-- Resource Service：进行机位/登机口等资源分配与冲突检查。
+- Resource Service：进行机位/登机口/行李转盘/值机柜台等资源分配与冲突检查，支持人工覆盖与审计。
 - Milestone Service：维护 A-CDM 关键里程碑时间点。
 - Alert Service：统一处理延误、冲突等运营告警。
 - ACISP 接口层：向航司、地服、AOC 提供查询与订阅能力。
@@ -43,6 +43,122 @@
 - Milestone：`flight_id + milestone_type + source + event_time` 作为幂等写入键。
 - ResourceAssignment：`resource_type + resource_id + time_window + flight_id` 作为分配唯一键。
 
+### 3.4 权威边界（SSOT）与写入治理（MVP）
+
+为实现“单一事实源（SSOT）”，AODB 必须对外明确两类信息：
+
+1. **状态事实（Fact）**：AODB 对外提供的“当前状态”是唯一权威输出。
+2. **来源与裁决（Provenance）**：每个关键状态字段必须可追溯其来源、可信度与裁决过程。
+
+#### 3.4.1 状态写入三元信息（最小要求）
+
+所有关键状态写入（航班动态、里程碑、资源分配、告警）必须携带以下最小三元信息并持久化：
+
+- `source`：来源系统/组织（如 ANSP/航司/地服/机场运行/人工裁决），并可扩展到具体系统标识。
+- `confidence`：可信度等级（建议：`confirmed`/`estimated`/`reported`/`suspect`），用于表示数据质量与可用性。
+- `decision`：裁决信息（可为空）。若发生冲突或人工覆盖，必须记录：裁决人/系统、裁决原因、裁决时间与裁决依据。
+
+#### 3.4.2 权威边界与冲突裁决原则（MVP）
+
+为避免“多系统同写同字段”导致不可控冲突，MVP 采用以下治理原则：
+
+- **分层权威**：以“字段/里程碑”为粒度定义权威优先级（不同字段可不同）。例如：
+  - **到离港实际时间类（如 ALDT）**：优先 ANSP/机场运行权威源，其次航司上报，最后为人工裁决。
+  - **协同计划时间类（如 TOBT）**：优先航司/地服协同上报，其次机场运行，最后为人工裁决。
+  - **资源分配类（机位/登机口/行李转盘/值机柜台）**：优先机场运行系统计算与人工调度，外部源仅作为建议输入。
+- **可信度优先**：在同等来源优先级下，`confidence` 更高者覆盖更低者。
+- **更正优先**：当上游明确发送“更正/撤销”语义（或带更高版本号/序列号）时，允许对既有事实进行修正，但必须保留历史与审计轨迹。
+- **不可判定进入旁路**：无法自动裁决的冲突必须进入“人工复核队列”，同时对外输出“冲突标记/数据质量标记”，避免静默覆盖。
+
+#### 3.4.3 审计与可追溯要求（MVP）
+
+- **审计覆盖范围**：
+  - 航班关键状态字段的变更（计划/预计/实际时间、关键里程碑状态）
+  - 资源分配变更（分配/释放/人工覆盖/回滚）
+  - 告警生命周期变更（触发/确认/关闭/抑制）
+- **审计最小字段**：`who/what/when/why`（操作者或系统、变更字段、变更前后值、时间、原因/关联事件）。
+- **对外可见性**：对外查询接口必须能返回“当前值 + source/confidence + 最近一次裁决摘要”，以便订阅方正确解读数据质量。
+
+### 3.5 核心实体与关系（ER 概念级，MVP）
+
+本节定义 AODB 的最小“可落地”概念模型，用于约束后续数据字典与接口契约的一致性。
+
+- Flight：航班在指定运行日（op_date）的运行对象，包含计划/预计/实际时间与当前态字段集合。
+- Milestone：A-CDM 里程碑事件记录（含来源、可信度、审计信息），与 Flight 关联。
+- Resource：资源主数据，MVP 覆盖：
+  - Stand（机位）、Gate（登机口）、Belt（行李转盘）、Counter（值机柜台）
+- ResourceAssignment：资源占用/分配记录（含时间窗口、分配来源、是否人工覆盖），与 Flight 与 Resource 关联。
+- Alert：告警实体（延误/冲突/超阈值），含生命周期（触发、确认、关闭、抑制）与处置轨迹。
+- DataQualityFlag（可选但建议纳入 MVP）：对“冲突/不可判定/低可信度”等数据质量问题的结构化标记，便于对外呈现与内部对账。
+
+实体关系（概念级）：
+
+- 一个 Flight 对应多个 Milestone（1:N）。
+- 一个 Flight 在同一时间窗口内可占用多个资源（例如 Stand + Gate + Belt + Counter），每类资源对应多个 ResourceAssignment（1:N）。
+- 一个 Resource 在时间轴上对应多个 ResourceAssignment（1:N），但同一资源的占用窗口不得重叠（冲突即告警）。
+- Alert 可关联到 Flight，亦可关联到具体 Resource/ResourceAssignment（N:1）。
+
+#### 3.5.1 主键与唯一性约束（高层口径）
+
+- Flight：建议区分
+  - `flight_key`（业务唯一键）：`carrier + flight_number + op_date + leg_no`
+  - `flight_id`（系统主键）：内部生成的不可变 ID（推荐 UUID/雪花 ID）。
+- Resource：`resource_type + resource_code`（或 `resource_id`）唯一。
+- ResourceAssignment：同一 `resource_type + resource_id` 的 `time_window` 不允许重叠；若发生则必须产生冲突告警并进入人工/规则裁决。
+
+### 3.6 Flight 状态模型（最小状态机，MVP）
+
+为支撑“当前态查询”和“事件订阅”，AODB 对 Flight 的当前态至少需要统一以下字段口径：
+
+- 时间类：计划（Scheduled）、预计（Estimated）、实际（Actual）三组时间；MVP 强制覆盖里程碑相关时间（如 EOBT/TOBT/TSAT/ALDT/EIBT）。
+- 资源类：当前生效的 Stand/Gate/Belt/Counter 分配（可为空），并能追溯来源与覆盖原因。
+- 质量类：是否存在冲突/待裁决标记（可由 DataQualityFlag/Alert 汇总而来）。
+
+最小状态机（示意，非穷尽）：
+
+- Planned：已导入计划但无运行动态。
+- Active：已接收运行动态/里程碑并持续更新。
+- Completed：已到达关键收敛里程碑（例如到位/关舱等）并可进入归档策略。
+- Cancelled：取消/无效（保留审计与历史，避免硬删除）。
+
+状态迁移原则：
+
+- 状态迁移由“里程碑事实”驱动，不直接由单个外部系统声明。
+- 若存在冲突或裁决，状态不回滚到更早阶段，但可产生“更正事件/裁决事件”并更新当前态字段，同时保留历史。
+
+### 3.7 历史、快照与可追溯（MVP）
+
+为兼顾实时查询与审计追溯，MVP 推荐采用以下高层模式：
+
+- CurrentState（可变）：保存 Flight/Resource 的当前态，用于低延迟查询与看板展示。
+- EventLog（追加）：保存标准化后的业务事件与关键变更（MilestoneUpserted、ResourceAssigned、AlertRaised 等），用于回放、对账与审计。
+
+要求：
+
+- CurrentState 的任何关键字段变更都必须能在 EventLog 中找到对应的原因事件（或裁决事件）。
+- 对外“历史回放”能力通过 EventLog/时间范围过滤实现；不要求首期提供全量任意时点快照，但必须支持“关键链路回放与审计抽样”。
+
+### 3.8 计算、规则与工作流职责边界（Flink / Drools / Temporal，MVP）
+
+为对齐“实时计算引擎为 MVP”以及可追溯与可审计要求，MVP 对计算/规则/编排做明确分工：
+
+- Flink（流处理/实时计算）：
+  - 里程碑派生与聚合（例如从多源事件推导统一里程碑视图）。
+  - 预测类计算的在线聚合与发布（EIBT/EXIT/EXOT 等的估计值生成/更新）。
+  - 复杂事件检测（CEP）：异常模式识别与实时指标聚合。
+- Drools（规则判定/可配置/可追溯）：
+  - 延误/冲突/阈值告警规则与资源分配约束校验规则。
+  - 规则版本管理与灰度：规则变更必须可回放验证，避免误报/漏报。
+  - 规则执行结果必须可追溯（输出触发条件、命中规则、输入快照摘要）。
+- Temporal（工作流编排/长事务/补偿）：
+  - DLQ/人工复核闭环：解析失败→任务分派→复核结果→重放/裁决事件输出。
+  - 跨系统补偿流程：当外部源延迟/更正导致状态回补时，编排补偿与通知。
+  - 关键处置流程：告警处置、资源冲突裁决的状态流转与审计留存。
+
+验收口径（与 6.4 对齐）：
+
+- 对任一预测/告警/裁决结果，能够通过事件链路回放解释“数据从哪来、规则如何命中、流程如何流转”。
+
 ## 4. 关键数据流（初版）
 
 ### 4.1 航班计划导入流
@@ -61,20 +177,124 @@
 
 ### 4.3 事件一致性与异常处理约束
 
-1. 所有写入事件必须携带 `idempotency_key`，重复事件只更新一次。
-2. 同一 `flight_id` 的事件按 `event_time + version` 排序处理，过旧版本进入旁路审计。
-3. 解析失败或校验失败消息进入 DLQ，并生成人工复核任务。
-4. 外部源异常抖动时启用降级策略：保留最近可信状态并标记数据可信度。
+#### 4.3.1 事件类型清单（MVP，建议最小集）
+
+- FlightImported：航班计划已导入并标准化。
+- FlightUpdated：航班关键字段（计划/预计/实际/取消等）发生变更。
+- MilestoneUpserted：里程碑写入/更正（含来源、可信度与裁决）。
+- ResourceAssigned：资源已分配（Stand/Gate/Belt/Counter）。
+- ResourceUnassigned：资源已释放/撤销分配。
+- ResourceConflictDetected：资源占用冲突被检测到（需人工/规则裁决）。
+- AlertRaised：告警触发（延误/冲突/超阈值）。
+- AlertAcknowledged：告警已确认（进入处置中）。
+- AlertCleared：告警已关闭或解除。
+- DataQualityFlagged：产生数据质量标记（冲突、不可判定、低可信度等）。
+- ManualDecisionRecorded：人工裁决已记录（覆盖原因与证据）。
+
+#### 4.3.2 事件最小字段（Envelope）
+
+所有业务事件必须具备统一事件信封，确保可追溯、可回放、可演进：
+
+- `event_id`：全局唯一 ID（用于去重与审计）。
+- `event_type`：事件类型（见 4.3.1）。
+- `schema_version`：事件 schema 版本（向后兼容为原则）。
+- `occurred_at`：业务发生时间（来自上游或由系统推断）。
+- `produced_at`：AODB 产生该事件的时间。
+- `source`：来源（与 3.4 一致）。
+- `idempotency_key`：幂等键（见 4.3.3）。
+- `correlation_id`：关联 ID（用于串联同一业务链路，如同一条 AFTN 报文/同一次导入批次）。
+- `flight_id`：关联航班（若适用）。
+- `payload`：事件负载（各事件类型自定义）。
+
+#### 4.3.3 幂等与更正语义（MVP）
+
+1. 所有写入事件必须携带 `idempotency_key`，重复事件不得产生重复副作用（至少做到 at-least-once 输入下的“结果幂等”）。
+2. 幂等键的生成原则：尽量使用上游“不可变消息标识/序列号”（如报文 ID、批次+行号），避免仅用 `event_time` 作为幂等锚点。
+3. 更正（Correction）必须显式：
+   - 若上游具备更正/撤销语义，则映射为 `MilestoneUpserted`（含更正标记或更高序列），同时保留旧值审计。
+   - 若上游无更正语义，则 AODB 只能通过“裁决事件（ManualDecisionRecorded）”修正当前态，并保留冲突与裁决轨迹。
+
+#### 4.3.4 顺序保证边界与乱序处理（MVP）
+
+1. 顺序保证以 `flight_id` 为最小粒度：同一 `flight_id` 的事件按分区键落到同一顺序通道（例如 Kafka 分区），确保消费端可按序处理。
+2. 同一 `flight_id` 内部的处理顺序以 `occurred_at` 优先，其次以 `source_sequence`（若上游提供）或 AODB 生成的 `ingest_sequence` 作为并列消歧。
+3. 过旧/乱序事件处理策略：
+   - 允许在可配置“乱序窗口”内重排；超窗事件进入旁路审计并生成 DataQualityFlag。
+   - 不允许静默覆盖已确认事实；需触发冲突标记或进入人工复核。
+
+#### 4.3.5 写库与发事件一致性（Outbox/CDC，高层约束）
+
+为避免“写库成功但没发事件/发了事件但没落库”的不可审计空洞，MVP 必须采用可验证的一致性策略之一：
+
+- 主选：**Outbox Pattern + CDC**
+  - 业务服务在同一数据库事务内：更新 CurrentState，并写入 Outbox 表。
+  - CDC/发布器将 Outbox 可靠发布到 Kafka，并在成功后标记已发布。
+- 约束：
+  - 事件发布必须可重试；失败不得丢失，且必须可回放。
+  - 对外订阅以 Kafka 事件为事实流（或由 Kafka 驱动 Hasura 订阅层的投影），避免多路源头。
+
+#### 4.3.6 解析失败、DLQ 与人工复核闭环（MVP）
+
+1. 解析失败或校验失败消息进入 DLQ，并生成“人工复核任务”（可由工作流编排系统承接）。
+2. 人工复核结果必须形成结构化输出：要么生成可重放的标准化事件，要么生成裁决事件（ManualDecisionRecorded）。
+
+#### 4.3.7 一致性口径（对齐需求）
+
+- 关键实体（Flight 当前态、ResourceAssignment 生效集、Alert 生命周期）在同一服务内采用强一致事务写入。
+- 跨服务/跨投影（例如检索、订阅投影、指标聚合）采用最终一致，目标：**最终一致收敛 <= 30 秒**。
+- 验收方式：对账任务 + 抽检回放，必须能解释每一次不一致的根因（延迟、乱序、裁决、外部源缺陷等）。
+
+#### 4.3.8 降级策略（MVP）
+
+外部源异常抖动时启用降级策略：保留最近可信状态并标记数据可信度；对外订阅必须包含数据质量标记，避免下游误用。
+
+### 4.4 资源分配规则（MVP）
+
+MVP 资源管理覆盖：Stand（机位）、Gate（登机口）、Belt（行李转盘）、Counter（值机柜台）。资源分配的目标不是“全局最优”，而是保证冲突可检测、可裁决、可追溯，并能支撑秒级传播与对外可解释。
+
+#### 4.4.1 时间窗口（time_window）口径
+
+- **分配窗口组成**：`[start_time, end_time] + buffer_before + buffer_after`。
+- **锚点选择（MVP）**：
+  - Stand：以 `ALDT/EIBT`（到达侧）与 `AOBT/ATOT`（离港侧）相关里程碑推导占用区间；若缺失则回退到 Estimated。
+  - Gate：以旅客流程相关里程碑（如登机开始/结束、关舱/推出）推导；缺失时回退到 TOBT/TSAT 近似。
+  - Belt：以 `AIBT/EIBT` 起算，结合航班机型/行李量经验参数给出默认占用时长（可配置）。
+  - Counter：以航班计划起飞前固定窗口（如 T-3h 至 T-45min）为默认规则（可配置并可按航司差异化）。
+- **滑动更新**：当关键里程碑变更（延误、提前、取消、更正）时，ResourceAssignment 必须重算窗口并触发冲突检测。
+
+#### 4.4.2 冲突定义与缓冲策略
+
+- **冲突定义**：同一 `resource_type + resource_id` 的生效占用窗口发生重叠即为冲突。
+- **缓冲策略**：缓冲时间为规则参数（按资源类型/机场策略配置）。缓冲引入的冲突必须可解释（在告警中记录触发原因）。
+
+#### 4.4.3 分配优先级与人工覆盖
+
+MVP 采用“规则优先 + 人工可覆盖”的策略：
+
+- 自动分配/调整由规则或简单启发式完成（不做全局优化），输出 ResourceAssigned/Unassigned 事件。
+- 人工覆盖（override）必须：
+  - 记录 `decision`（原因/证据/操作者）并产生 ManualDecisionRecorded。
+  - 可回滚（回滚同样写审计）。
+
+#### 4.4.4 与航班变更联动（延误/取消/换机型）
+
+- 延误：窗口整体右移或重新估算，先“保持原资源”并检测后续冲突；若冲突不可自动消解则触发 ResourceConflictDetected + AlertRaised。
+- 取消：释放资源并触发 ResourceUnassigned；若取消为更正则需保留历史并标记更正原因。
+- 换机型/机位限制变化：触发资源适配性校验，不满足则产生冲突并进入裁决流程。
+
+#### 4.4.5 输出与审计（最小要求）
+
+- 任何资源变更都必须能回答：谁分配的（规则/人工）、为什么分配、影响了哪些航班、是否引发冲突告警。
 
 ## 5. 首期上线范围（MVP）
 
 首期建议只覆盖以下最小闭环：
 
 - 航班计划导入与实时状态更新。
-- 基础资源分配（机位、登机口）。
+- 基础资源分配（机位、登机口、行李转盘、值机柜台）。
 - 关键里程碑跟踪（EOBT/TOBT/TSAT/ALDT/EIBT）。
 - 延误与资源冲突告警。
-- 对外查询接口与基础订阅推送。
+- 对外查询接口与订阅推送（REST + GraphQL Subscription）。
 
 不纳入首期：
 
@@ -85,9 +305,41 @@
 ### 5.1 上线门禁（Go/No-Go）
 
 - 功能门禁：航班导入、里程碑更新、资源分配、冲突告警链路可端到端演示。
-- 性能门禁：关键状态事件处理延迟达到最低可接受值。
+- 性能门禁：在峰值吞吐与订阅并发条件下，端到端事件延迟达到最低可接受值（见 6.1/6.4/6.5 的压测口径）。
 - 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
 - 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
+- 演练门禁：完成容灾恢复与回滚演练，RTO/RPO 达到最低可接受值并留存记录。
+
+### 5.2 关键场景走读（MVP）
+
+本节用于评审阶段快速验证“闭环是否成立、可追溯是否可用、异常是否可处置”。
+
+#### 场景 1：SSIM 导入 → 标准化 → 发布 → 订阅
+
+1. SSIM 导入进入接入层（解析/校验/标准化）。
+2. Flight Service 在事务内写 CurrentState + Outbox。
+3. CDC/发布器将 Outbox 事件发布到 Kafka（FlightImported/FlightUpdated）。
+4. Hasura/订阅层向终端/外部系统推送订阅事件或提供查询读。
+
+验收点：重复导入不产生重复副作用；订阅可重连补偿；可追溯到导入批次与来源。
+
+#### 场景 2：多源里程碑冲突（以 ALDT 为例）→ 裁决 → 审计 → 对外呈现
+
+1. 两个来源上报同一航班 ALDT，发生冲突（source/confidence/序列不一致）。
+2. 系统按 3.4 裁决原则尝试自动裁决；不可判定则产生 DataQualityFlagged + 进入人工复核。
+3. 人工复核通过工作流记录 ManualDecisionRecorded，更新当前态并保留历史。
+4. 对外查询返回“当前值 + source/confidence + 裁决摘要”；订阅推送裁决事件。
+
+验收点：冲突不静默覆盖；审计可还原变更前后与原因；最终一致收敛 <= 30 秒。
+
+#### 场景 3：延误导致资源冲突（以 Stand 为例）→ 告警 → 覆盖/回滚
+
+1. 延误触发 ResourceAssignment 窗口右移，检测到同机位窗口重叠。
+2. 产生 ResourceConflictDetected + AlertRaised；规则可给出建议（可选）。
+3. 调度人工覆盖资源分配（记录 decision），触发 ResourceAssigned + ManualDecisionRecorded。
+4. 如需回滚，回滚同样形成事件与审计。
+
+验收点：冲突检测可解释；覆盖/回滚全链路可追溯；订阅方能收到变更并理解可信度。
 
 ## 6. 非功能目标（初步）
 
@@ -96,6 +348,41 @@
 - 可追溯：关键状态变化具备审计记录。
 - 安全性：统一认证鉴权与最小权限控制。
 
+### 6.2 对外接口（MVP 合同口径）
+
+MVP 对外提供“查询 + 订阅”两类能力，并明确北向治理边界：
+
+- **北向入口**：统一经 API Gateway（Kong）进入，执行认证鉴权、限流、审计与路由治理。
+- **接口形态**：
+  - REST：面向外部系统的标准查询与批量拉取。
+  - GraphQL（Hasura）：面向运营终端与需要实时订阅的消费者，提供订阅与细粒度字段选择。
+
+#### 6.2.1 查询（Query）最小约束
+
+- 核心查询对象：Flight（当前态）、Milestone（明细/时间序列）、ResourceAssignment（生效集）、Alert（生命周期）。
+- 过滤维度：`op_date`、`flight_key/flight_id`、状态（Planned/Active/Completed/Cancelled）、资源类型与资源编号。
+- 分页与一致性：必须支持稳定分页（cursor/offset 任选其一作为主选并写清），并能返回“数据版本/更新时间”以支持下游对账。
+- 数据质量：关键字段必须返回 `source/confidence`，存在冲突时必须返回“冲突标记/待裁决标记”。
+
+#### 6.2.2 订阅（Subscription）最小约束
+
+- 订阅源：以 AODB 标准化业务事件为事实流（见 4.3 事件契约）。
+- 订阅粒度：按 `event_type` 与 `flight_id/op_date` 过滤；支持“关键事件流”订阅（只推 Flight/Milestone/Resource/Alert 的变更摘要）。
+- 可靠性：至少提供 at-least-once 投递语义；订阅必须支持断线重连与补偿（基于 `event_id` 或可回放游标）。
+- 限流与隔离：对外订阅连接数、推送速率、单租户资源上限必须可配置并可观测。
+
+#### 6.2.3 鉴权、限流与审计（Kong 治理边界）
+
+- 鉴权：OIDC/OAuth2（Keycloak）为统一入口；按角色/Scope 控制 Flight/Resource/Alert 的读写与订阅权限。
+- 限流：对“查询 QPS、订阅连接数、推送速率”分别限流，且需要能按租户/客户端维度配置。
+- 审计：所有“写入类操作”（包含人工裁决、资源覆盖、告警处置）必须审计；对外查询/订阅的访问也需记录最小审计日志（用于追溯与合规）。
+
+### 6.3 安全与合规（MVP）
+
+- 认证授权：OIDC/OAuth2 + RBAC（Keycloak），最小权限原则。
+- 传输安全：北向 TLS；服务间建议启用 mTLS（与服务网格能力对齐）。
+- 数据分级：至少区分“运营敏感字段”和“可共享字段”，并在接口层实现字段级权限控制（GraphQL 尤其需要明确）。
+
 ### 6.1 最小 SLO（评审口径）
 
 | 指标         | 目标值                        | 最低可接受值                  |
@@ -105,6 +392,47 @@
 | 容灾恢复     | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
 | 审计覆盖率   | 100% 关键变更可追溯           | 99.9% 可追溯                  |
 
+### 6.4 验收与可观测口径（MVP）
+
+为确保 SLO 可被验证，MVP 至少需要定义并采集以下运行指标：
+
+- 事件端到端延迟：ingest → commit(CurrentState/Outbox) → publish(Kafka) → deliver(订阅端)（按 P95/P99 统计）。
+- DLQ 率：解析失败/校验失败/旁路审计占比与趋势。
+- 幂等命中率：重复事件去重命中比例（用于评估上游质量与系统健壮性）。
+- 冲突率与 MTTR：资源冲突/里程碑冲突发生频率与平均处置时间。
+- 订阅健康：订阅连接数、推送速率、订阅落后量（按租户/客户端）。
+
+验收方式（与需求对齐）：
+
+- 压测：在峰值吞吐假设下验证 P95 延迟达标。
+- 对账与抽检：验证强一致实体与最终一致收敛（<= 30 秒）的抽样结果可解释。
+- 容灾演练：验证 RTO/RPO 达到最低可接受值并留存演练记录。
+
+### 6.5 容量基线与伸缩策略（MVP 口径）
+
+本节用于把“500 万至 3000 万吞吐机场”的范围，映射为可评审、可压测的容量假设（范围值即可，后续以压测修正）。
+
+#### 6.5.1 容量假设（建议范围）
+
+- 航班量：约 150–900 架次/日（按机场规模与航班结构波动）。
+- 事件密度：每航班 20–80 条关键事件（计划导入、动态更新、里程碑、资源变更、告警与裁决）。
+- 峰值事件速率：10–200 events/s（含短时抖动与重放）。
+- 订阅规模：10–500 并发订阅连接（运营终端、航司、地服、AOC 等），推送速率按租户限额。
+
+#### 6.5.2 伸缩策略（高层约束）
+
+- 事件骨干（Kafka）：按 `flight_id` 分区保证同航班顺序；通过增加分区与消费组并行度扩展吞吐。
+- 流处理（Flink）：关键作业（预测/CEP/聚合）支持水平扩展；必须具备状态一致性与可恢复能力（与 RTO/RPO 对齐）。
+- 事务库（PostgreSQL/TimescaleDB）：写路径优先保证强一致与审计；读路径通过缓存与只读副本（可选）缓解压力。
+- 检索（OpenSearch）：仅承载检索/分析投影，不作为强一致事实源；索引延迟纳入最终一致指标。
+
+#### 6.5.3 压测口径（最小）
+
+- 压测必须覆盖：
+  - 峰值事件速率 + 乱序/重复输入（验证幂等与乱序策略）。
+  - 订阅并发 + 推送速率上限（验证网关限流与订阅补偿）。
+  - DLQ 率提升场景（验证人工复核闭环与系统降级）。
+
 ## 7. 迭代方向
 
 Phase 1：完成 MVP 闭环并上线单机场。