# SSP 文件解析器（白話需求草稿 — 已歸檔）

> **狀態**：Phase 1 brainstorming 已完成，spec 已細化為 [api-spec.md](../api-spec.md)
> **歸檔日期**：2026-04-30
> **撰寫人**：raymond
>
> 以下為原始白話需求，作為溯源參考。最新可執行 spec 請見 [`api-spec.md`](../api-spec.md)（SA） 與後續的 `design.md`（SD）。
>
> **Phase 1 brainstorm 修正了三點原始想法**（不再採用）：
>
> 1. ~~OSCAL JSON 匯出沿用既有邏輯~~ — 既有匯出邏輯不存在，v1 不做、留 v2
> 2. ~~系統元件 / 軟體元件 / 外部系統結構化抽取~~ — 範例 docx 該章節多半是敘述，無結構，v1 跳過
> 3. ~~LLM 輔助解析~~ — v1 純規則 + 拖拉指派，LLM 留 v2 候選
>
> 詳見 [`api-spec.md` §1.2](../api-spec.md)。

---

## 我想解決什麼問題

客戶（資安顧問 / 受評公司）目前都用 Word 寫 SSP（System Security Plan）。
他們把寫好的 docx 上傳到 Guidant AI 後，希望系統能：

1. **自動把控制項段落抓出來**，對應到指定的合規規範(NIST 800-171 / CMMC / ISO27001 )控制項目錄
2. **抽取每個控制項的「實作描述（control implementation statement）」**，填到對應的 SSP control implementation 欄位
3. **遇到對應不到的段落**（章節標題不規則、段落混排），顯示在「待人工確認清單」，讓使用者拖拉指定歸屬
4. **再多分析其他可用資訊** 文件內可能會有系統元件, 軟體元件或是其他系統環境章節內的資訊, 是否可以在拆解出來, 放入SSP相關的物件內, 也在確認系統內有沒有對應的資料可以存放, 沒有的話可以討論是否新增

## 客戶情境

- 顧問拿到客戶寫好的 docx，丟進系統 → 期望看到自動對應結果
- 客戶自己寫 SSP，邊寫邊上傳更新 → 系統需要支援 **重新解析** 而不覆蓋使用者已手動編輯的部分


## 預期效果

- 「上傳 → 自動解析 → 呈現解析結果 → 使用者只需確認 / 微調」
- 比起目前「人工逐條 copy-paste」，預期省 70% 時間
- 解析結果要能轉成 OSCAL JSON 匯出（後段流程沿用既有匯出邏輯）
- 自動辨識文件內 control, ao 的現況說明, 並可自動填入

## 已知限制 / 風險（白話想法，待精化）

- docx 章節標題格式各家寫法不一（有人用 "3.1.1 AC-1"、有人寫 "Access Control - AC-01"）→ 需要 fuzzy match
- 表格內的控制項描述抽取可能不準
- 同一個控制項在 docx 內可能被拆到多個段落，要能合併

## 參考資料

- 客戶範本：[`reference/ASIA-CMMC-SSP-DRAFT-202604.docx`](./reference/ASIA-CMMC-SSP-DRAFT-202604.docx)（CMMC Asia draft，作為主要解析目標）
- 既有的 SSP control implementation 模型：jedi-oscal 內的infra.model的資料

## UI 想法（粗略）

1. 在合規資源庫, 新增/編輯 資源庫現況資料時, 可以允許匯入docx, 目前只有針對excel處理
2. 在專案規劃頁面, 規劃專案內容時, 可以允許匯入docx, 目前只有針對excel處理
3. 匯入後要有預覽以及即時編輯的UI
4. 再幫我想設計看看有沒有其他更好的方式

## 其他事項

1. 幫我分析後, 列出要決策的項目, 我們逐項討論
2. 你可以先拿範例文件來分析, 這個規格可能隨時會再更新, 我們先出這一版
3. 如果有建議的docx的格式, 也可以討論, 目前還在定義這份範例文件