Jyotisha/references/event_judgment_marriage.md

# Marriage Event Adjudicator v1.0

> 这是 `relationship` 题目域的专用裁决器。用于婚恋、婚姻、配偶、正式关系、关系转正、长期关系是否成立等问题。

---

## 1. Route Freeze

婚恋问题的**第一句**必须冻结事件类，然后再冻结任务类型与粒度。

先冻结四件事：

1. **事件类（强制，第一句写出）**
   - `romantic_activation`（心动 / 类似感情触发）
   - `relationship_formation`（成对 · 契约 / 正式配对）
   - `legal_marriage`（法律婚）
   - 可选上下文：`public_formalization`（社会公开/婚礼安排，不等于关系成立日）
2. **任务类型**
   - `prediction`
   - `backtest`
   - `rectification_support`
   - `multi-option adjudication`
3. **目标粒度**
   - `trend`
   - `window`
   - `month_level`
   - `event_level verification`
4. **关系定义**
   - `legal marriage`
   - `formal partnership`
   - `sustained relationship`
   - `romantic activation only`

若关系定义或事件类不清，先说明判定对象再继续；不得把心动窗写成结婚窗。

---

## 2. Mandatory Layers

婚恋题目至少必须展开：

- `D1`: 7H / 7L / Venus / Jupiter / Mars / Moon / DK
- `D9`: Lagna / 7H / 7L / Venus-Jupiter / DK
- `UL`
- `Vimshottari + Narayana`
- `Transit / Double Transit`
- `Vivah Saham`
- `Functional Benefic/Malefic`
- `MEVG / Global Web Evidence`
- `Real Case Calibration`

若用户要求高严谨，还应尽量加：

- `KP 7H sub-lord`
- `Chara Dasha`
- `Argala on 7H / 7L / UL`

---

## 3. Evidence Ledger Roles

把婚恋证据按 4 种角色分类：

1. `promise`
   - 7H / 7L / DK / UL / D9 是否支持婚恋承诺
2. `activation`
   - Dasha / Transit / Double Transit / KP / Saham 是否激活
3. `manifestation`
   - 这些激活是否足以落到现实关系成立，而不是只表现为暧昧、吸引、情绪事件
4. `timing`
   - 若上三层成立，再给窗口或月份级判断

---

## 4. Marriage Adjudication Order

### 4.1 Promise

先问：

- 本命是否有婚恋承载力？
- D1 的 7H / 7L / Venus / Jupiter / DK 是否形成基本 promise？
- D9 是否支持，还是明显削弱？
- UL 是否支持“正式关系/婚姻质量”？

若 promise 本身薄弱，不得直接因为某段 Dasha 激活就断定“必然结婚”。

### 4.2 Activation

必须检查：

- `Vimshottari` 是否激活 7H / 7L / Venus / Jupiter / DK / UL
- `Narayana` 是否同向
- `Transit / Double Transit` 是否对 7H / 7L / DK / UL 有作用
- `Vivah Saham` 是否支持

若 `Vimshottari` 与 `Narayana` 明显相反，标记 `mixed` 或 `blocked`。

### 4.2.1 Non-Standard Proxy Activation

不要把婚期只限缩到 `Venus / Jupiter / Saturn`。

公开案例显示，`Mercury / Moon / Rahu / Ketu` 等非典型大运、小运也可能给出婚姻事件，但必须满足：

```text
active_lord not in {Venus, Jupiter, Saturn}
AND active_lord linked to any of {2H, 7H, 8H, 11H, 7L, Venus, Jupiter, DK, UL, A7, D9_7H, D9_7L}
AND supported by at least one of {PD/PrAD, Chara/Narayana, Transit/Double Transit, D9, UL/A7}
```

解释边界：

- `Rahu/Ketu` 型：更常见非常规、突然、异地/异文化、秘密性、压力或强吸引。
- `Mercury` 型：更常见网络、学习、工作协作、朋友介绍、沟通、文书渠道。
- `Moon` 型：更常见家庭、安全感、同居、情绪依赖、照顾与生活稳定。

机器可审计资料见：

```bash
python3 scripts/non_standard_marriage_trigger_audit.py --pretty
```

### 4.3 Manifestation

这一层专门防止“有窗口但没落地”。

要区分：

- `romantic activation`：5H / 5L / 7H Moon / Punarphoo（月土合 ≤10° 或土星回照本命月）
- `relationship formation`：7L / DK / UL 支持的成对、契约、排他关系
- `legal marriage`：D9 + UL + Vivah Saham + 双轨 Dasha
- `public formalization`

硬边界：

