謎題、版本預告和社交帖子裡常出現編碼字串。解碼能說明字串代表哪些位元組，卻不能證明作者是誰、截圖是否真實，或未來產品有什麼能力。調查線索時，應把這些問題分開。
先準確儲存原文
儘量直接複製，保留大小寫、標點和填充。另行記錄來源 URL 與時間。如果來源是圖片，要註明人工識別可能把大寫 I、小寫 l 和數字 1 混淆。結果看起來像一句話，也不能證明抄錄無誤。
只說明實際解碼結果
例如 NS41 解碼為 ASCII 文本 5.5。它首先只是一個字串，不能獨立證明版本號、日期、分數，或某個組織已經發布公告。
const bytes = Uint8Array.from(atob('NS41'), c => c.charCodeAt(0));
console.log([...bytes]); // [53, 46, 53]
console.log(new TextDecoder('utf-8', { fatal: true }).decode(bytes)); // 5.5
console.log(btoa('5.5')); // NS41反向編碼可以確認編碼關係，但不會增加來源證據。此頁面保留與預告搜尋相關的歷史 URL，不據此斷言 URL 中的組織釋出過該字串或宣佈過某個產品。
把證據分成三欄
分別記錄原始輸入、確定性解碼結果和當前解釋。除非官方來源確認，否則解釋應標記為假設。傳播產品訊息之前直接檢視官方公告，不能用轉發、截圖示題或解碼數字代替核驗。
解碼失敗時，報告具體原因，不要連續嘗試各種變換直到出現有意義的文本。補齊已知遺漏的填充與刪除未知字元不是同一件事。只有來源或格式說明還有一層編碼時，才有理由再次解碼。
輸出也應保持不可執行。謎題可能包含連結或程式碼，閱讀文字不需要開啟連結或執行程式碼。先完成可逆轉換，再獨立評估解讀的證據，這個流程同樣適用於遊戲線索和除錯訊息。