跳轉到主要內容
一份合規報告只有在稽核師能信任它自你產生以來未被編輯時，對他們才有用。OrcaRouter 產生的每份報告都攜帶兩樣讓那項檢查在沒有任何帳號存取的情況下成為可能的東西：標準證據的 SHA-256 內容雜湊，以及對該雜湊的 Ed25519 簽章。本頁展示如何驗證一份合規報告——取得公鑰、確認雜湊、檢查簽章——只使用公開端點。 使用案例很具體：你把一份簽署報告（或一個分享入口連結）交給稽核師，他們需要在依賴它之前證明它是真實且未經竄改的。他們從不接觸你的工作區、你的金鑰或主控台。

​
1. 隨報告一同傳遞的東西

三個值讓一份報告能自我驗證。它們出現在報告產物上，以及連結的公開分享入口中繼資料上。
報告標準證據 JSON 的小寫十六進位 SHA-256 摘要。對某份報告而言這些位元組是確定性的，因此任何持有相同證據的人都會重新計算出相同的雜湊。對證據的任何編輯都會改變這個值。
對十六進位 content_hash 計算的 base64 Ed25519 簽章。它證明該雜湊由 OrcaRouter 的簽署金鑰簽署且非偽造。
作用中公鑰的一個簡短、穩定的識別碼（例如 orca- 後接一個十六進位片段）。驗證者用它確認報告由目前已發佈的金鑰簽署——由未知金鑰 id 簽署的報告會失敗關閉。
簽章涵蓋的是內容雜湊，而非直接渲染出的 PDF、CSV 或 JSON 位元組。相同的證據從一個雜湊渲染成全部三種格式，因此完整性保證落在底層證據上——某份報告的每次匯出共享同一個 content_hash、signature 與 sig_key_id。

​
2. 取得公鑰

簽署公鑰發佈於一個開放端點——無需驗證、無需工作區情境。稽核師直接呼叫它。 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
public_key 是 base64 編碼的 32 位元組 Ed25519 公鑰。此處的 key_id 必須與報告上的 sig_key_id 相符——若不相符，該報告由一把不同的（可能已輪替或較舊的）金鑰簽署，且不會對照這把已發佈的金鑰驗證通過。

​
3. 驗證簽章

你可以用兩種方式驗證簽章。要嘛請 OrcaRouter 為你檢查這組值，要嘛用已發佈的公鑰完全離線驗證。

​
託管的 verify 端點

把報告中的三個值 POST 到開放的 verify 端點。它是公開的——稽核師無需任何憑證即可呼叫它。 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true 表示簽章對照該金鑰 id 的作用中金鑰檢查通過。valid: false 表示要嘛簽章與雜湊不符、雜湊為空，要嘛 sig_key_id 與目前已發佈的金鑰不符。
verify 端點會回傳作用中的 key_id。把它與你提交的 sig_key_id 比較：若它們不同，該報告由一把不再是作用中的金鑰簽署，這就是它驗證失敗的原因。

​
用公鑰離線驗證

一位多疑的稽核師完全不需要信任 verify 端點。因為演算法是對十六進位內容雜湊的標準 Ed25519，簽章可用任何密碼學程式庫檢查： 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
被簽署的訊息是十六進位雜湊字串本身，編碼為 ASCII 位元組——而非該雜湊解碼出的原始 32 位元組。在簽章驗證之前原樣傳遞 content_hash 值，否則檢查會在一份正確的報告上失敗。

​
4. 簽章涵蓋什麼

簽章證明報告的 content_hash 由 OrcaRouter 簽署，而雜湊證明證據未經編輯。一個細微之處：雜湊是對閘道建立的證據的標準形式計算的——而非 JSON 或 PDF 檔案的原始位元組。因此你自己重新雜湊下載的產物不會重現 content_hash。請使用 verify 端點（§2/§3），它會為你重新計算標準雜湊並檢查 Ed25519 簽章：
檢查含義
signature_valid: truecontent_hash 由 OrcaRouter 的金鑰簽署——證據真實且未經編輯。
Key id 相符報告 sig_key_id == 已發佈的金鑰 id → 由作用中金鑰簽署。
兩者皆通過表示報告真實且未經竄改。簽章失敗表示雜湊、證據或金鑰 id 不屬於 OrcaRouter 的簽署金鑰。

​
5. 驗證一份分享的報告

當你寄給稽核師一個分享入口連結而非檔案時，入口中繼資料已攜帶 content_hash、signature 與 sig_key_id，外加一個伺服器計算的 signature_valid 旗標。稽核師可以信任該旗標，並且獨立對照公鑰重新執行上述檢查——分享入口無需登入，而驗證路徑相同。
一個分享的產物只在其蓋印地區仍與你工作區宣告的資料駐留地區相符時才被提供。若地區被變更，即使簽章中繼資料仍可驗證，下載也會被扣留。這是刻意設計——參見 跨地區讀取。

​
6. 下一步去哪裡

簽署報告

一份簽署報告如何產生、它擷取什麼證據，以及如何鑄造一個稽核師分享連結。

匯出證據

把報告證據以 PDF、CSV 或 JSON 拉出，供你稽核師的工作底稿使用。

資料駐留地

報告上的地區戳記如何治理它儲存與提供的所在地。

共同責任

OrcaRouter 在閘道路徑上保證什麼相對於什麼仍是你的。
簽署金鑰是 OrcaRouter 的；驗證是任何人都能做的。那個拆分就是整個重點——稽核師證明一份報告真實，而完全無需取得產生它的工作區的存取權。