EMILIA Protocol

โปรโตคอล EMILIA

---

เอเจนต์ AI กำลังกลายเป็นผู้ปฏิบัติงาน ผู้ปฏิบัติงานต้องการอำนาจอนุมัติ

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

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

• Authority Brain จับคู่พื้นผิวการกระทำที่ประกาศรองรับในเครื่อง ไม่ต้องใช้บัญชี อัปโหลด หรือ callback การค้นพบไม่ได้สร้างอำนาจอนุมัติ เจ้าของเป็นผู้ตรวจสอบแผนที่
• EMILIA Gate เปลี่ยนแผนที่และขอบเขตอำนาจปฏิบัติการที่ได้รับอนุมัติให้เป็นการควบคุมเชิงป้องกันบนเส้นทาง executor ที่ถือครองเครดิตและถูกควบคุมอย่างสมบูรณ์
• EMILIA Protocol คือโครงสร้างพื้นฐานแบบเปิดภายใต้ Apache-2.0 สำหรับเอกลักษณ์การกระทำที่แน่นอน การตรวจสอบหลักฐานต้นทาง การประกอบหลักฐาน สถานะการยอมรับที่คงทน และบันทึกงานที่พกพาได้
• EMILIA Approver บันทึกการตัดสินใจของมนุษย์ที่ผูกกับอุปกรณ์สำหรับการกระทำที่แน่นอนเมื่อขอบเขตหรือนโยบายท้องถิ่นต้องการอำนาจมนุษย์ใหม่ การคลิกของมนุษย์คือแหล่งอำนาจหนึ่งแหล่ง ไม่ใช่โมเดลการดำเนินการเริ่มต้น
• EMILIA Assurance Plane ให้การตรวจสอบที่จำกัดขอบเขต การดำเนินการซ้ำ รายงานความสอดคล้อง และหลักฐานการปรับใช้ รองรับผู้ตรวจสอบบัญชี ผู้รับประกันภัย ผู้กำกับดูแล และลูกค้า EMILIA ไม่ใช่ผู้ตรวจสอบบัญชีหรือผู้รับรองที่ได้รับการรับรอง และไม่มีโปรแกรมการรับรอง EMILIA สาธารณะที่ดำเนินการอยู่

รันแผนที่ในเครื่อง (npx @emilia-protocol/scan) เลือกเวิร์กโฟลว์ที่มีผลกระทบหนึ่งรายการ และวาง Gate ตรงจุดที่เครดิตผู้ให้บริการเปลี่ยนเจตนาให้เป็นงาน

โปรไฟล์การแจกจ่ายแบบ friction ต่ำแรกคือ GitHub: Merge Gate แบบเปิดผูกขอบเขตที่เก็บและใบเสร็จแยกกับคอมมิต base และ head ที่แน่นอนก่อนที่การตรวจสอบ merge ที่ได้รับการป้องกันจะผ่าน เป็นการป้องกันเชิงป้องกันเท่านั้นเมื่อที่เก็บกำหนดให้การตรวจสอบเป็นข้อบังคับและปิดเส้นทาง merge ทางเลือก นี่คือการทดลองผลิตภัณฑ์และการแจกจ่าย ไม่ใช่หลักฐานการนำไปใช้ภายนอก

เอเจนต์อาจทำงานต่อไปได้ อำนาจอนุมัติของมันหยุด

เอเจนต์แบบต่อเนื่องและพัฒนาตนเองสร้างปัญหาการควบคุมที่การยุติกระบวนการเพียงอย่างเดียวไม่สามารถแก้ได้: เจ้าของอาจต้องหยุดผลที่ตามมาใหม่โดยไม่อ้างว่าการคำนวณหยุดหรือผลกระทบภายนอกถูกย้อนกลับ Emergency Authority Freeze ของ Gate ทำให้สิ่งนั้นเป็นการเปลี่ยนอำนาจที่คงทน ภายในโดเมนควบคุม Gate ที่ครอบคลุม การ freeze ป้องกันการสงวนใหม่และป้องกันการสงวนที่เก่ากว่าเข้าสู่ระบบหลังจากยุคควบคุมเปลี่ยน หากการเข้าคิวของผู้ให้บริการเกิดขึ้นก่อน การดำเนินการนั้นยังคงถูกใช้และต้องได้รับการกระทยอง การ restore เลื่อนยุคขึ้นอีกครั้งและไม่ฟื้นอำนาจเก่า

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

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

