{
  "schemaVersion": "1.0",
  "type": "research-article",
  "runtimeAvailable": false,
  "id": "proof21:journal:one-artifact-three-decisions:th",
  "inLanguage": "th",
  "slug": "one-artifact-three-decisions",
  "title": "หลักฐานชิ้นเดียว สามการตัดสินใจ",
  "description": "แยกความครบถ้วน การประเมิน และการยอมรับ แม้อินเทอร์เฟซจะเรียบง่าย",
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "url": "https://proof21.xyz/th/journal/one-artifact-three-decisions/",
  "markdownUrl": "https://proof21.xyz/th/journal/one-artifact-three-decisions/article.md",
  "markdown": "# หลักฐานชิ้นเดียว สามการตัดสินใจ\n\n**บันทึกออกแบบโปรโตคอล · 7 กันยายน 2026**\n\nการเขียนว่า “ตรวจแล้ว” บนเว็บไซต์ทำง่าย แต่การใช้ให้แม่นยำยากกว่า เราตรวจลายเซ็น การคำนวณ การรวมธุรกรรม เงื่อนไขนโยบาย หรือสิทธิ์ทำขั้นตอนถัดไป?\n\nอินเทอร์เฟซผู้รับที่เสนอของ Proof21 แยกคำถามเหล่านี้โดยตั้งใจ ผลสีเขียวเดียวที่ซ่อนความต่างไม่เหมาะเป็นรากฐานเวิร์กโฟลว์การเงินอัตโนมัติ\n\n## 1. ตรวจชิ้นหลักฐาน\n\nชั้นแรกถามว่าชิ้นหลักฐานคงสภาพและผูกอย่างถูกต้องภายใต้สมมติฐานคีย์ที่ยอมรับหรือไม่ ตรวจโครงสร้าง ลายเซ็น ผู้ออก การอ้างถึงงาน และกฎเข้ารหัสที่รองรับ\n\nสิ่งนี้ยืนยันว่าผู้ออกลงนามอะไร ไม่ได้ยืนยันอิสระว่าทุกข้อความเป็นจริง โปรโตคอลบันทึกเช่น PEAC ระบุขอบเขตคำรายงานของผู้ออกชัดเจน [1]\n\nระบบผู้รับยังต้องมีนโยบายค้นหา หมุน และเพิกถอนคีย์ การตรวจออฟไลน์ด้วยคีย์ที่ให้มาไม่ใช่หลักฐานว่าคีย์ยังได้รับการยอมรับในขณะนี้\n\n## 2. ประเมินคำกล่าวอ้างที่ระบุ\n\nชั้นถัดไปใช้นโยบายเฉพาะกับชุดหลักฐานที่กำหนด อาจเทียบผู้รับและจำนวนเงินกับคำสั่ง หรือคำนวณ DMT ซ้ำจากฟิลด์และกฎที่อ้างถึง\n\nผลมีขอบเขต: ผ่าน ไม่ผ่าน หรือสรุปไม่ได้ พร้อมเหตุผล ห้ามขยายเงื่อนไขเดียวที่ผ่านเป็นคำรับรองทั้งความปลอดภัยของเอเจนต์ ผลลงทุน หรือความครบถ้วนของร่องรอยกระบวนการทั้งหมด\n\nชนิดหลักฐานสำคัญ คำกล่าวลงนาม ข้อสังเกต RPC ข้อพิสูจน์การรวม และสถานะตรวจอิสระใช้แทนกันไม่ได้ การห่อในรายงานร่วมต้องเก็บความต่างนี้\n\n## 3. ใช้เกณฑ์ยอมรับของตน\n\nผู้รับตัดสินว่าผลเพียงพอสำหรับงานถัดไปหรือไม่ งานติดตามมูลค่าต่ำกับข้อผูกมัดทางการเงินมูลค่าสูงอาจกำหนดแหล่ง ความสิ้นสุด ผู้ลงนาม ความสด และการอนุมัติมนุษย์ต่างกัน\n\nจึงเป็นเหตุผลที่ P21 ไม่แทนมาตรการควบคุมทุกอย่างของกระเป๋าหรือแพลตฟอร์ม ผู้รับยังมีอำนาจ รายงานเป็นหลักฐานให้พิจารณาภายใต้อำนาจนั้น ไม่ใช่การให้สิทธิ์ใหม่\n\n## ภายนอกเรียบง่าย ภายในชัดเจน\n\nประสบการณ์นักพัฒนาที่ตั้งใจยังย่อได้ SDK เดียวส่งคำขอ รักษาต้นฉบับ สร้างผลตรวจ และให้ตัวตรวจฝั่งผู้รับ ความเรียบง่ายควรมาจากอินเทอร์เฟซสม่ำเสมอ ไม่ใช่ลบความไม่แน่นอน\n\nหมุดหมายการสร้างแรกคือสองโปรเซสอิสระครบวงจร: ฝ่ายหนึ่งสร้างรายงาน อีกฝ่ายทำซ้ำการตรวจที่รองรับและปฏิเสธหลักฐานที่ถูกแก้ เอกสารปัจจุบันอธิบายเป้าหมายนี้ SDK ที่เผยแพร่ยังไม่มี\n\n## รายงานความล้มเหลวที่แท้จริงก็เป็นหลักฐานที่มีประโยชน์\n\nสมมติว่าผู้จัดทำลงนามรายงานระบุว่าการจ่ายเงินสังเคราะห์ใช้ผู้รับผิดคน ผู้ใช้ผลที่เป็นอิสระยืนยันว่ารายงานไม่ถูกแก้ไข และลายเซ็นตรวจสอบได้ด้วยกุญแจที่ให้มาและได้รับการยอมรับ ผลด้านความสมบูรณ์อาจเป็นบวก ขณะที่ผลประเมินการจ่ายเงินเป็น `FAIL` จากนั้นนโยบายอาจยอมรับรายงานเป็นหลักฐานที่มีประโยชน์ แต่ไม่อนุญาตขั้นตอนถัดไปที่เกี่ยวกับการจ่ายเงิน ผลทั้งสามสอดคล้องกัน ไม่ได้ขัดแย้งกัน\n\nในทางกลับกัน รายงานที่ไม่ถูกแก้ไขอาจมีคำกล่าวอ้างว่าสำเร็จโดยผู้จัดทำไม่มีหลักฐานรองรับ ตัวประเมินต้องไม่ยืมความแน่นอนมาจากลายเซ็น แบบจำลองข้อมูล Verifiable Credentials ของ W3C เป็นเอกสารต้นทางที่ช่วยแยกการตรวจสอบกลไกของข้อมูลรับรองออกจากการตัดสินใจไว้วางใจของผู้พึ่งพาข้อมูล Proof21 ไม่ได้อ้างว่ารูปแบบสิ่งส่งมอบฉบับร่างของตนเป็นข้อมูลรับรอง W3C โดยอัตโนมัติ [2]\n\nการแยกเช่นนี้ช่วยให้ข้อความข้อผิดพลาดดีขึ้นด้วย “ไม่รองรับโปรไฟล์หลักฐาน” บอกให้ผู้ใช้ผลหาเครื่องมือที่เข้ากันได้หรือหลักฐานชนิดอื่น “ผู้รับไม่ตรงกัน” อธิบายการเปรียบเทียบที่รองรับแต่ไม่ผ่าน ส่วน “นโยบายท้องถิ่นไม่ยอมรับผู้ออก” เป็นเรื่องอำนาจและความไว้วางใจ การรวมทั้งหมดเป็นคำว่า “ไม่ถูกต้อง” อาจทำให้แก้ปัญหายากขึ้นและกระตุ้นการลองใหม่ที่ไม่ปลอดภัย\n\n## ต้องตกลงไบต์ให้แน่นอนก่อนลงนาม\n\nวัตถุ JSON สองชุดอาจดูมีความหมายเท่ากันสำหรับผู้อ่าน แต่มีการเข้ารหัสต่างกัน ลายเซ็นต้องใช้ข้อความที่กำหนดอย่างแม่นยำ ไม่ใช่ภาพหน้าจอหรือการตีความของผู้อ่าน RFC 8785 กำหนดกฎ JSON Canonicalization Scheme ซึ่งรวมข้อจำกัดของข้อมูลและการซีเรียลไลซ์แบบกำหนดผลแน่นอน เป็นเอกสารออกแบบที่เกี่ยวข้อง แต่ไม่ทดแทนการเลือกและทดสอบโปรไฟล์การซีเรียลไลซ์ที่แน่นอนของระบบจริง [3]\n\nสำหรับโปรไฟล์ทางการเงิน จำนวนเงินขนาดใหญ่ควรคงเป็นสตริงเลขฐานสิบที่แทนจำนวนเต็มของหน่วยย่อยที่สุด ไม่ใช่แปลงผ่านเลขทศนิยมแบบลอยตัวโดยไม่ระวัง สคีมาที่รับต้องกำหนดชนิดข้อมูลและปฏิเสธความกำกวม อีกทั้งควรผูกเครือข่าย สินทรัพย์ที่แน่นอน ตัวระบุการดำเนินการ เวอร์ชันนโยบาย ไดเจสต์คำสั่ง และไดเจสต์ผลลัพธ์ไว้ในบริบทที่ได้รับการรับรอง ไม่ปล่อยป้ายกำกับสำคัญไว้ภายนอก\n\nตัวแยกวิเคราะห์ควรปฏิเสธเวอร์ชันที่ไม่รองรับและฟิลด์ซ้ำหรือขัดกันตามกฎที่ประกาศไว้ จำกัดขนาดอินพุตก่อนเริ่มงานที่ใช้ทรัพยากรมาก ใช้ไลบรารีการเข้ารหัสที่เป็นที่ยอมรับพร้อมชุดทดสอบ แทนการให้โมเดลภาษาประดิษฐ์วิธีตรวจลายเซ็น RFC 8032 ให้ข้อกำหนด EdDSA และชุดทดสอบ การเลือก Ed25519 เพียงอย่างเดียวไม่ได้พิสูจน์ความเป็นเจ้าของกุญแจ สถานะการเพิกถอน หรือสิทธิ์ดำเนินการ [4]\n\n## การยอมรับเป็นหน้าที่ของนโยบายผู้ใช้ผลที่มีชื่อชัดเจน\n\nลองนึกถึงผู้ใช้ผลสองรายที่ได้รับรายงานเดียวกัน แดชบอร์ดติดตามอนุญาตให้แสดงการสังเกตเก่าซึ่งติดป้ายชัดเจนเพื่อวิเคราะห์ย้อนหลัง แต่ตัวควบคุมเงินทุนต้องการหลักฐานปัจจุบัน ผู้ออกที่กำหนด เงื่อนไขการยืนยันเพียงพอ และการอนุมัติจากมนุษย์ จึงสมเหตุสมผลที่แดชบอร์ดแสดงรายงานได้ ขณะที่ตัวควบคุมปฏิเสธการกระทำที่เกี่ยวกับธุรกรรม\n\nรายงานต้องไม่แอบเลือกนโยบายที่อ่อนกว่าแทนตัวควบคุม ควรบันทึกว่าประเมินนโยบายใด เงื่อนไขก่อนหน้าครบหรือไม่ และอนุญาตการกระทำถัดไปใดจริง การปรับนโยบายภายหลังต้องไม่เขียนความหมายทางประวัติศาสตร์ของการตัดสินใจเก่าใหม่ เก็บเวอร์ชันเดิมให้ใช้ทำซ้ำได้ และบันทึกการตัดสินใจใหม่เมื่อต้องประเมินอีกครั้ง\n\nในการนำร่อง ให้ผู้จัดทำและผู้ใช้ผลทำงานคนละกระบวนการและใช้การตั้งค่าแยกกัน ทดสอบรายงานเชิงลบที่แท้จริง หลักฐานที่ถูกแก้ไข ตัวระบุการดำเนินการผิด เวอร์ชันที่ไม่รู้จัก การสังเกตที่หายไป และผู้ออกที่ไม่เป็นที่ยอมรับ เดโมออฟไลน์เพื่อการศึกษามีตัวอย่างสังเคราะห์ของการตรวจความสมบูรณ์และนโยบายบางส่วนแล้ว แต่นั่นไม่ได้อ้างว่ามีการค้นหากุญแจแบบไดนามิก อะแดปเตอร์หลักฐานครบทุกชนิด หรือบริการยอมรับสำหรับระบบใช้งานจริง\n\n## คำถามที่พบบ่อย\n\n### ลายเซ็นผ่านการตรวจได้ในขณะที่การจ่ายเงินไม่ผ่านได้หรือไม่?\n\nได้ รายงานที่ลงนามถูกต้องสามารถอธิบายเงื่อนไขการจ่ายเงินที่ไม่ผ่านอย่างตรงไปตรงมา ความสมบูรณ์เป็นเรื่องของสิ่งส่งมอบที่รับรองแล้ว ส่วนการประเมินเป็นเรื่องของข้อกล่าวอ้างและหลักฐานที่ระบุ อินเทอร์เฟซควรแสดงผลทั้งสองอย่างชัดเจน\n\n### การยอมรับรายงานอนุญาตให้เอเจนต์ใช้เงินหรือไม่?\n\nไม่ได้โดยตัวมันเอง ผู้ใช้ผลอาจยอมรับรายงานเพื่อเก็บหรือทบทวน โดยไม่ให้สิทธิ์โอนเงิน สิทธิ์ดำเนินการเป็นหน้าที่ของนโยบายอนุญาตและมาตรการควบคุมที่ชัดเจนของแอปพลิเคชัน\n\n### หลักฐานทุกชนิดลดเหลือคะแนนความไว้วางใจเดียวได้หรือไม่?\n\nการทำเช่นนั้นจะซ่อนความแตกต่างสำคัญ คำยืนยันที่ลงนาม การสังเกตผ่าน RPC และสถานะที่ตรวจสอบอย่างอิสระรองรับข้อกล่าวอ้างต่างกัน ซองข้อมูลร่วมควรคงชนิดหลักฐานต้นฉบับ ที่มา ข้อจำกัด และคำถามที่ยังไม่คลี่คลายไว้\n\n## เอกสารต้นทางเพิ่มเติม\n\n- [2: W3C Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/)\n- [3: RFC 8785 — JSON Canonicalization Scheme](https://www.rfc-editor.org/rfc/rfc8785.html)\n- [4: RFC 8032 — อัลกอริทึมลายเซ็นดิจิทัล Edwards-Curve](https://www.rfc-editor.org/rfc/rfc8032.html)\n\n## อ่านต่อ\n\n- [แบบตรวจฝั่งผู้รับ](https://proof21.xyz/th/docs/protocol/verification/)\n- [ความปลอดภัยและขอบเขตความเชื่อถือ](https://proof21.xyz/th/docs/protocol/security/)\n- [1: ขอบเขตหลักฐาน PEAC](https://www.peacprotocol.org/)\n",
  "articleBody": "บันทึกออกแบบโปรโตคอล · 7 กันยายน 2026 การเขียนว่า “ตรวจแล้ว” บนเว็บไซต์ทำง่าย แต่การใช้ให้แม่นยำยากกว่า เราตรวจลายเซ็น การคำนวณ การรวมธุรกรรม เงื่อนไขนโยบาย หรือสิทธิ์ทำขั้นตอนถัดไป? อินเทอร์เฟซผู้รับที่เสนอของ Proof21 แยกคำถามเหล่านี้โดยตั้งใจ ผลสีเขียวเดียวที่ซ่อนความต่างไม่เหมาะเป็นรากฐานเวิร์กโฟลว์การเงินอัตโนมัติ 1. ตรวจชิ้นหลักฐาน ชั้นแรกถามว่าชิ้นหลักฐานคงสภาพและผูกอย่างถูกต้องภายใต้สมมติฐานคีย์ที่ยอมรับหรือไม่ ตรวจโครงสร้าง ลายเซ็น ผู้ออก การอ้างถึงงาน และกฎเข้ารหัสที่รองรับ สิ่งนี้ยืนยันว่าผู้ออกลงนามอะไร ไม่ได้ยืนยันอิสระว่าทุกข้อความเป็นจริง โปรโตคอลบันทึกเช่น PEAC ระบุขอบเขตคำรายงานของผู้ออกชัดเจน [1] ระบบผู้รับยังต้องมีนโยบายค้นหา หมุน และเพิกถอนคีย์ การตรวจออฟไลน์ด้วยคีย์ที่ให้มาไม่ใช่หลักฐานว่าคีย์ยังได้รับการยอมรับในขณะนี้ 2. ประเมินคำกล่าวอ้างที่ระบุ ชั้นถัดไปใช้นโยบายเฉพาะกับชุดหลักฐานที่กำหนด อาจเทียบผู้รับและจำนวนเงินกับคำสั่ง หรือคำนวณ DMT ซ้ำจากฟิลด์และกฎที่อ้างถึง ผลมีขอบเขต: ผ่าน ไม่ผ่าน หรือสรุปไม่ได้ พร้อมเหตุผล ห้ามขยายเงื่อนไขเดียวที่ผ่านเป็นคำรับรองทั้งความปลอดภัยของเอเจนต์ ผลลงทุน หรือความครบถ้วนของร่องรอยกระบวนการทั้งหมด ชนิดหลักฐานสำคัญ คำกล่าวลงนาม ข้อสังเกต RPC ข้อพิสูจน์การรวม และสถานะตรวจอิสระใช้แทนกันไม่ได้ การห่อในรายงานร่วมต้องเก็บความต่างนี้ 3. ใช้เกณฑ์ยอมรับของตน ผู้รับตัดสินว่าผลเพียงพอสำหรับงานถัดไปหรือไม่ งานติดตามมูลค่าต่ำกับข้อผูกมัดทางการเงินมูลค่าสูงอาจกำหนดแหล่ง ความสิ้นสุด ผู้ลงนาม ความสด และการอนุมัติมนุษย์ต่างกัน จึงเป็นเหตุผลที่ P21 ไม่แทนมาตรการควบคุมทุกอย่างของกระเป๋าหรือแพลตฟอร์ม ผู้รับยังมีอำนาจ รายงานเป็นหลักฐานให้พิจารณาภายใต้อำนาจนั้น ไม่ใช่การให้สิทธิ์ใหม่ ภายนอกเรียบง่าย ภายในชัดเจน ประสบการณ์นักพัฒนาที่ตั้งใจยังย่อได้ SDK เดียวส่งคำขอ รักษาต้นฉบับ สร้างผลตรวจ และให้ตัวตรวจฝั่งผู้รับ ความเรียบง่ายควรมาจากอินเทอร์เฟซสม่ำเสมอ ไม่ใช่ลบความไม่แน่นอน หมุดหมายการสร้างแรกคือสองโปรเซสอิสระครบวงจร: ฝ่ายหนึ่งสร้างรายงาน อีกฝ่ายทำซ้ำการตรวจที่รองรับและปฏิเสธหลักฐานที่ถูกแก้ เอกสารปัจจุบันอธิบายเป้าหมายนี้ SDK ที่เผยแพร่ยังไม่มี รายงานความล้มเหลวที่แท้จริงก็เป็นหลักฐานที่มีประโยชน์ สมมติว่าผู้จัดทำลงนามรายงานระบุว่าการจ่ายเงินสังเคราะห์ใช้ผู้รับผิดคน ผู้ใช้ผลที่เป็นอิสระยืนยันว่ารายงานไม่ถูกแก้ไข และลายเซ็นตรวจสอบได้ด้วยกุญแจที่ให้มาและได้รับการยอมรับ ผลด้านความสมบูรณ์อาจเป็นบวก ขณะที่ผลประเมินการจ่ายเงินเป็น FAIL จากนั้นนโยบายอาจยอมรับรายงานเป็นหลักฐานที่มีประโยชน์ แต่ไม่อนุญาตขั้นตอนถัดไปที่เกี่ยวกับการจ่ายเงิน ผลทั้งสามสอดคล้องกัน ไม่ได้ขัดแย้งกัน ในทางกลับกัน รายงานที่ไม่ถูกแก้ไขอาจมีคำกล่าวอ้างว่าสำเร็จโดยผู้จัดทำไม่มีหลักฐานรองรับ ตัวประเมินต้องไม่ยืมความแน่นอนมาจากลายเซ็น แบบจำลองข้อมูล Verifiable Credentials ของ W3C เป็นเอกสารต้นทางที่ช่วยแยกการตรวจสอบกลไกของข้อมูลรับรองออกจากการตัดสินใจไว้วางใจของผู้พึ่งพาข้อมูล Proof21 ไม่ได้อ้างว่ารูปแบบสิ่งส่งมอบฉบับร่างของตนเป็นข้อมูลรับรอง W3C โดยอัตโนมัติ [2] การแยกเช่นนี้ช่วยให้ข้อความข้อผิดพลาดดีขึ้นด้วย “ไม่รองรับโปรไฟล์หลักฐาน” บอกให้ผู้ใช้ผลหาเครื่องมือที่เข้ากันได้หรือหลักฐานชนิดอื่น “ผู้รับไม่ตรงกัน” อธิบายการเปรียบเทียบที่รองรับแต่ไม่ผ่าน ส่วน “นโยบายท้องถิ่นไม่ยอมรับผู้ออก” เป็นเรื่องอำนาจและความไว้วางใจ การรวมทั้งหมดเป็นคำว่า “ไม่ถูกต้อง” อาจทำให้แก้ปัญหายากขึ้นและกระตุ้นการลองใหม่ที่ไม่ปลอดภัย ต้องตกลงไบต์ให้แน่นอนก่อนลงนาม วัตถุ JSON สองชุดอาจดูมีความหมายเท่ากันสำหรับผู้อ่าน แต่มีการเข้ารหัสต่างกัน ลายเซ็นต้องใช้ข้อความที่กำหนดอย่างแม่นยำ ไม่ใช่ภาพหน้าจอหรือการตีความของผู้อ่าน RFC 8785 กำหนดกฎ JSON Canonicalization Scheme ซึ่งรวมข้อจำกัดของข้อมูลและการซีเรียลไลซ์แบบกำหนดผลแน่นอน เป็นเอกสารออกแบบที่เกี่ยวข้อง แต่ไม่ทดแทนการเลือกและทดสอบโปรไฟล์การซีเรียลไลซ์ที่แน่นอนของระบบจริง [3] สำหรับโปรไฟล์ทางการเงิน จำนวนเงินขนาดใหญ่ควรคงเป็นสตริงเลขฐานสิบที่แทนจำนวนเต็มของหน่วยย่อยที่สุด ไม่ใช่แปลงผ่านเลขทศนิยมแบบลอยตัวโดยไม่ระวัง สคีมาที่รับต้องกำหนดชนิดข้อมูลและปฏิเสธความกำกวม อีกทั้งควรผูกเครือข่าย สินทรัพย์ที่แน่นอน ตัวระบุการดำเนินการ เวอร์ชันนโยบาย ไดเจสต์คำสั่ง และไดเจสต์ผลลัพธ์ไว้ในบริบทที่ได้รับการรับรอง ไม่ปล่อยป้ายกำกับสำคัญไว้ภายนอก ตัวแยกวิเคราะห์ควรปฏิเสธเวอร์ชันที่ไม่รองรับและฟิลด์ซ้ำหรือขัดกันตามกฎที่ประกาศไว้ จำกัดขนาดอินพุตก่อนเริ่มงานที่ใช้ทรัพยากรมาก ใช้ไลบรารีการเข้ารหัสที่เป็นที่ยอมรับพร้อมชุดทดสอบ แทนการให้โมเดลภาษาประดิษฐ์วิธีตรวจลายเซ็น RFC 8032 ให้ข้อกำหนด EdDSA และชุดทดสอบ การเลือก Ed25519 เพียงอย่างเดียวไม่ได้พิสูจน์ความเป็นเจ้าของกุญแจ สถานะการเพิกถอน หรือสิทธิ์ดำเนินการ [4] การยอมรับเป็นหน้าที่ของนโยบายผู้ใช้ผลที่มีชื่อชัดเจน ลองนึกถึงผู้ใช้ผลสองรายที่ได้รับรายงานเดียวกัน แดชบอร์ดติดตามอนุญาตให้แสดงการสังเกตเก่าซึ่งติดป้ายชัดเจนเพื่อวิเคราะห์ย้อนหลัง แต่ตัวควบคุมเงินทุนต้องการหลักฐานปัจจุบัน ผู้ออกที่กำหนด เงื่อนไขการยืนยันเพียงพอ และการอนุมัติจากมนุษย์ จึงสมเหตุสมผลที่แดชบอร์ดแสดงรายงานได้ ขณะที่ตัวควบคุมปฏิเสธการกระทำที่เกี่ยวกับธุรกรรม รายงานต้องไม่แอบเลือกนโยบายที่อ่อนกว่าแทนตัวควบคุม ควรบันทึกว่าประเมินนโยบายใด เงื่อนไขก่อนหน้าครบหรือไม่ และอนุญาตการกระทำถัดไปใดจริง การปรับนโยบายภายหลังต้องไม่เขียนความหมายทางประวัติศาสตร์ของการตัดสินใจเก่าใหม่ เก็บเวอร์ชันเดิมให้ใช้ทำซ้ำได้ และบันทึกการตัดสินใจใหม่เมื่อต้องประเมินอีกครั้ง ในการนำร่อง ให้ผู้จัดทำและผู้ใช้ผลทำงานคนละกระบวนการและใช้การตั้งค่าแยกกัน ทดสอบรายงานเชิงลบที่แท้จริง หลักฐานที่ถูกแก้ไข ตัวระบุการดำเนินการผิด เวอร์ชันที่ไม่รู้จัก การสังเกตที่หายไป และผู้ออกที่ไม่เป็นที่ยอมรับ เดโมออฟไลน์เพื่อการศึกษามีตัวอย่างสังเคราะห์ของการตรวจความสมบูรณ์และนโยบายบางส่วนแล้ว แต่นั่นไม่ได้อ้างว่ามีการค้นหากุญแจแบบไดนามิก อะแดปเตอร์หลักฐานครบทุกชนิด หรือบริการยอมรับสำหรับระบบใช้งานจริง คำถามที่พบบ่อย ลายเซ็นผ่านการตรวจได้ในขณะที่การจ่ายเงินไม่ผ่านได้หรือไม่? ได้ รายงานที่ลงนามถูกต้องสามารถอธิบายเงื่อนไขการจ่ายเงินที่ไม่ผ่านอย่างตรงไปตรงมา ความสมบูรณ์เป็นเรื่องของสิ่งส่งมอบที่รับรองแล้ว ส่วนการประเมินเป็นเรื่องของข้อกล่าวอ้างและหลักฐานที่ระบุ อินเทอร์เฟซควรแสดงผลทั้งสองอย่างชัดเจน การยอมรับรายงานอนุญาตให้เอเจนต์ใช้เงินหรือไม่? ไม่ได้โดยตัวมันเอง ผู้ใช้ผลอาจยอมรับรายงานเพื่อเก็บหรือทบทวน โดยไม่ให้สิทธิ์โอนเงิน สิทธิ์ดำเนินการเป็นหน้าที่ของนโยบายอนุญาตและมาตรการควบคุมที่ชัดเจนของแอปพลิเคชัน หลักฐานทุกชนิดลดเหลือคะแนนความไว้วางใจเดียวได้หรือไม่? การทำเช่นนั้นจะซ่อนความแตกต่างสำคัญ คำยืนยันที่ลงนาม การสังเกตผ่าน RPC และสถานะที่ตรวจสอบอย่างอิสระรองรับข้อกล่าวอ้างต่างกัน ซองข้อมูลร่วมควรคงชนิดหลักฐานต้นฉบับ ที่มา ข้อจำกัด และคำถามที่ยังไม่คลี่คลายไว้ เอกสารต้นทางเพิ่มเติม 2: W3C Verifiable Credentials Data Model v2.0 3: RFC 8785 — JSON Canonicalization Scheme 4: RFC 8032 — อัลกอริทึมลายเซ็นดิจิทัล Edwards-Curve อ่านต่อ แบบตรวจฝั่งผู้รับ ความปลอดภัยและขอบเขตความเชื่อถือ 1: ขอบเขตหลักฐาน PEAC",
  "citations": [
    "https://www.w3.org/TR/vc-data-model-2.0/",
    "https://www.rfc-editor.org/rfc/rfc8785.html",
    "https://www.rfc-editor.org/rfc/rfc8032.html",
    "https://www.peacprotocol.org/"
  ],
  "faq": [
    {
      "question": "ลายเซ็นผ่านการตรวจได้ในขณะที่การจ่ายเงินไม่ผ่านได้หรือไม่?",
      "answer": "ได้ รายงานที่ลงนามถูกต้องสามารถอธิบายเงื่อนไขการจ่ายเงินที่ไม่ผ่านอย่างตรงไปตรงมา ความสมบูรณ์เป็นเรื่องของสิ่งส่งมอบที่รับรองแล้ว ส่วนการประเมินเป็นเรื่องของข้อกล่าวอ้างและหลักฐานที่ระบุ อินเทอร์เฟซควรแสดงผลทั้งสองอย่างชัดเจน"
    },
    {
      "question": "การยอมรับรายงานอนุญาตให้เอเจนต์ใช้เงินหรือไม่?",
      "answer": "ไม่ได้โดยตัวมันเอง ผู้ใช้ผลอาจยอมรับรายงานเพื่อเก็บหรือทบทวน โดยไม่ให้สิทธิ์โอนเงิน สิทธิ์ดำเนินการเป็นหน้าที่ของนโยบายอนุญาตและมาตรการควบคุมที่ชัดเจนของแอปพลิเคชัน"
    },
    {
      "question": "หลักฐานทุกชนิดลดเหลือคะแนนความไว้วางใจเดียวได้หรือไม่?",
      "answer": "การทำเช่นนั้นจะซ่อนความแตกต่างสำคัญ คำยืนยันที่ลงนาม การสังเกตผ่าน RPC และสถานะที่ตรวจสอบอย่างอิสระรองรับข้อกล่าวอ้างต่างกัน ซองข้อมูลร่วมควรคงชนิดหลักฐานต้นฉบับ ที่มา ข้อจำกัด และคำถามที่ยังไม่คลี่คลายไว้"
    }
  ],
  "sourceSha256": "cef9ebb732223dee1986825bd1b1011ea05e417e4877b45bdfc5ad905ec3cf6b",
  "markdownSha256": "b267ae2288daa10f96c7599cc8a7d4d44cd1f00bf2d4808bdbf2371cc93ed028",
  "translationReview": "คำแปลภาษาไทยฉบับเต็มจัดเตรียมด้วย AI และยังไม่ได้รับการทบทวนทางเทคนิคโดยผู้เชี่ยวชาญภาษาไทยอิสระ หากมีความกำกวมให้ยึดข้อกำหนดภาษาอังกฤษ โค้ด ฟิลด์ และสิทธิ์ไม่เปลี่ยนตามภาษา",
  "image": {
    "url": "https://proof21.xyz/assets/journal/verdict.png",
    "caption": "ประตูสามบานแยกความสมบูรณ์ของสิ่งส่งมอบ การประเมินข้อกล่าวอ้าง และการยอมรับของผู้ใช้ผล การผ่านประตูหนึ่งไม่ได้ทำให้ผ่านประตูถัดไป",
    "sha256": "0e0f3f9f2bd48d65b0f629d46ed5da6ef4e636f98f93cf9b907d0ee9a7ebc92e"
  },
  "motion": {
    "url": "https://proof21.xyz/assets/journal/verdict.mp4",
    "engine": "Remotion",
    "sourceSha256": "13a909f4267d8147386045cbd90df732a42679342c16e04c5725e09e953d3728",
    "sha256": "08e845dff21811c106caf90103805e17df6d2c9851520b7c622ae0df50591d1b",
    "seconds": 7.2,
    "loop": true,
    "audio": false
  },
  "availableLanguages": [
    "en",
    "zh-Hans",
    "th",
    "ar"
  ],
  "editions": {
    "en": "https://proof21.xyz/journal/one-artifact-three-decisions/",
    "zh-Hans": "https://proof21.xyz/zh-hans/journal/one-artifact-three-decisions/",
    "th": "https://proof21.xyz/th/journal/one-artifact-three-decisions/",
    "ar": "https://proof21.xyz/ar/journal/one-artifact-three-decisions/"
  }
}