- Punarphoo 回照 ≠ 结婚
- 5L 大运 ≠ 法律婚
- **金星过本命月亮 ≠ 心动月**。7H Venus-to-Moon 大约每年一次；2019–2022 空窗每年都有贴月（2022-04-11 距角 0.00° 仍空），2026-02-13→18 距角 0.11° 用户确认零情感。只记观察，禁止写入 `romantic_hits`，禁止用它点月。
- 心动评分器与法律婚姻评分器分轨；负样本 / 非事件区间必须进表
- 未过 negative holdout 前，Punarphoo 与心动轨道只能标 `observation_only`
- **同构真实案例的婚恋粒度 = AD，不是月。** 土星 7 宫本垣只给「一对一很认真」，不给哪一年结婚。法律婚由触发 AD 兑现，不由 Saturn MD 整段兑现。女盘夫星=木星：夫星 MD 在且木星不弱 → 法律婚走木星季；夫星落陷且当前不在 Jupiter MD → 触发权交给 7L / 金星 AD。PD、每年一次的行运合相、金星贴本命月，都不是案例层用过的触发器。问「哪个月」时，若案例与本盘回测都只支持到 AD，必须停在窗口级，禁止另造月份代理层。

尤其对名人、公职人物、长期恋爱者，要警惕“关系已成立，但婚礼日期只是社会安排”。

### 4.4 Timing

只有在 Promise + Activation + Manifestation 都通过后，才给：

- 趋势级
- 窗口级（默认 = **AD**；同构真实案例的事件日全部落在 AD 内，不是落在某次行运合相上）
- 月份级（仅当本盘回测已证明某行运层能点月，且该层不是每年空转的合相）
- 事件验证级

若只能做到窗口级，必须明说不能上升到“具体婚礼日”，也不得用未验证的月份代理层硬压。

同构案例校准过的触发链（女盘 + 土星 7 宫主链）：

```text
MD = 时代 / 背景（土星大运 = 成对课题，不等于必婚年）
AD = 触发窗（法律婚 / 成对兑现的真实单位）
PD = 切段，不改事件类
Transit month = 默认不点月；禁止用每年一次的合相当月份开关
```

校准样本角色（只借机制，不借日历）：

- 夫星 Jupiter MD 内各 AD 兑现法律婚，入 Saturn MD 后改长期非婚伴侣 → 土星 7 宫不决定早晚
- Saturn–Venus AD 兑现法律婚并长期维持 → 金星 AD 可以是法律婚触发窗；触发 AD 比金星落宫更关键
- 同主链、同 Saturn MD、恋爱/有子仍未婚 → 到了土星大运 ≠ 必须领证

**结婚「年月」拆层（2026-09-04 实算，Raman 整宫）**：公开婚礼日落在触发 AD 内；PD 三场各不相同（Moon / Mercury / Ketu）；7 宫双过境 1 真 2 假。因此案例能借到当前目标盘的只有 **AD 这一层**，不能把某场婚礼的 PD 或双过境当月份开关。Sagan 二婚日 1962-01-10 落在 Jupiter–Sun AD（Moon AD 1962-04-13 才起），旧报告「1962=Moon AD」是年标签，不是婚礼日标签。

**认识 / 恋爱 / 领证不得挤进同一段 AD、更不得挤进同一个月。** 同构样本显示三步可以跨 AD，甚至跨 MD：

- 认识对象 ≠ 心动月 ≠ 恋爱开始 ≠ 领证。公开日能核到的只有：订婚/公开成对、恋爱起止（粗）、婚礼日。
- 认识可以落在领证 AD **之前**的一段（样本：拍戏认识在上一段 MD 末 AD，正式恋爱在下一段 Saturn AD）。
- 恋爱可以在土星大运里走完数年仍不领证。
- 领证仍只给到触发 AD，不给月。

禁止把「相识高峰 / 恋爱季 / 领证月」写成 Venus AD 内三个连续月份。

---

## 5. Template Hooks

优先调用并引用：

- `darakaraka_ul_spouse_depth`
- `strict-workflow-router.md` 的 `relationship-timing-strict`
- `marriage-timing-validation-methodology.md`

若调用不到，必须在 Audit Table 里标注其对置信度的削弱。

---

## 6. Output Contract

婚恋输出最少要有：

1. `relationship verdict`
2. `confidence`
3. `main conflicts`
4. `Technique Audit Table`
5. `raw evidence`
6. `MEVG / Global Web Evidence`
7. `Real Case Calibration`

`MEVG / Global Web Evidence` 必须复用
`references/mandatory-verification-gate-protocol.md`，至少说明 source tier、
global web evidence collection、conflict arbitration 和未验证声明如何降级。

`Real Case Calibration` 必须给出真实案例参考、公开 benchmark case，或明确的
case gap。没有可比案例时不得假装完成，应降低置信度。

pure calculation exemption 只适用于纯计算、纯代码、纯项目维护或不解释运势意义的原始
数据输出；一旦解释婚恋运势、关系窗口或婚期，必须执行 MEVG 与真实案例校正。

示例 verdict：

- `high_probability_window`
- `moderate_probability_window`
- `weak_window_needs_confirmation`
- `insufficient_evidence`
- `blocked`

---

## 7. Must-Not-Overclaim

以下情况必须降级或阻断：

- 只看 `Vimshottari` 没看 `Narayana`
- 只看 `DK` 没看 `UL/D9`
- 只看 `Double Transit` 就断婚期
- 只看单一文章规则
- 未说明 birth time precision
- 未说明 `Ayanamsa / Node mode`
- 未完成 `MEVG / Global Web Evidence`
- 未完成 `Real Case Calibration`