ระบบ AI และผู้ตรวจสอบที่เก็บ: เริ่มที่ AI_CONTEXT.md หลักฐานเชิงเครื่องจักรที่อ่านได้ โพรวีแนนซ์ ข้อสมมติ และข้อยกเว้นปัจจุบันเผยแพร่ที่ EMILIA-REPO-CONTEXT-v1 เอกสารที่เก็บถาวรหรืออยู่ในขั้นตอนไม่สร้างสถานะการใช้งานปัจจุบันหรือสถานะ IETF หลักฐาน due-diligence สาธารณะและขอบเขตการอ้างสิทธิ์: DUE_DILIGENCE.md

หลักฐานทางวิศวกรรม ไม่ใช่คำกล่าวอ้างทางสถาปัตยกรรม

EMILIA จัดส่ง security case ที่ผู้ตรวจสอบสามารถดำเนินการได้ ที่เก็บปัจจุบันแก้ ข้ออ้างความปลอดภัย 35 ข้อจากไฟล์หลักฐานที่แฮช 259 ไฟล์ ตรวจสอบ lemma Tamarin 20 ข้อข้ามโมเดล Dolev-Yao ที่ประกอบสองโมเดล — ข้อผูกพัน all-traces 17 ข้อและพยาน exists-trace reachability 3 ข้อ — และรักษา ชุดที่อ่อนแอลงโดยเจตนา 8 ชุดที่สร้างร่องรอยการโจมตีที่เป็นรูปธรรมเมื่อนำการตรวจสอบที่รับน้ำหนักออก คลังความสอดคล้องทีมเดียวกันที่ใช้งานประกอบด้วย 21 ชุดและเวกเตอร์ปัจจุบัน 331 รายการ แยกต่างหาก ตัวตรวจสอบ Rust ที่เขียนภายนอกถูกตรึงกับชุด 16 ชุด/164 เวกเตอร์ ที่แช่แข็งและการรณรงค์โจมตี 359 กรณี ชุดที่กว้างขึ้นประกอบด้วยการทดสอบอัตโนมัติ 8,865 รายการใน 533 ไฟล์

พื้นผิว JavaScript และ JSDoc สำหรับการผลิตถูกตรวจสอบด้วยคอมไพเลอร์ด้วย TypeScript checkJs; แอปที่ปลอดภัยมีโปรเจกต์คอมไพเลอร์ความเข้ากันได้ของตัวเอง ขณะที่ declarations และ TypeScript SDK สาธารณะถูกตรวจสอบในโหมดเข้มงวด นี่คือการครอบคลุมการตรวจสอบประเภทการผลิตที่กำหนดค่าอย่างสมบูรณ์ ไม่ใช่การอ้างว่าที่เก็บถูกแปลงทั้งหมดจาก JavaScript เป็น TypeScript หรือทุกโปรเจกต์ JavaScript มีตัวเลือก strict ของ TypeScript เปิดใช้งาน

ข้ออ้างความปลอดภัยแต่ละข้อระบุเส้นทางการบังคับใช้ เวกเตอร์บวกและลบ ความครอบคลุมภาษา ขอบเขตทางการหรือช่องว่างที่ชัดเจน ข้อสมมติ ข้อยกเว้น และแฮชหลักฐาน เริ่มที่ แผนที่หลักฐานที่มนุษย์อ่านได้ จากนั้นตรวจสอบ security case ที่แก้แล้ว หรือรัน npm run check:security-case

AEB-1: ทดสอบขอบเขตหลักฐานต่อผลลัพธ์

ชุด AEB-1 Consequence Admission Conformance แบบเปิด ทดสอบจุดควบคุมสุดท้ายก่อนการกระทำที่มีผลกระทบ: การตรวจสอบต้นทาง การยอมรับของ relying party การจับคู่ CAID/การกระทำที่แน่นอน ความพอใจของหลักฐาน การอนุญาตท้องถิ่น การสงวนแบบอะตอม การดูแล INVOKING ผลลัพธ์ผู้ให้บริการและผลที่สังเกตแยกจากกัน พฤติกรรมไม่ลองซ้ำแบบไม่เห็นผล และการกระทยองที่รับรองความถูกต้อง

