Build event adjudication skeleton for relationship and wealth

2026-06-27 21:28:55 +08:00
parent 79a6c8622b
commit f0dbee752c
10 changed files with 1021 additions and 5 deletions
@@ -1,13 +1,14 @@
 # AI解盘工作流Prompt工程（AI Reading Workflow）

 > **适用场景**：AI收到出生信息、PDF星盘或文字星盘后，如何一步步执行完整的解盘+推运分析
-> **版本**：v5.0.0 | **更新日期**：2026-04-27
+> **版本**：v5.1.0 | **更新日期**：2026-06-27
 > **来源标签**: 【工具/模板】 — AI解盘执行引擎工作流
 > **优先级**：⭐⭐⭐⭐⭐（AI解盘质量的决定性文件）
 > **定位**：本文件是AI解盘的**执行引擎**，将Skill中所有参考资料串联成可执行的工作流
 > **v3.0重大变更**：三条入口路径明确分流，引擎全自动计算无需用户逐模块触发
 > **v4.0重大变更**：Step 0.5 Karaka系统自动识别（解决DK摇摆问题）、预测输出强制[A/B/C]标注、统一精度边界声明、来源标签体系引用
 > **v5.0重大变更**：强制外部验证门控（MEVG）——新增核心原则"不凭记忆"、三个门控步骤（Step 3.11/4.10/5.5）嵌入工作流、与"不跳步"同级强制
+> **v5.1重大变更**：事件判定骨架接入主工作流——新增 `Route -> Evidence Ledger -> Adjudication -> Output Contract` 四段式事件裁决层，并引入 marriage 专用 adjudicator。

 ---

@@ -461,6 +462,33 @@ AI不应该凭空假设一个时间，而应该通过结构化互动帮助用户
 4. 重点展开当前Dasha激活的领域
 5. 主动提示用户可以深入询问任何领域

+### 2.3 事件判定骨架（v5.1 新增）
+
+凡是以下题型，必须进入事件判定骨架，不得只靠 `strict route` 后直接写结论：
+
+- marriage / relationship
+- career / offer / promotion / project landing
+- wealth / payment / gains / asset timing
+- generic event verification
+
+固定执行顺序：
+
+1. `Route`
+   - 先冻结 **问题域**、**任务类型**、**目标粒度**
+2. `Evidence Ledger`
+   - 把每个模块落成结构化证据块
+3. `Adjudication`
+   - 按 `Promise -> Activation -> Manifestation -> Timing`
+4. `Output Contract`
+   - 只输出 `verdict + confidence + conflicts + audit + raw evidence`
+
+详细协议：
+
+- `references/event_judgment_skeleton.md`
+- `references/event_judgment_marriage.md`
+
+若问题属于婚恋，必须再额外执行 `event_judgment_marriage.md` 的专用裁决器。
+
 ---

 ## 阶段三：静态星盘分析（→ 多个参考文件）
