假設我要把一則集合通知傳到另一個據點。按下送出後，畫面顯示成功，我便不再處理它。但那個成功，究竟是程式接受了請求、傳送服務願意接手，還是目的地真的回覆了？如果大家依賴這則通知安排行動，三種意思的差別就不只是畫面上的文字。

這是假設情境，不是 ARCI 已發生的現場事故。上一篇，我讓工程日誌不能搶先宣布成功；那篇留下的外部草稿驗證，本文也沒有代替它完成。今天我把同一個問題帶回通訊：當某個元件說「成功」，誰有資格把整個任務標成完成？

ARCI 的全名是 Autonomous Resilient Communication Intelligence。我希望它能在通訊條件不理想時，仍然依照規則處理任務。本篇先回看較早的通訊核心，只談一件事：傳送端回報成功，必須經過什麼檢查，才能成為系統承認的送達？[1]

問題原本看起來很簡單

最直覺的流程是「送出、收到成功回傳、結束」。寫教學範例時，這很容易理解；問題是，把它放進多個元件合作的流程，每個元件能證明的事情並不相同。

可以把它想成寄包裹：櫃檯收下包裹，代表交寄這一步成立，不能直接證明收件人已經簽收。對 ARCI 而言，傳輸介面回傳 ACCEPTED，也是接受這次傳送嘗試的觀察，不能直接替整個任務蓋上送達章。早期的本機傳輸文件已經把這條界線寫清楚。[1]

因此我需要另一種資料：ACK（acknowledgement，接收端回覆「這次傳送已收到」的確認訊息）。不過，收到 ACK 還不是終點。它也可能屬於別的訊息，或是在這次任務的期限過後才出現。系統必須先辨認它到底在回答哪一件事。[2]

真正失敗時發生什麼？

翻開既有測試，我看到一個很容易忽略的情況：執行結果已經寫著 DELIVERED，也就是執行端回報已送出到目的地，但驗證器拿不到 ACK。測試要求它回傳 UNVERIFIED，意思是尚未驗證，並留下缺少確認訊息的原因。這個欄位本身不能取代確認證據。[2][3]

這讓「沒有報錯」與「可以宣布完成」分開了。假如我只檢查傳送函式有沒有丟出錯誤，就會忽略最重要的缺口：我仍然沒有足夠資料，知道對方是否收到。

另外幾個測試把 ACK 的訊息、執行或路徑識別換掉。路徑在這裡指這次傳送採用的通道；識別則是用來區分各次工作的一組標記。只要其中一項對不上，驗證就必須拒絕。拿別張包裹的簽收單來證明這一件，格式再完整也沒有用。[2][3]

時間也是條件。timeout（逾時，就是到了約定期限仍無法在規則內完成確認）不等於「對方肯定沒收到」。既有驗證器會把超過期限的 ACK 分類成逾時；它回答的是這份回覆能否滿足本次確認規則，沒有替遠端實際發生的事情下結論。[2]

我最後加了什麼限制？

我把完成的決定留在專門的驗證關卡。早期的 VerificationEngine 會檢查 ACK 是否缺席、是否已處理、是否超過期限，以及訊息、執行和路徑是否吻合；執行結果本身也必須符合要求，才會得到 VERIFIED，也就是通過驗證。[2]

以下是簡化後的概念模型，不是實際 production code；它只說明必要條件，不呈現原始碼的判斷順序或完整錯誤分類。

收到這次傳送的結果
  ↓
是否有 ACK？ ── 否 → 保留未驗證或逾時狀態
  ↓ 是
ACK 是否未重複、未逾期，而且身分吻合？
  ├─ 否 → 不建立送達結論，保留原因
  └─ 是 → 執行結果也符合條件？
             ├─ 否 → 不建立送達結論
             └─ 是 → 通過驗證

在後續的受控本機傳輸階段，ARCI 又把這道關卡接到 runtime，也就是掌管任務執行狀態的流程。外部整理好的 ACK 候選資料仍然沒有宣告完成的權力。入口先檢查它是否符合目前任務、執行、有效路徑與政策狀態，再交給既有驗證器。[4]