npx @emilia-protocol/verify aeb-conformance --reference

เป็นกลางต่อรูปแบบและรันด้วยตนเอง รายงานที่ผ่านคือหลักฐานความสอดคล้องที่ตนเองรับรอง — ไม่ใช่การตรวจสอบบัญชี การรับรอง การอ้างการใช้งานการผลิต หรือการอนุญาตให้ดำเนินการใดๆ

สำหรับการพิสูจน์ที่ดำเนินการได้ที่เน้นเส้นทาง Gate ของที่เก็บ ให้รัน:

npm run proof:gate:reference

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

เอกลักษณ์ไม่ใช่คำอธิบายงาน

เอกลักษณ์บอกว่าใครหรืออะไรกำลังเรียก นโยบายบอกว่าอะไรได้รับอนุญาตโดยทั่วไป ไม่มีสิ่งใดกำหนดงานจำกัดที่เอเจนต์อัตโนมัติอาจทำตอนนี้: ภารกิจ ขีดจำกัดการกระทำที่มีผลวัสดุ งบประมาณ หลักฐานที่ต้องการ วันหมดอายุ กฎการมอบหมาย และเส้นทางข้อยกเว้น

EMILIA แยกคำถามเหล่านั้น:

ชั้น	คำถาม
เอกลักษณ์	ใครหรืออะไรอยู่ตรงนี้?
นโยบาย	อะไรได้รับอนุญาตโดยทั่วไป?
อำนาจอนุมัติ	งานที่แน่นอนใดที่เอเจนต์นี้อาจทำภายใต้ขอบเขตนี้?

เครดิตให้การเข้าถึง อำนาจกำหนดงาน ไม่ใช่ทุกการกระทำที่ต้องการมนุษย์ ทุกการกระทำที่มีผลกระทบต้องการอำนาจที่ถูกต้อง

ที่รากฐาน EP Core ยังคงเปิดเผยอ็อบเจกต์ที่ทำงานร่วมกันได้สามรายการ: Trust Receipt นำหลักฐานที่ระบุแหล่งที่มา Trust Profile แทนสถานะความเชื่อถือที่มีโครงสร้าง และ Trust Decision บันทึกผลที่ประเมินนโยบายของ relying party ชั้นระนาบควบคุมอำนาจเพิ่มการผูกการกระทำที่แน่นอน ขอบเขตจำกัด การยอมรับ การใช้ และหลักฐานผลลัพธ์โดยไม่รวมอ็อบเจกต์เหล่านั้นเป็นข้ออ้างเดียว

---

กำหนดขอบเขตครั้งเดียว ปล่อยให้เอเจนต์ทำงาน

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

ตัวอย่าง MCP ที่มาพร้อมกันสาธิตโปรไฟล์นโยบายหนึ่งที่ต้องการการตัดสินใจของมนุษย์ใหม่ที่ขอบ ตัวอย่างรันลูปท้องถิ่นที่สมบูรณ์—หลักฐานที่ขาดถูกปฏิเสธ การกระทำที่แน่นอนถูกลงนาม ความพยายามผู้ให้บริการหนึ่งครั้งถูกยอมรับ หลักฐานปลอมถูกปฏิเสธ—โดยไม่อ้างว่าทุกการกระทำอัตโนมัติต้องการการคลิกของมนุษย์:

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

เดโมการประกอบที่ลึกกว่าดำเนินการชำระเงินที่มอบหมายผูก CAID ผ่านเส้นทางความสามารถขอบเขตจริงของ Gate จากนั้นตรวจสอบใบรับรองการดำเนินการที่ลงนามแบบออฟไลน์:

npm run demo:receipt-program

โดยจงใจไม่รวม blockchain หรือข้ออ้าง zero-knowledge จำลอง ดู สถาปัตยกรรมโปรแกรมใบเสร็จ สำหรับสถานะการผลิตและข้อกำหนดความเชื่อถือ

