ตรวจ ประเมิน ยอมรับ

เอเจนต์ผู้รับตัดสินใจแยกกันสามส่วน ได้แก่ ความสมบูรณ์ของอาร์ติแฟกต์ การประเมินหลักฐาน และการยอมรับตามนโยบาย

พฤติกรรมที่ผู้รับต้องมี

ผูก operation คำสั่ง โปรไฟล์/เวอร์ชัน สินทรัพย์/เครือข่าย ผู้ออกหรือกุญแจที่เชื่อถือ และข้อกำหนดความสดใหม่ ประเมินสถานะยืนยันขั้นสุดท้ายที่ต้องการและปฏิเสธการรีเพลย์หรือบริบทไม่ตรง ฟิลด์สำคัญที่ไม่รู้จัก หลักฐานหาย กุญแจไม่พร้อม หรือโปรไฟล์ไม่รองรับต้องไม่กลายเป็นความสำเร็จ

FAIL ที่ลงนามถูกต้องเป็นอาร์ติแฟกต์ถูกต้องแต่การประเมินไม่ผ่าน แม้ PASS ก็อาจยังต้อง REVIEW เมื่อผู้ออกไม่เป็นที่ยอมรับ หลักฐานเก่า หรือผู้รับต้องการข้อสังเกตอิสระที่ไม่มีในชุดข้อมูล

การตรวจในเครื่อง

หลักฐานเดิม กุญแจที่ยอมรับ และโปรไฟล์รุ่นที่ตรงกันทำให้ผู้บริโภคทำซ้ำการตรวจสอบที่รองรับในเครื่องได้ การตรวจสอบออฟไลน์ครอบคลุม snapshot ที่ได้รับ ส่วนการเพิกถอน ความใหม่ เชนหลัก และ finality ปัจจุบันอาจต้องมีหลักฐานออนไลน์เพิ่ม

สิทธิ์ยังแยกจากผลตัดสิน

SDK ต้องไม่เรียกกระเป๋าหรือปล่อย escrow เพียงเพราะรายงานมี PASS สิทธิ์และการควบคุมธุรกรรมเดิมยังทำงาน หากเกี่ยวข้องให้ตรวจเงื่อนไขที่ขึ้นกับสถานะอีกครั้งก่อนลงมือทันที เพราะรายงานก่อนทำงานอาจล้าสมัยระหว่างการตรวจกับการดำเนินงาน

การเชื่อมต่อ Alpha ใช้โหมดเฝ้าสังเกต ผู้รับบันทึกว่าจะยอมรับอะไรโดยไม่ให้ P21 ควบคุมเงินฝ่ายเดียว

<!-- p21-source-payment-v08 -->

แยกการตีความ การลงทะเบียน และกรรมสิทธิ์

ใบรับรองแยกการอ่านข้อมูลต้นทาง การลงทะเบียนองค์ประกอบ การคำนวณแบบกำหนดผลแน่นอน ความถูกต้องของการสร้างหรือมินต์โทเคน และกรรมสิทธิ์หรือยอดคงเหลือปัจจุบัน การตรวจข้อหนึ่งไม่ได้ยืนยันข้ออื่น การตรวจผู้ลงทะเบียนที่ถูกต้องรายแรกต้องมีดัชนีประวัติและกฎการเปิดใช้งาน หลักฐานว่า inscription อยู่ในบล็อกไม่พิสูจน์ว่าไม่เคยมีองค์ประกอบขัดแย้งก่อนหน้า

ตรึงแฮชเนื้อหา inscription โปรไฟล์แหล่งข้อมูล เวอร์ชันต้นน้ำ เครือข่าย แฮชและความสูงบล็อก การเข้ารหัสมาตรฐาน การดำเนินการ พารามิเตอร์ commitment ของอินพุต และผลลัพธ์ ระบุขอบเขตหลักฐานและข้อจำกัด ข้อมูลที่ขาดหรือรูปแบบที่ไม่รองรับให้ผล INDETERMINATE ไม่ใช่สร้างผลว่าถูกต้อง แยกข้อมูลที่ดัชนีรายงานจากสถานะที่เล่นซ้ำโดยอิสระ การใช้ฟิลด์ Bitcoin โดยตรงแทนต้องไม่แอบนับเป็นการตรวจทะเบียน DMT ที่ยังไม่ได้ทำ

[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-enforcement-v10 -->

การยอมรับไม่เขียนทับ proof หรือ settlement

ต้องเก็บสถานะแยกกัน เช่น VALID + PASS + CONFIRMED + REJECT เป็นสถานะที่ถูกต้องได้ REJECT ของผู้รับไม่เปลี่ยน artifact เป็น INVALID, ไม่เปลี่ยน evaluation เป็น FAIL และไม่ทำให้ settlement ที่ยืนยันบนเครือข่ายหายไป

artifact_integrity:   VALID
evaluation:           PASS
settlement:           CONFIRMED
consumer_decision:    REJECT

Policy precommitment และ signed decisions

หาก workflow ต้องการความรับผิดที่ตรวจซ้ำได้ ผู้รับควร commit acceptance-policy digest/version และช่วงเวลาที่ใช้ได้ก่อนอีกฝ่ายทำ protected action แล้วจึงลงนาม P21 decision receipt ภายหลัง ถ้า policy เป็น deterministic และหลักฐานครบ ผู้ตรวจอิสระอาจได้ CONTRADICTORY; ถ้ามี private/unavailable input ต้องเป็น UNRESOLVED

Optional execution gate

สำหรับ protected action สามารถใช้ action-bound authorization และ execution gate ซึ่งตรวจ digest จริง, policy/request, nonce, network, asset และ expiry ก่อนใช้สิทธิ์ ปัจจุบัน Alpha ยังเป็น non-custodial/shadow mode