@@ -0,0 +1,118 @@
+# Event Judgment Examples v1.0
+
+> 作用：给事件判定骨架提供最小可执行范例，避免只停留在抽象规则。
+
+---
+
+## 示例一：婚恋窗口判断
+
+### 问题
+
+`When will I get married?`
+
+### Route
+
+- question_domain: `relationship`
+- task_type: `prediction`
+- target_granularity: `window`
+
+### Evidence Ledger（最小示例）
+
+```json
+[
+  {
+    "module": "relationship_timing",
+    "subtechnique": "d9_ul_dk",
+    "question_domain": "relationship",
+    "verdict_role": "promise",
+    "signal": "supportive",
+    "strength": 0.82,
+    "raw_values": {"d9": "present", "ul": "present", "dk": "present"},
+    "engine": "native",
+    "ayanamsa": "lahiri",
+    "node_mode": "mean",
+    "template_id": "darakaraka_ul_spouse_depth",
+    "case_ref_ids": ["marriage-timing-v6"],
+    "maturity": "covered",
+    "notes": ""
+  },
+  {
+    "module": "relationship_timing",
+    "subtechnique": "dual_dasha",
+    "question_domain": "relationship",
+    "verdict_role": "activation",
+    "signal": "supportive",
+    "strength": 0.78,
+    "raw_values": {"vimshottari": "Venus/Rahu", "narayana": "Pisces/Jupiter"},
+    "engine": "native",
+    "ayanamsa": "lahiri",
+    "node_mode": "mean",
+    "template_id": "darakaraka_ul_spouse_depth",
+    "case_ref_ids": [],
+    "maturity": "covered",
+    "notes": ""
+  }
+]
+```
+
+### Adjudication
+
+- Promise: pass
+- Activation: pass
+- Manifestation: partial
+- Timing: window only
+
+### Output Contract
+
+```json
+{
+  "event_family": "relationship",
+  "verdict": "moderate_probability_window",
+  "confidence": "B",
+  "conflicts": [],
+  "primary_drivers": ["d9_ul_dk", "dual_dasha"],
+  "missing_evidence": ["kp_7h_sub_lord"],
+  "raw_evidence_refs": ["full-reading.modules.jaimini.darakaraka", "full-reading.modules.dasa_convergence"]
+}
+```
+
+---
+
+## 示例二：财富窗口判断
+
+### 问题
+
+`When will my wealth grow?`
+
+### Route
+
+- question_domain: `wealth`
+- task_type: `prediction`
+- target_granularity: `window`
+
+### 关键约束
+
+- 必须 `D2 / D11`
+- 必须 `Vimshottari + Narayana`
+- 必须 `Shadbala + Ashtakavarga`
+- 若缺任一核心层，直接降为 `insufficient_evidence`
+
+---
+
+## 示例三：过去事件回测
+
+### 问题
+
+`Was my 2018 relationship event actually supported by the chart?`
+
+### Route
+
+- question_domain: `relationship`
+- task_type: `backtest`
+- target_granularity: `event_level verification`
+
+### 输出要求
+
+- 不只说“像不像”
+- 必须输出 `A / B / C / Fail`
+- 必须指出是 Promise 不足、Activation 不足，还是 Manifestation 不足
@@ -0,0 +1,156 @@
+# Marriage Event Adjudicator v1.0
+
+> 这是 `relationship` 题目域的专用裁决器。用于婚恋、婚姻、配偶、正式关系、关系转正、长期关系是否成立等问题。
+
+---
+
+## 1. Route Freeze
+
+先冻结三件事：
+
+1. **任务类型**
+   - `prediction`
+   - `backtest`
+   - `rectification_support`
+   - `multi-option adjudication`
+2. **目标粒度**
+   - `trend`
+   - `window`
+   - `month_level`
+   - `event_level verification`
+3. **关系定义**
+   - `legal marriage`
+   - `formal partnership`
+   - `sustained relationship`
+
+若关系定义不清，先说明判定对象再继续。
+
+---
+
+## 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`
+
+若用户要求高严谨，还应尽量加：
+
+- `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.3 Manifestation
+
+这一层专门防止“有窗口但没落地”。
+
+要区分：
+
+- `romantic activation`
+- `relationship formation`
+- `legal marriage`
+- `public formalization`
+
+尤其对名人、公职人物、长期恋爱者，要警惕“关系已成立，但婚礼日期只是社会安排”。
+
+### 4.4 Timing
+
+只有在 Promise + Activation + Manifestation 都通过后，才给：
+
+- 趋势级
+- 窗口级
+- 月份级
+- 事件验证级
+
+若只能做到窗口级，必须明说不能上升到“具体婚礼日”。
+
+---
+
+## 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`
+
+示例 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`
@@ -0,0 +1,153 @@
+# Event Judgment Skeleton v1.0
+
+> 用途：把分散在 `full-reading`、`dasha`、`jaimini`、`varga`、`kp`、`shadbala`、`ashtakavarga`、`references/verified-patterns-*` 中的证据，收束成统一的事件裁决链。
+> 适用：marriage / career / wealth / health / generic event verification
+
+---
+
+## 1. Route
+
+不要只按触发词路由。每次先识别三件事：
+
+1. **问题域**
+   - `relationship`
+   - `career`
+   - `wealth`
+   - `health`
+   - `generic_event`
+2. **任务类型**
+   - `prediction`
+   - `backtest`
+   - `rectification_support`
+   - `multi-option adjudication`
+3. **目标粒度**
+   - `trend`
+   - `window`
+   - `month_level`
+   - `event_level verification`
+
+若这三件事没有先冻结，不得继续下判。
+
+---
+
+## 2. Evidence Ledger
+
+每个模块必须变成结构化证据块，而不是散乱叙述。
+
+```json
+{
+  "module": "marriage_timing",
+  "subtechnique": "double_transit",
+  "question_domain": "relationship",
+  "verdict_role": "activation",
+  "signal": "supportive|mixed|contradictory|blocked",
+  "strength": 0.0,
+  "raw_values": {},
+  "engine": "native|pyjhora|vedastro|jyotishganit",
+  "ayanamsa": "lahiri",
+  "node_mode": "mean|true",
+  "template_id": "darakaraka_ul_spouse_depth",
+  "case_ref_ids": [],
+  "maturity": "complete|covered|partial",
+  "notes": ""
+}
+```
+
+最少要求：
+
+- `module`
+- `subtechnique`
+- `verdict_role`
+- `signal`
+- `strength`
+- `raw_values`
+- `engine`
+- `ayanamsa`
+- `node_mode`
+- `maturity`
+
+---
+
+## 3. Adjudication
+
+所有事件判断必须按以下顺序：
+
+1. **Promise**
+   - 本命是否有该主题的承载力？
+   - 禁止直接从 Dasha/Transit 跳到“会发生”
+2. **Activation**
+   - Dasha / Transit / Annual / Jaimini / KP 是否激活？
+3. **Manifestation**
+   - 是否足以落到现实事件，而不是只形成心理主题、机会接触或背景躁动？
+4. **Timing**
+   - 若 Promise + Activation + Manifestation 都成立，才进入 timing 窗口判定
+
+### 矛盾优先级
+
+若不同证据块冲突，按以下顺序裁决：
+
+1. `verified pattern / benchmark`
+2. `cross-system convergence`
+3. `classical rule with prerequisites satisfied`
+4. `single module output`
+
+若冲突无法裁决，必须输出 `blocked`。
+
+---
+
+## 4. Confidence Mapping
+
+置信度不得只按“有几个名人案例”判断，至少同时考虑以下 6 维：
+
+1. `benchmark/case support`
+2. `technique maturity`
+3. `cross-system convergence`
+4. `birth time precision`
+5. `oracle closure status`
+6. `contradiction severity`
+
+建议映射：
+
+- `A`：多案例 / benchmark 强支撑 + complete/covered + 多系统同向 + 参数清晰
+- `B`：部分案例支撑 + 多模块同向 + 仍有轻微边界
+- `C`：经典规则存在，但统计、闭环或关键层不足
+- `D`：仅单一模块、关键层缺失或矛盾明显
+
+---
+
+## 5. Output Contract
+
+最终输出必须包含：
+
+1. `verdict`
+2. `confidence`
+3. `conflicts`
+4. `Technique Audit Table`
+5. `raw evidence`
+
+最小 JSON 形态：
+
+```json
+{
+  "event_family": "relationship",
+  "verdict": "high_probability_window|moderate_probability_window|weak_window_needs_confirmation|insufficient_evidence|blocked",
+  "confidence": "A|B|C|D",
+  "conflicts": [],
+  "primary_drivers": [],
+  "missing_evidence": [],
+  "raw_evidence_refs": []
+}
+```
+
+---
+
+## 6. Hard Stops
+
+以下任一项未满足时，不得包装成高严谨结论：
+
+- 未显式声明 `Ayanamsa / Node mode`
+- 未显式声明 `Functional Benefic/Malefic`
+- timing 问题未完成 `Vimshottari + Narayana`
+- 题目域分盘未展开（relationship -> D9/UL；career -> D10/A10；wealth -> D2/D11）
+- 外部 oracle 未闭环却假装全局封顶
+- 缺少 `Technique Audit Table`
@@ -0,0 +1,199 @@
+# Wealth Event Adjudicator v1.0
+
+> 这是 `wealth` 题目域的专用裁决器。用于收入、财富积累、到账、套现、资产扩张、估值跃升、公众财富地位等问题。
+
+---
+
+## 1. Route Freeze
+
+先冻结三件事：
+
+1. **任务类型**
+   - `prediction`
+   - `backtest`
+   - `rectification_support`
+   - `multi-option adjudication`
+2. **目标粒度**
+   - `trend`
+   - `window`
+   - `month_level`
+   - `event_level verification`
+3. **财富事件标签**
+   - `income_growth`
+   - `asset_accumulation`
+   - `liquidity_cashout`
+   - `public_wealth_status`
+
+若财富事件标签不清，先说明判定对象再继续。
+
+---
+
+## 2. Four Wealth Layers
+
+财富题目固定拆成四层：
+
+1. `wealth promise`
+2. `wealth activation`
+3. `wealth manifestation`
+4. `payout label`
+
+### payout label 子类
+
+- `income_growth`：收入增长、薪资提升、持续现金流增强
+- `asset_accumulation`：资产沉淀、持仓扩大、房产/股权/长期财富积累
+- `liquidity_cashout`：到账、套现、融资落袋、出售变现
+- `public_wealth_status`：IPO、估值跃升、财富排行榜、公众财富可见度
+
+---
+
+## 3. Mandatory Layers
+
+财富题目至少必须展开：
+
+- `D1`: 2H / 11H / 5H / 9H / 10H / Jupiter / Venus / Mercury
+- `D2`
+- `D11`
+- `D10`（若财富来自职业兑现）
+- `Vimshottari + Narayana`
+- `Shadbala`
+- `Ashtakavarga`
+- `Functional Benefic/Malefic`
+
+高严谨时尽量补：
+
+- `Argala on 2H / 11H`
+- `A2 / A11 / A10`
+- `KP`
+- `Yogi / Dhana / Lakshmi template hooks`
+
+---
+
+## 4. Evidence Ledger Roles
+
+把财富证据按 4 种角色分类：
+
+1. `promise`
+   - 本命是否具备财富承载力或财富兑现潜力？
+2. `activation`
+   - Dasha / Transit / Annual / KP / Jaimini 是否点燃财富主题？
+3. `manifestation`
+   - 这些激活是否足以落到现实收益/资产/现金流，而不只是机会、焦虑或纸面波动？
+4. `payout_label`
+   - 最终更像哪一类财富事件：收入增长、资产积累、套现到账、公众财富地位？
+
+---
+
+## 5. Wealth Adjudication Order
+
+### 5.1 Promise
+
+先问：
+
+- 2H / 11H / 5H / 9H / 10H 是否给出财富承诺？
+- D1 的财富 promise 是否得到 `D2 / D11 / D10` 支持？
+- Jupiter / Venus / Mercury 在题目域里是增强器、兑现器还是干扰器？
+- 是否存在强财富模板钩子：
+  - `lakshmi_dhana_activation_chain`
+  - `yogi_asc_tight_orb_wealth`
+
+若本命 promise 薄弱，不得因为单次 transit 或单个 Dasha 就断定“发财”。
+
+### 5.2 Activation
+
+必须检查：
+
+- `Vimshottari` 是否激活 2L / 11L / 5L / 9L / 10L / Jupiter / Venus / Mercury
+- `Narayana` 是否同向
+- `Transit Jupiter / Saturn / nodes` 是否对 2H / 11H / 10H 有实质推动
+- `Shadbala / Ashtakavarga` 是否支持“强而可兑现”的状态
+
+若 `Vimshottari` 与 `Narayana` 明显冲突，标记 `mixed` 或 `blocked`。
+
+### 5.3 Manifestation
+
+这一层专门防止“有财运感，但没落到现实收益”。
+
+要区分：
+
+- `opportunity to earn`
+- `actual income growth`
+- `asset build-up`
+- `cash-out / liquidity event`
+- `public wealth visibility`
+
+### 5.4 Payout Label
+
+只有前三层通过后，才给最终财富事件标签。
+
+禁止把所有财富事件都压成一个粗糙的“发财”。
+
+---
+
+## 6. Defect Typology
+
+财富线沿用婚恋线的缺陷类型思路：
+
+1. `promise weak`
+2. `activation/convergence weak`
+3. `manifestation split`
+4. `payout-label failure`
+
+### payout-label failure
+
+定义：
+
+- 旧体系高分
+- 现实财富事件明确成立
+- 新聚合器没有把它抬成正确的财富标签
+
+这是财富线最重要的回归靶子之一。
+
+---
+
+## 7. Template Hooks
+
+优先调用并引用：
+
+- `lakshmi_dhana_activation_chain`
+- `yogi_asc_tight_orb_wealth`
+- `strict-workflow-router.md` 的 `wealth-timing-strict`
+- `divisional-chart-deep-reading.md` 中的财富链 `D2 -> D4 -> D10 -> D11`
+
+若调用不到，必须在 Audit Table 里标注其对置信度的削弱。
+
+---
+
+## 8. Output Contract
+
+财富输出最少要有：
+
+1. `wealth verdict`
+2. `confidence`
+3. `main conflicts`
+4. `Technique Audit Table`
+5. `raw evidence`
+
+示例 verdict：
+
+- `high_probability_window`
+- `moderate_probability_window`
+- `weak_window_needs_confirmation`
+- `insufficient_evidence`
+- `blocked`
+
+最终还要给出：
+
+- `payout_label`
+
+---
+
+## 9. Must-Not-Overclaim
+
+以下情况必须降级或阻断：
+
+- 只看 `Vimshottari` 没看 `Narayana`
+- 只看 `D1` 没展开 `D2 / D11`
+- 把事业曝光误当成财富兑现
+- 把纸面估值误当成流动性到账
+- 未说明 birth time precision
+- 未说明 `Ayanamsa / Node mode`
@@ -409,6 +409,9 @@ SCRIPT=~/.workbuddy/skills/jyotish-vedic-astrology/scripts/jyotish_engine.py
 ### AI解盘工作流（2个）
 0. **ai-reading-workflow-prompt.md**：AI解盘工作流Prompt工程（7阶段完整执行引擎）
 0b. **quick-reference-guide.md**：⭐执行总控指南（本文件）
+0c. **event_judgment_skeleton.md**：事件裁决总骨架（Route -> Evidence Ledger -> Adjudication -> Output Contract）
+0d. **event_judgment_marriage.md**：婚恋事件专用裁决器（Promise -> Activation -> Manifestation -> Timing）
+0e. **event_judgment_wealth.md**：财富事件专用裁决器（wealth promise -> activation -> manifestation -> payout label）

 ### 核心方法论（9个）
 1. **common-misconceptions.md**：印度占星常见误判与冲突问题集（错题本）⭐⭐⭐⭐⭐