เริ่มด้วย dry run กับพื้นผิวเครื่องมือที่ประกาศของคุณ จากนั้นสร้างไฟล์บูรณาการที่ตรวจสอบได้:

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

การตรวจสอบท้องถิ่นที่สร้างขึ้นใช้สถานะเดโมหายไปอย่างชัดเจนและพิสูจน์เพียงว่า handler สังเคราะห์ของมันไม่ถูกเรียก การผลิตต้องมีบัญชี provenance ที่คงทน ที่เก็บการบริโภคอะตอมที่ใช้ร่วมกัน คีย์ที่ตรึง และ wrapper บนทุกเส้นทางไปยังเครดิตผู้ให้บริการจริง ดู examples/mcp/ และ /mcp

ลองใช้ใน 30 วินาที

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

ลองลงนามด้วย Face ID จริง → อนุมัติการโอนเงิน $82,000 ด้วย passkey ของคุณเอง ดูว่า VERIFIED มีลักษณะอย่างไร ปลอมใบเสร็จ ดูว่ามันล้มเหลว

ตรวจสอบใบเสร็จใดก็ได้ในเบราว์เซอร์ — วางมันลง ไม่มีการอัปโหลดอะไร

---

วิธีการทำงาน — วงจรชีวิตอำนาจหนึ่งรอบ

รันด้วยตัวเอง: node examples/crash-test.mjs — ออฟไลน์เต็มรูปแบบ ไม่ต้องใช้ API key

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

ขอบเขต แหล่งอำนาจกำหนดงานจำกัด อาจเป็นโปรแกรมปฏิบัติการที่ลงนามโดยลูกค้า ความสามารถขอบเขต การตัดสินใจมนุษย์ที่จำเป็น องค์ประชุม หรือการประกอบหลักฐานต้นทางของ relying party

งานที่แน่นอน Gate ผูก method ต้นทาง callee เป้าหมาย การเกิดขึ้น และทุกฟิลด์ที่มีวัสดุเข้ากับอ็อบเจกต์ที่ดำเนินการได้ตามบัญญัติ เจตนา พรอมต์ หรือข้อความตั๋วไม่ใช่อ็อบเจกต์นั้น

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

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

สำหรับการปรับใช้ระดับองค์กร Gate อาจกำหนดการยืนยัน Authorization Server ที่ตรวจสอบอย่างอิสระที่ผูกกับหลักฐานมนุษย์ที่แน่นอนเดียวกัน การกระทำที่แน่นอนเดียวกัน สแนปชอตเอกลักษณ์ที่ AS สังเกตจริง และคีย์ Resource Server ที่ตั้งใจ เวลาสแนปชอตและอายุสูงสุดของ relying party ชัดเจน: โทเค็นใหม่ไม่สามารถทำให้ข้อมูลไดเรกทอรีล้าสมัยเป็นปัจจุบันได้ ขา AS เป็นหลักฐานภายใต้ความเชื่อถือที่ลูกค้าตรึง ไม่เคยอนุญาตด้วยตัวเอง พิสูจน์สถานะการจ้างงานทันที หรือเปลี่ยน orchestrator เอเจนต์เป็นอำนาจ ผลลัพธ์ที่ตรงไปตรงมา การยอมรับไม่ใช่การดำเนินการ และการดำเนินการไม่ใช่ผลกระทบ บันทึกลายเซ็นสามารถตรวจสอบได้แบบออฟไลน์ หลักฐานจากผู้ให้บริการและผู้สังเกตการณ์ยังคงแยกจากกัน การตอบกลับที่สูญหายกลายเป็น INDETERMINATE ซึ่งเป็นสถานะที่ต้องกระทบยอด—ไม่ใช่อนุญาตให้ลองใหม่ การแก้ไขคือการดำเนินการที่ได้รับอนุญาตใหม่ และไม่เคยเขียนทับผลลัพธ์เดิม

---

ทำไมนักพัฒนาถึงใช้มัน

