上一篇恒川工業(yè)用 Decision-back Canvas 從 Outcome 和缺料決定反推出一個關(guān)鍵動詞供應(yīng)鏈經(jīng)理要批準方案AP-2048?，F(xiàn)在經(jīng)理在處置應(yīng)用里點擊“批準”。按鈕變綠頁面提示成功。十分鐘后WMS 沒有調(diào)撥任務(wù)ERP 沒有執(zhí)行記錄缺料事件SD-260808-01卻已經(jīng)顯示“已完成”。按鈕完成了交互業(yè)務(wù)沒有完成操作。這正是傳統(tǒng)功能需求最容易遺漏的地方它寫清用戶點什么、頁面顯示什么卻沒有完整定義這次操作作用于誰、什么條件下允許發(fā)生、改變什么狀態(tài)、誰有權(quán)執(zhí)行、失敗后怎么辦以及如何證明它真的發(fā)生過。本篇要解決的問題Action 不是給按鈕換一個高級名字。本篇要回答Action 在 Ontology 和 Palantir 架構(gòu)中處于什么位置Action Type、一次 Action submission、Function、Automation、side effect 和 Writeback 各自負責(zé)什么BA 怎樣把一句用戶故事升級為可配置、可測試、可審計的業(yè)務(wù)操作契約。一句話定義Action 是在 Ontology 中按照明確目標、參數(shù)、規(guī)則、權(quán)限和審計要求改變業(yè)務(wù)對象狀態(tài)的一次受控事務(wù)Action Type 則是這類業(yè)務(wù)操作可復(fù)用的定義。先把 Action 放回 OntologyPalantir Ontology 用 Object、Property 與 Link 表達企業(yè)世界中的“名詞”用 Action Type 表達用戶可以怎樣改變這個世界。官方把 Action 描述為基于用戶定義邏輯、改變一個或多個對象屬性的一次事務(wù)Action Type 定義可一并進行的 Object、Property value 與 Link 編輯以及提交時的 side effects。PalantirAction types overview從概念類型看Action Type 屬于OntologyLanguage 的操作構(gòu)件配置后由 Ontology Engine 執(zhí)行并受安全機制約束。它建立在 Object Type、Property、Link、規(guī)則或 Function 之上再被 Workshop、Object Explorer、自定義應(yīng)用、Automate 或受控 Agent 等入口調(diào)用。Foundry / Palantir 架構(gòu) └─ Ontology System ├─ 語義目標Object、Property、Link ├─ 操作定義Action Type │ ├─ Parameters │ ├─ Submission criteria │ ├─ Rules 或 backing Function │ ├─ Permissions / authorizations │ ├─ Edits 與 side effects │ └─ Action log / monitoring └─ 一次運行Action submission └─ 由人、應(yīng)用、Automate 或受控 Agent 發(fā)起在產(chǎn)品中建設(shè)者通常在 Ontology Manager 中配置 Action Type 的目標、參數(shù)、規(guī)則、條件與 side effects。運營用戶不會直接編輯這份定義而是在 Workshop 等應(yīng)用中填寫參數(shù)并提交同一個 Action Type 也可以被其他受支持入口復(fù)用。因此Action 的上級是 Ontology System其基礎(chǔ)是業(yè)務(wù)對象、邏輯和權(quán)限其下游消費者是應(yīng)用、自動化與 Agent。它不是 Foundry 的平級平臺也不是外部系統(tǒng) API 的別名。七個相鄰詞一次分清最有效的辨析方式是讓這些詞處理同一個恒川動作“批準AP-2048中 520 EA 的跨倉調(diào)撥”。520 EA 為本篇教學(xué)場景假設(shè)因超過恒川 500 EA 閾值必須由 Supply Chain Manager 復(fù)核。名詞類型負責(zé)回答什么在AP-2048中的形態(tài)Button / Form界面入口用戶從哪里發(fā)起Workshop 的“批準方案”按鈕與參數(shù)表單Action TypeOntology Language 構(gòu)件允許執(zhí)行哪一類業(yè)務(wù)操作Approve Allocation Proposal的目標、參數(shù)、校驗、權(quán)限和效果定義Action submission運行事件/一次事務(wù)誰在何時用什么參數(shù)執(zhí)行某經(jīng)理在 10:32 對AP-2048提交批準Function邏輯單元怎樣計算、判斷或生成復(fù)雜編輯計算受影響訂單或生成多對象狀態(tài)更新API / Webhook集成機制數(shù)據(jù)怎樣送到外部系統(tǒng)把調(diào)撥請求送往 WMS 或 ERPside effectAction 提交的附加效果Ontology 編輯之外還觸發(fā)什么通知倉儲負責(zé)人或調(diào)用 WebhookAutomate業(yè)務(wù)自動化應(yīng)用/資源何時自動檢查條件并觸發(fā)效果檢測高風(fēng)險缺料后創(chuàng)建任務(wù)不改寫 Action 契約Writeback本系列的問題域/實施術(shù)語批準后的狀態(tài)到底寫到哪里、如何對賬Ontology edit、WMS/ERP 寫入、失敗重試和人工復(fù)核的整體設(shè)計幾個邊界必須守住。按鈕不是 Action。按鈕可以改版、遷移或被 Agent 工具替代Action Type 的業(yè)務(wù)語義仍應(yīng)穩(wěn)定。Function 不是 Action。Function 可以計算建議也可以支撐復(fù)雜對象編輯但“算出 520 EA”不等于“有權(quán)批準 520 EA”。Automate 不是 Action。Automate 定義何時自動檢查條件并執(zhí)行效果其中一種效果是提交 Action它不會因此取代 Action 的目標、校驗和授權(quán)。PalantirAutomate overviewWebhook 不是完整 Writeback。Webhook 只是向外發(fā)送請求的一種機制。System of Record、冪等、并發(fā)、補償、重試、對賬和人工退出仍需另行設(shè)計。從用戶故事走向狀態(tài)契約普通用戶故事可能這樣寫作為供應(yīng)鏈經(jīng)理我希望批準調(diào)撥方案以便降低客戶訂單延期影響。它說明了角色、意圖和價值卻不足以進入生產(chǎn)。BA 應(yīng)先寫狀態(tài)變化再展開契約字段。先寫狀態(tài)機不要先畫表單對恒川缺料處置統(tǒng)一狀態(tài)應(yīng)是Supply Disruption / Allocation Proposal Detected → Assessed → Options Prepared → Pending Approval ├→ Rejected └→ Approved ↓ Writeback In Progress ↓ Executed / Partially Failed / Failed ↓ Reconciled → Closed本篇 Action 的直接職責(zé)是把滿足條件的AP-2048從Pending Approval推到Approved并保存批準上下文、創(chuàng)建或觸發(fā)后續(xù)執(zhí)行請求。它不能在外部系統(tǒng)尚未確認時直接把事件寫成Executed。Approved ≠ Executed。前者是業(yè)務(wù)決定通過后者是目標系統(tǒng)已經(jīng)完成并經(jīng)對賬確認。兩種狀態(tài)合并是運營應(yīng)用最危險也最常見的假成功之一。這個狀態(tài)機迫使團隊回答誰能推動哪次遷移遷移前必須滿足什么Ontology 編輯與外部執(zhí)行如何區(qū)分部分失敗后能否恢復(fù)。Action Contract 的十三項核心內(nèi)容1. Name 與 Owner操作叫什么誰擁有定義名稱要用業(yè)務(wù)動詞加對象例如“批準調(diào)撥方案”而不是submitButton2或“調(diào)用 ERP 接口”。Owner 要對業(yè)務(wù)含義、規(guī)則和變更負責(zé)不只是頁面負責(zé)人。2. Target這次操作作用于什么目標對象是Allocation Proposal AP-2048與關(guān)聯(lián)的Supply Disruption SD-260808-01。若 Action 還修改多個訂單、庫存分配或執(zhí)行請求要逐項寫明不能用“更新相關(guān)數(shù)據(jù)”代替。3. Parameters提交者必須提供什么恒川參數(shù)包括來源倉WH-S02、目標倉WH-E01、數(shù)量 520 EA、生效時間和批準理由。參數(shù)不是頁面字段清單每項還要定義類型、單位、是否必填、可選范圍和來源。4. Submission criteria什么時候允許提交Submission criteria 是決定一次 Action 能否提交的條件可結(jié)合當前用戶、參數(shù)、對象與關(guān)系信息表達業(yè)務(wù)限制。它與誰能編輯 Action Type 定義的權(quán)限相互獨立。PalantirSubmission criteria恒川至少檢查方案仍為Pending Approval缺料事件未關(guān)閉排產(chǎn)未凍結(jié)數(shù)量不超過當前可用量來源倉與目標倉不同當數(shù)量超過 500 EA 時當前用戶滿足經(jīng)理復(fù)核條件。這些不是瀏覽器里的表單提示。無論 Action 從 Workshop、API、Automate 還是受控 Agent 入口提交都應(yīng)遵守同一業(yè)務(wù)約束。5. Permission 與 authorization誰能看、配、提、批、做官方權(quán)限文檔區(qū)分誰能查看 Action Type、誰能編輯定義以及誰能用一組參數(shù) Apply Action。提交者還要能訪問被編輯的 Object/Link 及相應(yīng) datasource并通過 submission criteriaread/write authorizations 還會約束標記數(shù)據(jù)的讀取與寫入。PalantirAction permissions恒川不能只寫“供應(yīng)鏈團隊可操作”。至少拆成Supply Planner 可準備并提交方案Supply Chain Manager 復(fù)核超過 500 EA 的高影響調(diào)撥Warehouse Coordinator 處理倉儲執(zhí)行Agent 默認只能解釋和建議不能自行繞過審批。6. Rule / Function狀態(tài)怎樣改變簡單 Action 可用 rules 創(chuàng)建、修改、刪除 Object 或 Link。若要讀取多對象、執(zhí)行復(fù)雜計算或同時創(chuàng)建多類對象可以使用 Function-backed Action它仍受 Action 與 Function 的執(zhí)行限制。PalantirFunction-backed actionsAP-2048獲批時規(guī)則或 backing Function 至少要更新方案狀態(tài)、保存批準人和時間、關(guān)聯(lián)決策上下文并按恒川實現(xiàn)創(chuàng)建WR-2048-*執(zhí)行跟蹤對象。Writeback Request是本系列實施性對象不是 Palantir 固定對象模型。7. Transaction boundary哪些編輯必須一起成功Action 在 Ontology 內(nèi)是一次事務(wù)但跨 Ontology、WMS 與 ERP 的端到端過程不應(yīng)被想當然地視為單一原子事務(wù)。BA 要明確哪些對象編輯必須共同成功哪些外部效果可以異步失敗時狀態(tài)落在哪里。8. Side effectsOntology 之外還發(fā)生什么Action Type 可配置 notification 和 Webhook 等 side effects把數(shù)據(jù)送出 Foundry并連接既有流程。官方把外部系統(tǒng)仍是 source of truth 時的這種模式稱為 decision orchestration。PalantirSide effectsSide effect 與 Ontology 編輯并不天然同成同敗。官方權(quán)限頁明確指出通知失敗時 edits 仍可能成功。因此契約必須定義Ontology 已批準但通知或 WMS 請求失敗顯示Partially Failed、Failed還是等待重試誰收到告警何時轉(zhuǎn)人工。9. System of Record哪個系統(tǒng)擁有哪個事實恒川的方案審批和處置運行狀態(tài)可以由 Ontology 承載ERP 仍擁有訂單與采購承諾WMS 仍擁有倉儲執(zhí)行事實。Action 不會自動替企業(yè)決定誰是權(quán)威賬本。10. Failure、retry 與 compensation失敗怎樣恢復(fù)用戶參數(shù)錯誤、庫存已被他人占用、權(quán)限不足、WMS 超時與 WMS 明確拒絕是不同失敗。每一類都要有錯誤狀態(tài)、用戶提示、Owner、重試條件、重復(fù)請求處理和人工退出路徑。本篇不展開 Writeback 技術(shù)方案但 Action Contract 至少要保存冪等標識、外部關(guān)聯(lián)號和補償責(zé)任避免重試生成重復(fù)調(diào)撥任務(wù)。11. Audit怎樣重建當時的決定Action log 可把每次 submission 建模為可分析的對象并連接被編輯對象。官方文檔列出的默認信息包括 submission RID、Action Type RID 與版本、時間、提交用戶、被編輯對象主鍵以及可選摘要和參數(shù)值還可以保存相關(guān)決策上下文。PalantirAction logBA 應(yīng)定義未來復(fù)盤要回答什么誰基于哪版AP-2048批準看到的庫存更新時間是什么為什么覆蓋系統(tǒng)建議最終影響哪些訂單。Edit history 可以回答更廣泛的對象編輯歷史但不替代一項決定需要保存的業(yè)務(wù)理由。12. Outcome技術(shù)成功后業(yè)務(wù)有沒有改善“Action submission 成功”只能證明一次操作被接受。處置時長是否縮短、重點訂單延期影響是否下降、部分失敗率是否可控才說明業(yè)務(wù) Outcome 是否改變。13. Acceptance怎樣證明整份契約成立正常路徑只是起點。驗收必須覆蓋越權(quán)、條件失效、并發(fā)變化、部分失敗、重復(fù)請求和審計復(fù)盤。BA 工作臺恒川 Action Contract契約項Approve Allocation Proposal填寫樣例Business name / Owner批準調(diào)撥方案Supply Chain ManagerTrigger / callerPlanner 提交后由 Manager 復(fù)核高影響方案不可由 Agent 自動批準TargetAP-2048、SD-260808-01ParametersWH-S02 → WH-E01、520 EA、生效時間、批準理由State transitionPending Approval → Approved外部執(zhí)行另進Writeback In ProgressSubmission criteria方案待審批、事件未關(guān)閉、未過凍結(jié)點、數(shù)量未超可用量、500 EA 經(jīng)理復(fù)核Permission / authorizationPlanner 提交Manager 批準Warehouse 執(zhí)行讀取和寫入遵守對象、datasource 與標記數(shù)據(jù)授權(quán)Rules / Function更新審批狀態(tài)記錄批準上下文按實施設(shè)計創(chuàng)建WR-2048-*Transaction boundary方案狀態(tài)與批準記錄共同成功外部 WMS/ERP 執(zhí)行單獨跟蹤Side effects通知倉儲通過受控 Webhook/API 請求外部執(zhí)行System of RecordOntology決定與運行狀態(tài)WMS倉儲執(zhí)行ERP訂單和采購承諾Failure / recovery外部失敗不偽裝成功冪等重試超限或拒絕轉(zhuǎn)人工復(fù)核AuditAction 版本、參數(shù)、用戶、時間、方案版本、庫存時間點、受影響對象Outcome決策耗時、執(zhí)行成功率、訂單延期影響、人工返工率Action Contract是本系列面向 BA 的實施模板不是 Palantir 官方固定表單。它的作用是讓業(yè)務(wù)、BA、Ontology、應(yīng)用與集成團隊對同一個操作給出同一答案。把契約直接變成驗收場景場景前置條件操作預(yù)期結(jié)果正常批準AP-2048待審批520 EA 可用排產(chǎn)未凍結(jié)Manager 批準狀態(tài)進入Approved保存日志并發(fā)起后續(xù)執(zhí)行不提前顯示Executed越權(quán)提交Planner 只有提交權(quán)Planner 嘗試批準阻斷操作說明所需權(quán)限不產(chǎn)生 edits 或 side effects條件失效頁面打開后庫存被占用或排產(chǎn)凍結(jié)提交舊方案criteria 失敗提示重新評估不執(zhí)行舊參數(shù)部分失敗Ontology 審批已成功WMS 請求失敗接收失敗回執(zhí)進入可識別的失敗狀態(tài)保留原因、外部關(guān)聯(lián)號與責(zé)任人重復(fù)請求同一方案和冪等標識已有結(jié)果再次提交不重復(fù)生成外部任務(wù)返回已有結(jié)果或明確阻斷審計復(fù)盤處置已對賬查詢記錄可還原誰、何時、用哪版方案和證據(jù)、影響哪些對象若團隊無法寫出某一行的預(yù)期結(jié)果問題通常不在測試腳本而在 Action 的業(yè)務(wù)契約還沒有達成共識。三條生產(chǎn)邊界事務(wù)邊界。一個按鈕不代表多個企業(yè)系統(tǒng)天然屬于一個原子事務(wù)。先定義 Ontology 內(nèi)必須共同成功的編輯再定義外部執(zhí)行與恢復(fù)。授權(quán)邊界。能看到對象、能運行 Function、能提交建議、能批準和能執(zhí)行是不同權(quán)力。尤其 Agent 參與時工具可見不等于自動獲得高影響操作權(quán)。記錄邊界。當前狀態(tài)可以繼續(xù)變化但當時的參數(shù)、版本、批準理由與執(zhí)行結(jié)果不能被后續(xù)覆蓋成一條模糊的“已完成”?；氐介_頭Action 為什么是操作契約如果需求只寫“點擊批準后提示成功”它描述的是交互。只有當 Target、Parameters、criteria、權(quán)限、狀態(tài)遷移、事務(wù)、side effects、System of Record、失敗、審計和 Outcome 都能被共同解釋和驗收時它才描述了一項業(yè)務(wù)操作。Action Type 把這份穩(wěn)定語義放進 Ontology一次 Action submission 則讓具體的人、對象、參數(shù)與時間進入運行和審計。頁面可以變化調(diào)用入口可以增加外部系統(tǒng)也可能替換但業(yè)務(wù)操作的核心契約仍然清楚。本文依據(jù) Palantir 公開資料與實施研究整理與 Palantir Technologies 無官方關(guān)聯(lián)。恒川工業(yè)及其編號和數(shù)據(jù)均為虛構(gòu)教學(xué)案例Action Contract、Writeback Request和本篇狀態(tài)機不是 Palantir 官方固定產(chǎn)品模型或模板。產(chǎn)品能力與授權(quán)模型可能變化請以官方文檔和具體環(huán)境為準。