Mystilink 知識庫編輯標準提案
以下是 Mystilink 知識庫的編輯標準提案，須經負責團隊審議、採納，才成為公司政策。它不是現行審核制度、公司過往做法或回覆時限的說明。
這座知識庫擬協助讀者研究象徵體系、記錄解讀、理解所用工具。可信度取決於讀者能否查驗一項說法，辨認它的界線。以下把這個目標化為編輯面對單篇文章時可作的判斷。
每篇文章先說清任務
稿件應交代協助讀者回答什麼問題。談不確定出生時間，就教人保留不確定；談歷史，就指出支持敘述的實物或文本；產品教學則要示範該版本支援的操作任務。
依這份提案，文章若在幾種用途間轉換卻不說明，編輯應不予接受。歷史敘述不證明預測準確，產品展示也不驗證展示過程產生的解釋。每類主張都需各自的證據。
說明深度要配合讀者。完成任務需要專業用語，就先解釋。進階比較不需要拿好幾段讚頌古代智慧或現代科技的文字來充篇幅。
證據要對得上主張
歷史說法應引可辨識的學術研究、原始文獻、博物館紀錄或其他合適證據，且要支持緊接的那句話。證明某物存在的來源，不能自動用來說明所有人怎樣使用它。
介紹象徵實踐時，傳統或慣例若影響意義，就要標出。實踐者不同意時，說明具體差異，別編出共同定論。翻譯選擇改變論證時，也應讓讀者看見。
關於 Mystilink 的描述，應以相關現有證據核對。程式碼儲存庫可以證明查過的那份程式有某項實作；要說使用者在已發布版本能用什麼，則須有發布文件或實測版本。提議中的功能無論在哪裡談，都得維持提案措辭。
把案例性質標清楚
編設的教學例子應標明虛構，不能看似顧客證言、員工經歷或預測命中報告。編輯要檢查標題、開頭、圖說，以及可能單獨流傳的摘錄。
涉及真人的案例，需要合適授權及身分資訊檢視。私人解讀的同意，不代表也同意公開成文。團隊須先建立有文字紀錄的處理流程，才宜將這類案例收進知識庫。
社群文章可以提問、示範分歧，不必假裝是自然出現的顧客互動。預備內容應保有教學或編輯目的，公開的作者身分與經驗陳述都要正確。
讓詮釋能被檢視
文章應分清提供的事實、計算結果、傳統聯想及作者自己的解釋。讀者應看得出從一項轉進另一項的步驟。不確定放在受影響的主張旁，才會改變理解。
個人結論不能比證據更肯定。象徵材料不應用來判定疾病、決定法律結果，或指導後果重大的財務選擇。教授解讀的知識庫，必須說清練習究竟能證明到哪裡。
讀者應有反對空間。案例不能把拒絕描述，當成解讀看穿隱藏真相的證據。不吻合時，作者可以分析落差，也可以先留著不作結論。
要有實質的人工編輯
按照提案，AI 輔助稿件需要一位人工編輯對發表內容負責。應查引用與產品描述、刪除無依據編造的細節，並把定稿和證據對照。只改文法，不符合這項要求。
文字審閱應去掉重複結論、含糊的權威背書，以及假扮說明的廣告語。每段都要有助文章任務。具體例子比抽象說法更清楚時，就讓例子負責解釋。
封面也須審閱。圖片不應讓虛構案例看似真實照片，也不應錯畫具有特定文化意義的物件，卻當成文獻證據展示。圖像性質影響理解時，附上圖說或標記。
記下發布判斷
編輯應為各稿留下決定：可供所述用途、依指定事項修改，或因證據不足暫緩。同時註明出處問題或產品核查由誰處理。團隊能承擔這些責任，擬議標準才適合正式運作。
發表後的實質更正，應循已採納的更正程序。在該程序獲准以前，標準仍是草案框架。下一輪可挑歷史文章、產品教學與虛構解讀練習各一份來試用，再針對編輯判斷仍不明確的地方修規則。