เริ่มต้นด้วยการแมปงานในเครื่อง จากนั้นปกป้องพื้นผิวการดำเนินการที่ประกาศไว้หนึ่งรายการด้วย MCP server หรือตัวห่อหุ้ม SDK แบบบาง สแกนเนอร์เสนอแผนที่ที่ตรวจสอบได้ เจ้าของกำหนดอาณัติ Gate ถือครองข้อมูลประจำตัวของผู้ให้บริการและบังคับใช้การดำเนินการที่แน่นอนบนเส้นทางที่ครอบคลุม ไม่มีการสแกนใดพิสูจน์การไกล่เกลี่ยที่สมบูรณ์ และการค้นพบเพียงอย่างเดียวไม่ให้อำนาจใด ๆ

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

เอเจนต์ได้รับความสามารถในการทำงานภายใต้ขอบเขต ไม่ใช่ข้อมูลประจำตัวถาวรที่สามารถตีความใหม่ได้

---

ทำไมองค์กรถึงต้องการมัน

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

Gate และ Assurance Plane ที่มีการจัดการเพิ่มการดำเนินการด้านอาณัติ การผสานรวม การดำเนินการด้านหลักฐาน การดำเนินการซ้ำ การสนับสนุน และระดับบริการรอบโปรโตคอลเปิด ลูกค้ายังคงควบคุมอำนาจ รากความเชื่อถือ ข้อมูลประจำตัว นโยบาย และหลักฐานที่พกพาได้

---

มาตรฐาน

EMILIA Protocol เป็นโอเพนซอร์สภายใต้สัญญาอนุญาต Apache-2.0 งานด้านมาตรฐานได้รับการเผยแพร่เป็นกลุ่มเอกสาร Internet-Drafts รายบุคคล Internet-Draft ที่เผยแพร่ไม่ใช่ RFC ไม่ใช่รายการของกลุ่มทำงานที่รับรอง และไม่ใช่การรับรองจาก IETF; Datatracker เป็นแหล่งอ้างอิงที่เชื่อถือได้สำหรับการแก้ไขและสถานะ

พื้นผิวการนำเสนอสี่เอกสารตามมาตรฐาน

สำหรับการนำทางของผู้อ่าน เส้นทางหลักฐานตามมาตรฐานคือ:

1. Authorization Receipts-11 กำหนดโปรไฟล์หลักฐานการอนุมัติที่ผูกกับการดำเนินการ การแก้ไขที่เผยแพร่ปัจจุบันคือ -11 ยื่นเป็นเอกสารรายบุคคลผู้สมัครในสาย Standards Track
2. Human Authorization Binding-00 ผูกอาร์ติแฟกต์การอนุญาตของมนุษย์ที่มีชื่อเข้ากับระเบียนโฮสต์ที่อยู่ติดกัน
3. Authority Introduction-03 สร้างรากความเชื่อถือที่ปักหมุดโดยฝ่ายที่พึ่งพาและอำนาจที่มีขอบเขต
4. Authorization Evidence Chain-05 ประเมินว่าหลักฐานที่ตรวจสอบโดยกำเนิดและตรงกับการดำเนินการเป็นไปตามข้อกำหนดของฝ่ายที่พึ่งพาหรือไม่; มันส่งคืน SATISFIED หรือ UNSATISFIED, ไม่เคย AUTHORIZED

พื้นผิวสี่เอกสารนี้เป็นเพียงการนำเสนอเท่านั้น ไม่ได้รวม เลิกใช้ แทนที่ อัปเดต ทำให้ล้าสมัย ทำให้อยู่ใต้บังคับ หรือลดระดับเอกสารร่างใด ๆ ในกลุ่มเอกสารที่ใช้งานอยู่

แกนการดำเนินการรันไทม์แยกต่างหาก

เส้นทางรันไทม์คือ Architecture-02 → CAID-02 → AEC-05 → AEB-03: ขอบเขตระบบ การจับคู่การดำเนินการเชิงวัตถุที่แน่นอน ความพึงพอใจของหลักฐาน จากนั้นการยอมรับฝั่งผู้ดำเนินการและการถือครองผลลัพธ์ที่คงทน AEC ปรากฏในทั้งสองมุมมองเพราะความพึงพอใจของหลักฐานป้อนเข้าสู่การยอมรับรันไทม์ ไม่ใช่เพราะมุมมองทั้งสองเทียบเท่ากัน