只有通過之後，入口才依序留下開始驗證、接收 ACK、任務送達、流程完成的事件。這個入口沒有提供直接把任務改成送達的捷徑。對我來說，重點是讓完成必須走過同一組檢查，而不是只在註解裡提醒大家小心。[4][5]

圖一：早期 ACK 驗證與後續本機傳輸入口的概念整理。沒有 ACK、資料不符或驗證未通過，都不能沿綠色路徑宣布完成；圖中的失敗出口不代表它們共用同一個錯誤碼。[1][2][4]

這個設計不能保證什麼？

首先，通過這些檢查，不代表通知已被人讀懂，更不代表對方已經照著行動。本文談的是 ARCI 在指定規則下承認的送達證據，沒有延伸到人的閱讀或現場任務結果。

其次，這裡的本機傳輸工具依照事先給定的腳本，產生結果與回覆，沒有真的連到電信網路或通訊硬體。測試可以檢查「拿錯 ACK 會不會被接受」，卻不能拿來宣稱災區訊息的實際送達率。[1][6]

最後，驗證器不是完整的故障恢復器。拒絕一份證據後，要等多久、能不能再次傳送、什麼條件下停止，仍然是接下來要回答的問題。它也不會因為判定逾時，就自動撤回遠端可能已經執行的動作。把完成條件寫清楚，能避免過早報喜，但不會讓網路從此不再失敗。

今天真正完成的是什麼？

今天我整理的是既有設計與測試，不是今天才新增這套機制。Git 紀錄顯示，本文的 ACK 驗證已存在於 2026 年 8 月 22 日的通訊核心；把外部候選資料接回 runtime 的本機傳輸入口，則出現在 8 月 23 日。兩個階段有先後，不能寫成一開始就同時完成。[2][4]

為了確認文章沒有讀錯程式，我在今天另做了一次局部複查：ACK 驗證與 runtime 入口兩份測試，共 21 項通過。這是目前本機的檢查結果，不是當年的完整驗收，也不代表外部服務、硬體或正式部署已通過。[3][5]

今天能交代清楚的範圍，就是「成功回傳需要哪些證據，才能變成送達結論」。後來 R1 的故障恢復與 R2 的儲存工作，會在系列後續分別討論；本篇沒有把那些較晚的能力放進早期流程。

下一步

現在我有規則決定什麼時候可以說完成，卻還有一個更難受的情況：確認訊息始終沒有回來。如果無限等待，任務可能永遠卡住；如果太早判定失敗，又可能對已經送達的工作做出錯誤處理。

Day 03 我想接著問：等不到回覆時，我能直接說失敗嗎？ 我會從「尚未知道」與「已確認失敗」的差別出發，討論為什麼時間到了，系統需要的是明確的停止與分類規則。

參考資料

1. ARCI《Phase 4D — Controlled Local Transport Prototype》：支持傳送受理、外部證據與正式送達之間的權限區分，以及本機腳本沒有接入真實通訊網路的限制。
2. ARCI VerificationEngine 原始碼與首次納入的 Git 紀錄：支持 ACK 缺席、重複、期限、身分比對及執行狀態的判斷，並確認早期實作時間。
3. ARCI〈ACK verification〉測試：支持缺少 ACK、錯誤身分、晚到、重複及失敗執行不能通過驗證的描述；今天局部複查涵蓋這份測試。
4. ARCI SealedRuntimeTransportIngestionCommand 原始碼與首次納入的 Git 紀錄：支持目前狀態的獨立檢查、沿用驗證器，以及通過後才產生送達事件。
5. ARCI〈Phase 4D sealed-runtime ingestion command〉測試：支持事件順序、過期狀態與錯誤身分遭拒絕，以及入口沒有直接送達修改方法；今天局部複查也涵蓋這份測試。
6. ARCI LocalLoopbackTransportAdapter 原始碼：支持以注入腳本產生傳送結果的說明，不能作為現場故障或送達率證據。