案例引用深度跟著 case 類型走skeleton / medium / rich case 各有不同承接深度；誤判類型 → 編造數字 / taxonomy（over-extrapolation）或漏掉 case 揭露的 mechanism（under-citation）；引用前先看 case 行數 + 內容密度判類型、決定該寫『揭露 X 方向』還是『揭露 N 個機制』還是『揭露具體數字 / 設計』
跨多個 case 合成的 frame 必須標為章節合成、非 case 原文當段落把多個 case 的失效訊號抽象為更高層 frame（如『跨工具回查壓力』『平台責任切分』）、要 explicit 標為『本章合成、非 case 原文』；否則章節 derive 會被讀者當成 case fact、回查 case 時發現章節說的『揭露』實際是章節抽象、不是 case 原文框架
Standard-driven 取代 Case-driven 適用 standard framework 比 case 庫成熟的領域並非所有領域都該走 case-driven。判斷該用哪種策略看四維度：議題穩定度 / case 公開度 / standard 成熟度 / 維護半衰期。LLM 安全屬 standard-driven 領域（OWASP LLM Top 10 + NIST AI RMF 已成型、case 半衰期 6 個月）；分散式系統 / 安全控制面屬 case-driven 領域（case 公開充分、半衰期 5+ 年）。誤套會導致 case 庫過早建構或 case 過時
案例庫不對齊章節主題時用反向追問取代強掛當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度