กลุ่มเอกสารที่ใช้งานอยู่ทั้งหมดยังคงเป็น 23 ระเบียน Datatracker: 20 ระเบียน draft-schrock-* ที่ใช้งานอยู่และสามระเบียนที่มีผู้ร่วมเขียน แต่ละรายการมีขอบเขตและประวัติการแก้ไขของตนเอง ดู คู่มือมาตรฐาน, กลุ่มเอกสาร, และ รายการสถานะ ที่เครื่องอ่านได้

IETF Internet-Drafts	สแนปชอตท้องถิ่นปัจจุบัน: รายการที่เผยแพร่ · สถานะสดที่เชื่อถือได้: IETF Datatracker
ตัวตรวจสอบข้ามภาษา	JavaScript · Python · Go — ทั้งสามพิสูจน์แล้วว่าสอดคล้องกันบนเวกเตอร์การปฏิบัติตามข้อกำหนดเชิง adversarial ทุกการพุช (npm run conformance) เป็นการตรวจสอบความสอดคล้องข้ามพอร์ตของทีมเดียว ไม่ใช่การนำไปใช้แบบอิสระแบบ clean-room แยกต่างหาก การนำไปใช้ Rust จากสเปกที่เขียนโดยบุคคลภายนอก (ซอร์สสาธารณะ) ผ่านชุด 16-suite/164-vector ที่ปักหมุดและการรณรงค์ความเป็นศัตรู 359 กรณีที่ปักหมุดภายใต้การสร้างใหม่ที่ควบคุมโดยผู้ประเมินจากทรีซอร์สที่ไม่เปลี่ยนแปลง หลักฐานการสร้างที่เช็คอินยังคงลงนามโดยผู้ implementer ไม่ใช่การรับรองจากบุคคลที่สาม (คำแถลงที่ลงนาม); การยอมรับ clean-room อย่างเคร่งครัดรอ manifest ที่ได้รับการรับรองจากบุคคลที่สามที่แก้ไขแล้วและคีย์ attestor ที่ปักหมุดอย่างอิสระ
หลักฐานแบบจำลองเชิงรูปแบบ	คุณสมบัติความปลอดภัย TLA+ แบบมีขอบเขต 26 รายการที่คงอยู่ในสเปซสถานะที่กำหนดค่าไว้; นี่ไม่ใช่การปรับแต่งการนำไปใช้หรือการพิสูจน์แบบไม่มีขอบเขต · ข้อเท็จจริง Alloy 35 รายการ, การยืนยัน 32 รายการข้ามสี่โมเดล · โมเดล Dolev-Yao เชิงสัญลักษณ์แบบประกอบสองโมเดลครอบคลุม challenge, CAID, การอนุมัติสองรายการ, การปักหมุดผู้ออกและอำนาจ, มุมมอง registry, การเพิกถอน, การใช้งาน, การดำเนินการ, และขอบเขตการอ้างสิทธิ์เฉพาะหกรายการ บทตั้ง Tamarin ยี่สิบบทตรวจสอบ — 17 ข้อผูกพันแบบ all-traces และ 3 พยานแบบ exists-trace; แปดรูปแบบที่อ่อนแอลงโดยเจตนาสร้างร่องรอยการโจมตีที่เป็นรูปธรรมเมื่อการตรวจสอบที่รับน้ำหนักถูกลบออก (formal/tamarin/)
ทะเบียน MCP	Official MCP registry · Glama (Grade A, Official badge) · Smithery
สัญญาอนุญาต	Apache-2.0

พอร์ตอ้างอิงสามพอร์ตจากทีมเดียวกัน (JS / Python / Go) สอดคล้องกันข้ามทั้ง 21 ชุดและ 331 เวกเตอร์ แยกต่างหาก การนำไปใช้ Rust ที่เขียนโดยบุคคลภายนอกซึ่งสร้างใหม่จากทรีซอร์สสาธารณะที่ปักหมุดผ่านชุด clean-room 16-suite/164-vector ที่ปักหมุดและการรณรงค์ความเป็นศัตรู 359 กรณี ซึ่งรันซ้ำในเลน CI ของตัวเองทุกการเปลี่ยนแปลง ชุดการยอมรับ AEC และการแก้ไขสี่ผลลัพธ์ที่ใหม่กว่าไม่ได้ระบุว่าเป็นของ Rust นั่นคือหลักฐานการทำงานร่วมกันภายนอก ไม่ใช่การยอมรับการสร้างแบบ clean-room อย่างเคร่งครัด; กรณี CI รวมบันทึกจำนวนการยอมรับอย่างเคร่งครัดเป็นศูนย์จนกว่าจะมีการรับรองอิสระ ดู CONFORMANCE.md หรือตรวจสอบใบรับด้วยตัวเองที่ emiliaprotocol.ai/verify

