呢個係 illustrative scenario，唔係 customer story。 佢冇使用真實 organization、真實人物，亦冇 claimed results。目的係展示 Threada executable Vendor Security pack 點樣將 routine security review 由 request 帶到 recorded decision。下面描述嘅每個 surface 都係真實 product capability；情境係為 illustration 而創作。
Security teams 每週花好多時間喺 reviews 上，呢啲 reviews 多數 routine，但間中好嚴重。新 SaaS tool 需要 sign-off。Vendor 想 process customer data。有人要求偏離 standing policy。大部分都有已知形狀；少部分需要真正 scrutiny。難處通常唔係 analysis — 而係令每個 review 都 consistent、grounded in evidence、on the record。
以下係呢件工作點樣喺 Threada 嘅 Vendor Security pack 入面運行。
工作嘅形狀
Vendor Security 係一個 workspace pack，帶 case archetype 同三個 defined intents：
- Vendor review — 對新 vendor 或續約 vendor 按 policy 評估。
- Data processing review — 評估 vendor 可唔可以 process 指定 data。
- Security exception — 處理偏離 standing control 嘅 request。
Reviewer 唔需要決定開邊個 form。佢講 intent，runtime 就將佢轉成 security queue 上嘅 structured WorkItem。
Walkthrough
想像一個 request 到達：一個 team 想採用新 analytics vendor，呢個 vendor 會收到 product usage data。喺呢個 scenario 入面，request 透過 configured intake channel 落地，變成 WorkItem。
Intent. Reviewer，或者 requester 透過 channel，描述佢需要嘅 outcome — “review this analytics vendor for data processing approval.” Runtime extract vendor、涉及嘅 data categories 同 initial risk flag，然後 file 到 Vendor Security queue。
Canvas. WorkItem 打開到 adaptive canvas。唔係 blank form，workspace 會組裝呢類 review 需要嘅 fields：data categories、processing location、sub-processors、相關 policy profile。資料缺失時，佢只會問正缺失嗰樣，而唔係交出一份冇分別嘅 questionnaire。
Evidence. Evidence drawer 放住 assessment 站喺上面嘅嘢 — vendor submitted documentation、同一 vendor 嘅 prior reviews、以及適用 policy 嘅 citations。如果 system 無法 ground 某個 claim，佢會記錄 fallback reason，而唔係聲稱自己有冇嘅 confidence。Reviewer 一眼可以見到每個 source 幾 fresh。
Controls. 呢度 review 變成 decision。為新 vendor approve data processing 係 consequential action，所以要經 governed controls surface：先 proposal，再對 active policy version 做 explicit approval。如果 policy 要求呢個 data category 有第二個 approver，gate 會 enforce。冇任何嘢會靜靜 execute。
Run log. 每一步都累積到 run log — intake、missing-info prompts、consulted evidence、approval 同批准人、final recorded outcome。因為 AI participant actions 以 distinct actor events 出現，log 清楚顯示邊啲 steps 由 system 處理，邊啲由人決定。
Team 最後得到啲咩
到最後，security team 有三樣本來要人手組裝嘅嘢：
- Consistent review. 同一 intent 一定產生同一 workspace shape，所以 review rigor 唔會因為忙碌週或清閒週而漂移。
- Grounded decision. Approval 綁定到具體 evidence 同 named policy version，而唔係 reviewer 嘅記憶。
- Receipt. 整個 review 都 on the record — 對 auditor defendable，對下一位處理相似 case 嘅 reviewer 亦清楚。
Routine reviews 行得快，因為 workspace 做咗 assembly。嚴重 cases 得到完整 human scrutiny，因為 controls surface 堅持要。呢個 division — automate routine，route 真正困難嘅 cases 畀人 — 就係全部重點。
點解我哋用 scenario 發布
我哋可以將呢件事包裝成帶驚人百分比嘅 customer success story。我哋唔會。直到有真實、consenting customer 分享真實 results，我哋喺呢度寫嘅都係 illustration；我哋寧願誠實標籤佢，而唔係暗示自己未有嘅 proof。
真實存在嘅係 pack。Vendor Security 係 installable workflow，喺同其他 Threada packs 一樣嘅 governed runtime 上運行，並包含上面描述嘅 intents 同五個 surfaces。如果你想睇 executable version，而唔係 walkthrough，pack catalog 係開始嘅地方。