---

สแตกอำนาจ

ชั้น	หน้าที่
อาณัติ	กำหนดภารกิจ ขีดจำกัด หลักฐาน การหมดอายุ การมอบหมาย และกฎข้อยกเว้น
CAID / การดำเนินการที่แน่นอน	ตรึงวัตถุที่ดำเนินการได้เชิงวัตถุเพื่อให้หลักฐานไม่สามารถย้ายไปยังงานอื่นได้
AEC	ประเมินว่าหลักฐานที่ตรวจสอบอย่างอิสระและตรงกันเป็นไปตามข้อกำหนดของฝ่ายที่พึ่งพาหรือไม่; มันไม่ได้อนุญาต
AEB / Gate	ตัดสินใจการอนุญาตในท้องถิ่น สำรองอำนาจที่ครอบคลุม และควบคุมการเข้าของผู้ให้บริการ
หลักฐานผลลัพธ์	รักษาความแตกต่างระหว่างการเรียกใช้ การตอบสนองของผู้ให้บริการ ผลที่สังเกตได้ และความไม่แน่นอน

---

จุดพิสูจน์

ตัวชี้วัด	ค่า
กรณีทดสอบอัตโนมัติ	8,865 รายการข้าม 533 ไฟล์; ทุกกรณีที่ใช้ได้กับแพลตฟอร์มต้องผ่าน
คุณสมบัติความปลอดภัย TLA+	อินเวอร์เรียนต์แบบมีขอบเขต 26 รายการที่คงอยู่ในสเปซสถานะที่กำหนดค่าไว้; ไม่ใช่การพิสูจน์การปรับแต่งการนำไปใช้หรือแบบไม่มีขอบเขต — ดู PROOF_STATUS.md
การยืนยันเชิงความสัมพันธ์ Alloy	ข้อเท็จจริง 35 รายการ + การยืนยัน 32 รายการข้ามสี่โมเดล — ตรวจสอบใน CI
กรณี red-team ที่จัดทำรายการ	85 — RED_TEAM_CASES.md
สถานะความปลอดภัยของการเผยแพร่	การตรวจสอบความปลอดภัยของ repository ผ่าน; ทุกข้อค้นพบ Strix ในการเปลี่ยนแปลงที่ตรวจสอบได้รับการแก้ไขด้วยความครอบคลุมการถดถอยและเธรดการตรวจสอบได้รับการแก้ไขแล้ว
การปฏิบัติตามข้อกำหนด (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
การปฏิบัติตามข้อกำหนดข้ามภาษา	331 เวกเตอร์ · 21 ชุด: ใบรับ · การลงนามอุปกรณ์ · การแก้ไขสี่ผลลัพธ์ · องค์ประชุมหลายฝ่าย · การเพิกถอน · Outcome Binding (เชิงความหมาย + real-crypto) · การรวมผู้ออก Authority Document/Proof · การรับรองเวลา · trust-receipt (2 โปรไฟล์) · provenance · ระเบียนหลักฐาน · canonicalization · ขอบเขต · การยอมรับ AEC · สกุลเงิน · การรับรองผู้ริเริ่ม · หลักฐานการใช้งาน · พยาน · หลักฐานเวลา (RFC 3161) ตัวตรวจสอบ JS / Python / Go สอดคล้องกัน (node conformance/run.mjs) พื้นฐาน Rust ภายนอกยังคงเป็น 164 เวกเตอร์ / 16 ชุด ดู CONFORMANCE.md
การสร้าง handshake p95	575ms ที่ 50 VUs — PERFORMANCE_PROOF.md

---

วัตถุหลักของโปรโตคอล

วัตถุ	คืออะไร
โปรแกรมอำนาจ / ความสามารถที่มีขอบเขต	อาณัติที่มีขอบเขตจำกัดพร้อมขอบเขต งบประมาณหรือหน่วย การหมดอายุ การมอบหมาย และกฎการใช้งานที่ชัดเจน
CAID	ตัวระบุตามมาตรฐานสำหรับการดำเนินการเชิงวัตถุหนึ่งรายการภายใต้โปรไฟล์การแมปที่มีชื่อ; การจับคู่ไม่ใช่การอนุญาต
ข้อกำหนดหลักฐานและผลลัพธ์ AEC	กฎที่ปักหมุดของฝ่ายที่พึ่งพาและการประเมิน SATISFIED, UNSATISFIED, หรือ INDETERMINATE
ระเบียนการยอมรับและ custody ของ AEB	ระเบียนฝั่งผู้ดำเนินการของการอนุญาต การสำรอง การเข้าของผู้ให้บริการ และสถานะการกระทบยอด
หลักฐานการอนุญาตและผลลัพธ์	อาร์ติแฟกต์แบบพกพาที่เป็น native หรือ EP ซึ่งคงผู้ออก ขอบเขต และขอบเขตการอ้างสิทธิ์ที่แน่นอน

---

เริ่มต้นด่วน

1. รัน npx @emilia-protocol/scan protect ./tools.json เพื่อแมปพื้นผิวที่ประกาศที่รองรับ
2. ตรวจสอบ manifest การดำเนินการที่สร้างขึ้น ฟิลด์เชิงวัตถุ ข้อมูลประจำตัว และจุดบอดที่มีชื่อ
3. ติดตั้ง Gate บนเส้นทางที่ถือครองข้อมูลประจำตัวของผู้ให้บริการและสถานะการใช้งานที่คงทน
4. กำหนดอาณัติการปฏิบัติงานและกฎข้อยกเว้นมนุษย์ใหม่หรือองค์ประชุมใด ๆ
5. รันกรณีการปฏิเสธ การดำเนินการที่แน่นอน การเล่นซ้ำ การหมดเวลา และการกระทบยอดก่อนเปิดใช้การบังคับใช้

เดโม 90 วินาที · เริ่มต้นด่วน · แนะนำเอเจนต์ · IETF Draft · Discord

---

EP คืออะไร — และไม่ใช่อะไร

EMILIA คือโครงสร้างพื้นฐานด้านอำนาจสำหรับงานอัตโนมัติ ไม่ใช่ระบบตัวตน กระเป๋าเงิน คะแนนชื่อเสียง รางการชำระเงิน หรือเอนจินนโยบายสากล

• คือ: ระนาบควบคุมสำหรับอาณัติการปฏิบัติงานที่มีขอบเขตจำกัด การตรวจสอบการดำเนินการที่แน่นอน สถานะการยอมรับที่คงทน ความไม่แน่นอนที่ตรงไปตรงมา และหลักฐานที่พกพาได้บนเส้นทางผู้ดำเนินการที่ครอบคลุม
• ไม่ใช่: สิ่งทดแทน OAuth/OIDC, workload identity หรือเอนจินนโยบาย สิ่งเหล่านั้นยังคงเป็นอินพุต native ภายใต้การปักหมุดของฝ่ายที่พึ่งพา
• ไม่ใช่: ข้อกำหนดให้มนุษย์อนุมัติทุกการดำเนินการ อาณัติอาจอนุญาตงานอัตโนมัติภายในขอบเขตจำกัดและเรียกร้องอำนาจใหม่เฉพาะที่ขอบ
• ไม่ใช่: หลักฐานว่าการดำเนินการที่ยอมรับดำเนินการสำเร็จหรือก่อให้เกิดผลตามที่ตั้งใจ
• ไม่ใช่: การควบคุมโปรโตคอลที่เป็นกรรมสิทธิ์ แกนหลักเป็น Apache-2.0 และ Internet-Drafts เป็นเอกสารรายบุคคล ไม่ใช่ RFC หรือการรับรองจาก IETF

ดู CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · พันธสัญญาความเป็นกลาง