EMILIA Protocol

EMILIA Protocol

---

AI agent đang trở thành người lao động. Người lao động cần thẩm quyền.

EMILIA là mặt phẳng điều khiển thẩm quyền cho công việc tự hành. Gate là ranh giới hệ quả nơi ý định có chứng thực của một agent trở thành thay đổi đối với tiền, mã nguồn, quyền hạn, hồ sơ, hoặc hạ tầng. Một con người hoặc tổ chức định nghĩa một phạm vi ủy quyền hoạt động hữu hạn; Gate kiểm tra đơn vị công việc chính xác đó so với phạm vi ủy quyền trước khi đường dẫn nhà cung cấp được bảo vệ có thể bắt đầu.

Gate là Tường lửa Hệ quả thương mại trên ranh giới đó. Nó xác minh thẩm quyền mà chủ sở hữu yêu cầu cho hành động chính xác, dành trước thẩm quyền đó trước khi vào nhà cung cấp, cho phép một lần thử nhà cung cấp được chấp nhận cho phiên bản ủy quyền được bao phủ trong miền thẩm quyền bền vững của nó, và để lại bằng chứng di động về những gì đường dẫn được bảo vệ đã chấp nhận và sau đó quan sát được. Khi kết quả không xác định, nó yêu cầu đối chiếu thay vì thử lại mù. Giao thức chứng minh. Gate ngăn chặn.

• Bộ não Thẩm quyền ánh xạ cục bộ các bề mặt hành động khai báo được hỗ trợ. Không cần tài khoản, tải lên, hoặc callback. Khám phá không tạo ra thẩm quyền; chủ sở hữu xem xét bản đồ.
• EMILIA Gate biến bản đồ đã phê duyệt và phạm vi ủy quyền hoạt động thành kiểm soát phòng ngừa trên một đường dẫn thực thi sở hữu chứng thực, được trung gian đầy đủ.
• EMILIA Protocol là nền tảng Apache-2.0 mở cho danh tính hành động chính xác, xác minh bằng chứng gốc, tổng hợp bằng chứng, trạng thái chấp nhận bền vững, và hồ sơ công việc di động.
• EMILIA Approver ghi lại quyết định con người gắn với thiết bị cho hành động chính xác khi phạm vi ủy quyền hoặc chính sách địa phương yêu cầu thẩm quyền con người mới. Một cú nhấp chuột của con người là một nguồn thẩm quyền, không phải mô hình thực thi mặc định.
• EMILIA Assurance Plane cung cấp xác minh có phạm vi, thực thi lại, báo cáo tuân thủ, và bằng chứng triển khai. Nó hỗ trợ kiểm toán viên, công ty bảo hiểm, cơ quan quản lý, và khách hàng; EMILIA không phải là kiểm toán viên hoặc chứng nhận viên được công nhận, và không có chương trình chứng nhận EMILIA công khai nào đang hoạt động.

Chạy bản đồ cục bộ (npx @emilia-protocol/scan), chọn một quy trình công việc hệ quả, và đặt Gate nơi chứng thực nhà cung cấp biến ý định thành công việc.

Hồ sơ phân phối ma sát thấp đầu tiên là GitHub: Merge Gate mở ràng buộc phạm vi ủy quyền thuộc sở hữu kho lưu trữ và biên nhận tách rời với các commit base và head chính xác trước khi kiểm tra merge được bảo vệ vượt qua. Nó chỉ mang tính phòng ngừa khi kho lưu trữ đặt kiểm tra ở chế độ bắt buộc và đóng các đường dẫn merge thay thế. Đây là một thử nghiệm sản phẩm và phân phối, không phải bằng chứng về việc áp dụng bên ngoài.

Agent có thể tiếp tục chạy. Thẩm quyền của nó dừng lại.

Các agent liên tục và tự cải thiện tạo ra một vấn đề kiểm soát mà việc chấm dứt tiến trình một mình không thể giải quyết: chủ sở hữu có thể cần dừng các hệ quả mới mà không khẳng định rằng tính toán đã dừng hoặc rằng một tác động bên ngoài đã bị đảo ngược. Emergency Authority Freeze của Gate biến điều đó thành một chuyển đổi thẩm quyền bền vững. Bên trong một miền kiểm soát Gate được bao phủ, freeze chặn các dự trữ mới và ngăn một dự trữ cũ đi vào sau khi epoch kiểm soát thay đổi. Nếu việc vào nhà cung cấp đã được tuần tự hóa trước, hoạt động vẫn bị tiêu thụ và phải được đối chiếu; restore tiến epoch thêm lần nữa và không hồi sinh thẩm quyền cũ.

Sự đảm bảo này yêu cầu trung gian hoàn toàn và trạng thái chia sẻ có thẩm quyền. Nó không dừng agent, hoàn tác một tác động đã vào, hoặc cung cấp freeze tức thì trên một miền thuê bao bị ngắt kết nối. Việc triển khai tham chiếu hiện tại bao phủ miền kiểm soát bộ nhớ cục bộ và PostgreSQL; truyền lan biên thuê bao và bằng chứng sự kiện freeze có chữ ký di động vẫn là các khoảng trống triển khai rõ ràng.

Quy trình công việc trả phí được đặt tên vẫn là xác định bất lợi y tế cần thiết có hỗ trợ AI của người trả tiền, theo một quy tắc an toàn: không có bằng chứng đánh giá có giấy phép hợp lệ, không có xác định bất lợi. Bằng chứng thiếu sẽ được chuyển đến đánh giá con người hợp pháp hoặc phương án dự phòng bảo vệ bệnh nhân; nó không phải là thẩm quyền để từ chối chăm sóc cần thiết về mặt y tế.

Hệ thống AI và người đánh giá kho lưu trữ: bắt đầu với AI_CONTEXT.md. Bằng chứng có thể đọc bằng máy hiện tại, nguồn gốc, giả định, và loại trừ được công bố tại EMILIA-REPO-CONTEXT-v1. Tài liệu lưu trữ hoặc đã qua giai đoạn không thiết lập trạng thái triển khai hoặc IETF hiện tại. Bằng chứng thẩm định công khai và ranh giới tuyên bố: DUE_DILIGENCE.md.

Bằng chứng kỹ thuật, không phải tuyên bố kiến trúc

EMILIA cung cấp một hồ sơ bảo mật mà người đánh giá có thể thực thi. Kho lưu trữ hiện tại giải quyết 35 tuyên bố bảo mật trên 259 tệp bằng chứng đã băm, xác minh 20 bổ đề Tamarin trên hai mô hình Dolev-Yao tổng hợp — 17 nghĩa vụ all-traces và 3 nhân chứng khả năng tiếp cận exists-trace — và bảo tồn 8 biến thể làm yếu có chủ đích tạo ra các dấu vết tấn công cụ thể khi các kiểm tra chịu tải bị loại bỏ. Bộ tuân thủ cùng nhóm trực tiếp chứa 21 bộ và 331 vector hiện tại. Riêng biệt, một bộ xác minh Rust do bên ngoài tác giả được ghim vào gói 16-bộ/164-vector đã đóng băng và một chiến dịch thù địch 359 trường hợp. Bộ rộng hơn chứa 8.865 bài kiểm tra tự động trên 533 tệp.

Các bề mặt JavaScript và JSDoc sản xuất được kiểm tra trình biên dịch với TypeScript checkJs; ứng dụng an toàn có dự án trình biên dịch tương thích riêng, trong khi khai báo và SDK TypeScript công khai được kiểm tra ở chế độ nghiêm ngặt. Đây là phạm vi bao phủ kiểm tra kiểu sản xuất đã cấu hình đầy đủ, không phải tuyên bố rằng kho lưu trữ đã được chuyển đổi toàn bộ từ JavaScript sang TypeScript hoặc rằng mọi dự án JavaScript đều bật tùy chọn strict của TypeScript.

Mỗi tuyên bố bảo mật nêu tên đường dẫn thực thi, vector tích cực và tiêu cực, phạm vi ngôn ngữ, phạm vi hình thức hoặc khoảng trống rõ ràng, giả định, loại trừ, và băm bằng chứng. Bắt đầu với bản đồ bằng chứng có thể đọc bởi con người, sau đó kiểm tra hồ sơ bảo mật đã giải quyết hoặc chạy npm run check:security-case.

AEB-1: kiểm tra ranh giới bằng chứng-đến-tác động

Gói AEB-1 Consequence Admission Conformance mở kiểm tra điểm kiểm soát cuối cùng trước một hành động hệ quả: xác minh gốc, chấp nhận của bên phụ thuộc, khớp CAID/hành động chính xác, thỏa mãn bằng chứng, ủy quyền địa phương, dự trữ nguyên tử, quyền giám hộ INVOKING, sự thật kết quả nhà cung cấp và tác động quan sát được tách biệt, hành vi không-thử-lại-mù, và đối chiếu có xác thực.

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

Nó trung lập về định dạng và tự chạy. Một báo cáo vượt qua là bằng chứng tuân thủ tự chứng nhận — không phải kiểm toán, chứng nhận, tuyên bố triển khai sản xuất, hoặc quyền thực thi một hành động.

Để có một bằng chứng thực thi tập trung về đường dẫn Gate của kho lưu trữ, chạy:

npm run proof:gate:reference

Lệnh này thực thi các ví dụ cục bộ và các ranh giới dịch vụ tập trung với khóa được tạo, trạng thái trong bộ nhớ, và hành vi nhà cung cấp giả lập. Đây là bằng chứng cục bộ hữu ích, không phải bằng chứng về một con người thực, ngân hàng bên ngoài, triển khai sản xuất, hoặc một tích hợp sản xuất đầu-cuối.

Danh tính không phải là mô tả công việc

Danh tính cho biết ai hoặc cái gì đang gọi. Chính sách cho biết điều gì được phép nói chung. Không cái nào định nghĩa công việc hữu hạn mà một agent tự hành có thể thực hiện ngay bây giờ: sứ mệnh của nó, giới hạn hành động vật chất, ngân sách, bằng chứng bắt buộc, thời hạn, quy tắc ủy quyền, và đường dẫn ngoại lệ.

EMILIA giữ các câu hỏi đó tách biệt:

Lớp	Câu hỏi
Danh tính	Ai hoặc cái gì đang hiện diện?
Chính sách	Điều gì được phép nói chung?
Thẩm quyền	Công việc chính xác nào mà agent này có thể thực hiện theo phạm vi ủy quyền này?

Chứng thực cấp quyền tiếp cận. Thẩm quyền định nghĩa công việc. Không phải mọi hành động đều cần con người; mọi hành động hệ quả cần thẩm quyền hợp lệ.

Ở nền tảng, EP Core vẫn hiển thị ba đối tượng tương tác: một Trust Receipt mang bằng chứng có thể quy kết, một Trust Profile đại diện trạng thái tin cậy có cấu trúc, và một Trust Decision ghi lại kết quả được đánh giá theo chính sách của bên phụ thuộc. Các lớp mặt phẳng điều khiển thẩm quyền thêm ràng buộc hành động chính xác, phạm vi ủy quyền hữu hạn, chấp nhận, tiêu thụ, và bằng chứng kết quả mà không gộp các đối tượng đó thành một tuyên bố duy nhất.

---

Đặt phạm vi ủy quyền một lần. Để agent làm việc.

Khách hàng định nghĩa sứ mệnh, giới hạn, yêu cầu bằng chứng, thời hạn, và quy tắc ngoại lệ. Mã cục bộ có thể thu hẹp thẩm quyền đó; nó không thể phát minh hoặc mở rộng nó. Gate ràng buộc mỗi yêu cầu thực thi với phạm vi ủy quyền, dành trước thẩm quyền được bao phủ trước khi vào nhà cung cấp, cho phép một lần thử nhà cung cấp được chấp nhận cho phiên bản ủy quyền đó bên trong miền thẩm quyền bền vững được chia sẻ, và leo thang chỉ khi thẩm quyền thiếu, lỗi thời, cạn kiệt, hoặc quá hẹp.

Các ví dụ MCP đi kèm minh họa một hồ sơ chính sách trong đó một quyết định con người mới được yêu cầu tại biên. Chúng chạy vòng lặp cục bộ hoàn chỉnh — bằng chứng thiếu bị từ chối, hành động chính xác được ký, một lần thử nhà cung cấp được chấp nhận, bằng chứng giả mạo bị từ chối — mà không khẳng định rằng mọi hành động tự hành cần một cú nhấp chuột của con người:

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

Bản demo tổng hợp sâu hơn thực thi một khoản thanh toán được ủy quyền ràng buộc CAID thông qua đường dẫn khả năng giới hạn thực của Gate, sau đó xác minh chứng chỉ thực thi đã ký ngoại tuyến:

npm run demo:receipt-program

Nó cố ý không bao gồm blockchain hoặc tuyên bố zero-knowledge mô phỏng. Xem kiến trúc chương trình biên nhận cho trạng thái sản xuất và yêu cầu tin cậy.

Bắt đầu với một lần chạy thử khô trên bề mặt công cụ đã khai báo của bạn, sau đó tạo các tệp tích hợp có thể xem xét:

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

Kiểm tra cục bộ được tạo sử dụng trạng thái demo phù du rõ ràng và chỉ chứng minh rằng trình xử lý tổng hợp của nó không được gọi. Sản xuất yêu cầu một sổ cái nguồn gốc bền vững, một kho lưu trữ tiêu thụ nguyên tử được chia sẻ, khóa được ghim, và wrapper trên mọi đường dẫn đến chứng thực nhà cung cấp thực. Xem examples/mcp/ và /mcp.

Dùng thử trong 30 giây

# 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

Thử xác nhận Face ID thực → Phê duyệt một chuyển khoản $82.000 bằng passkey của chính bạn. Xem VERIFIED trông như thế nào. Làm giả biên nhận. Xem nó thất bại.

Xác minh bất kỳ biên nhận nào trong trình duyệt của bạn — dán nó vào, không có gì được tải lên.

---

Cách hoạt động — một vòng đời thẩm quyền

Tự chạy: node examples/crash-test.mjs — hoàn toàn ngoại tuyến, không cần khóa API.

  [ 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

Phạm vi ủy quyền. Nguồn thẩm quyền định nghĩa công việc hữu hạn. Nó có thể là một chương trình hoạt động do khách hàng ký, khả năng giới hạn, quyết định con người bắt buộc, túc số, hoặc một tổ hợp bên phụ thuộc của bằng chứng gốc.

Công việc chính xác. Gate ràng buộc phương thức, nguồn gốc, đích đến, mục tiêu, lần xuất hiện, và mọi trường vật chất thành đối tượng thực thi chuẩn. Ý định, một lời nhắc, hoặc văn bản vé không phải là đối tượng đó.

Xác minh, dự trữ, và vào. Các tạo tác gốc vẫn giữ nguyên gốc. Bên phụ thuộc ghim hồ sơ tin cậy và ánh xạ, đánh giá yêu cầu bằng chứng hoàn chỉnh, đưa ra quyết định ủy quyền địa phương riêng biệt, và dự trữ thẩm quyền được bao phủ trước khi bộ điều hợp sở hữu chứng thực vào nhà cung cấp.

Thẩm quyền con người mới khi được yêu cầu. Một chính sách có thể yêu cầu quyết định WebAuthn/passkey ràng buộc với hành động chính xác và băm hiển thị xác định. Điều này thu hẹp khoảng cách "những gì bạn thấy là những gì bạn ký"; nó không chứng minh sự hiểu biết, sự khôn ngoan, tính hợp pháp, hoặc kết quả.

Đối với triển khai doanh nghiệp, Gate có thể bổ sung yêu cầu một xác nhận Authorization Server được xác minh độc lập ràng buộc với bằng chứng con người chính xác đó, cùng một hành động chính xác, ảnh chụp danh tính mà AS thực sự quan sát được, và khóa Resource Server dự kiến. Thời gian ảnh chụp và tuổi tối đa của bên phụ thuộc là rõ ràng: một token mới không thể làm cho dữ liệu thư mục lỗi thời trở nên hiện tại. Chân AS là bằng chứng dưới sự tin cậy do khách hàng ghim; nó không bao giờ tự ủy quyền, chứng minh tình trạng việc làm tức thời, hoặc biến bộ điều phối agent thành một thẩm quyền. Kết quả trung thực. Chấp nhận không phải là thực thi, và thực thi không phải là hiệu quả. Một bản ghi đã ký có thể được xác minh ngoại tuyến; bằng chứng của nhà cung cấp và người quan sát vẫn tách biệt. Một phản hồi bị mất trở thành INDETERMINATE, một trạng thái cần đối chiếu—không phải quyền thử lại. Một biện pháp khắc phục là một hành động được ủy quyền mới và không bao giờ ghi đè kết quả cũ.

---

Vì sao nhà phát triển sử dụng nó

Bắt đầu bằng cách lập bản đồ công việc cục bộ, sau đó bảo vệ một bề mặt hành động đã khai báo bằng MCP server hoặc trình bọc SDK mỏng. Máy quét đề xuất một bản đồ có thể xem xét; chủ sở hữu xác định phạm vi ủy quyền; Gate nắm giữ thông tin xác thực của nhà cung cấp và thực thi chính xác hành động trên đường dẫn được bao phủ. Không có quá trình quét nào chứng minh được sự trung gian hóa hoàn toàn, và việc phát hiện đơn thuần không trao quyền hạn nào.

# 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

Tác nhân nhận được khả năng thực hiện công việc có giới hạn, không phải một thông tin xác thực thường trực mà nó có thể diễn giải lại.

---

Vì sao doanh nghiệp cần nó

Các tiến trình tác nhân khởi động lại và các mô hình thay đổi. Phạm vi ủy quyền, trạng thái tiêu thụ, thu hồi, sự không chắc chắn và lịch sử công việc của khách hàng phải tồn tại bên ngoài chúng. EMILIA giữ trạng thái quyền hạn bền vững đó tại ranh giới của khách hàng trong khi chấp nhận bằng chứng bên ngoài thông qua các bộ điều hợp được ghim.

Cổng Gate được quản lý và Assurance Plane bổ sung các thao tác phạm vi ủy quyền, tích hợp, thao tác bằng chứng, thực thi lại, hỗ trợ và mức dịch vụ xung quanh giao thức mở. Khách hàng giữ quyền kiểm soát quyền hạn, gốc tin cậy, thông tin xác thực, chính sách và bằng chứng di động.

---

Tiêu chuẩn

EMILIA Protocol là giao thức mở và Apache-2.0. Công việc chuẩn hóa của nó được công bố dưới dạng một danh mục các Internet-Draft cá nhân. Một Internet-Draft đã công bố không phải là RFC, không phải mục của nhóm làm việc được thông qua, cũng không phải sự xác nhận của IETF; Datatracker là nguồn có thẩm quyền về sửa đổi và trạng thái.

Bề mặt trình bày bốn tài liệu chuẩn

Để thuận tiện cho người đọc, đường dẫn bằng chứng chuẩn là:

1. Authorization Receipts-11 định nghĩa hồ sơ bằng chứng phê duyệt gắn với hành động. Bản sửa đổi hiện được đăng là -11, được nộp như một bài nộp cá nhân ứng viên theo dõi Tiêu chuẩn.
2. Human Authorization Binding-00 gắn một tạo tác ủy quyền của con người có tên vào một bản ghi máy chủ liền kề.
3. Authority Introduction-03 thiết lập các gốc tin cậy được ghim bởi bên phụ thuộc và quyền hạn có phạm vi.
4. Authorization Evidence Chain-05 đánh giá liệu bằng chứng được xác minh gốc, khớp hành động có đáp ứng yêu cầu của bên phụ thuộc hay không; nó trả về SATISFIED hoặc UNSATISFIED, không bao giờ AUTHORIZED.

Bề mặt bốn tài liệu này chỉ mang tính trình bày. Nó không hợp nhất, rút lui, thay thế, cập nhật, làm lỗi thời, hạ cấp hoặc giáng cấp bất kỳ bản nháp nào trong danh mục đang hoạt động.

Trục thực thi thời gian chạy riêng biệt

Đường dẫn thực thi thời gian chạy là Architecture-02 → CAID-02 → AEC-05 → AEB-03: ranh giới hệ thống, khớp chính xác hành động vật chất, thỏa mãn bằng chứng, sau đó là chấp nhận phía bên thực thi và lưu giữ hậu quả bền vững. AEC xuất hiện trong cả hai chế độ xem vì thỏa mãn bằng chứng cung cấp đầu vào cho chấp nhận thời gian chạy, không phải vì hai chế độ xem tương đương nhau.

Danh mục đang hoạt động đầy đủ vẫn là 23 bản ghi Datatracker: 20 bản ghi draft-schrock-* đang hoạt động và ba bản ghi đồng tác giả, mỗi bản có phạm vi và lịch sử sửa đổi riêng. Xem hướng dẫn chuẩn, danh mục và kiểm kê trạng thái có thể đọc bằng máy.

IETF Internet-Drafts	Ảnh chụp cục bộ hiện tại: kiểm kê đã đăng · trạng thái trực tiếp có thẩm quyền: IETF Datatracker
Trình xác minh đa ngôn ngữ	JavaScript · Python · Go — cả ba đều được chứng minh khớp nhau trên các vector tuân thủ đối kháng, ở mọi lần đẩy (npm run conformance). Đây là kiểm tra nhất quán giữa các bản chuyển của một nhóm, không phải các triển khai độc lập kiểu clean-room. Riêng biệt, một triển khai Rust được viết bên ngoài theo đặc tả (nguồn công khai) vượt qua bộ 16 bộ kiểm thử/164 vector được ghim và chiến dịch thù địch 359 trường hợp được ghim dưới quá trình xây dựng lại do người đánh giá kiểm soát từ cây nguồn bất biến. Bằng chứng xây dựng được kiểm tra của nó vẫn do người triển khai ký, không được bên thứ ba chứng thực (tuyên bố có chữ ký); việc chấp nhận clean-room nghiêm ngặt chờ bản kê khai được bên thứ ba chứng thực đã hiệu chỉnh và khóa người chứng thực được ghim độc lập.
Bằng chứng mô hình hình thức	26 thuộc tính an toàn TLA+ có giới hạn được giữ trong các không gian trạng thái đã cấu hình; đây không phải là tinh chỉnh triển khai hay chứng minh không giới hạn · 35 sự kiện Alloy, 32 khẳng định trên bốn mô hình · hai mô hình Dolev-Yao tượng trưng kết hợp bao phủ thử thách, CAID, hai phê duyệt, ghim nhà phát hành và quyền hạn, chế độ xem sổ đăng ký, thu hồi, tiêu thụ, thực thi và sáu ranh giới tuyên bố chuyên dụng. Hai mươi bổ đề Tamarin được xác minh — 17 nghĩa vụ toàn vết và 3 nhân chứng tồn tại-vết; tám biến thể bị làm yếu có chủ đích tạo ra các vết tấn công cụ thể khi các kiểm tra chịu lực bị loại bỏ (formal/tamarin/).
Sổ đăng ký MCP	Sổ đăng ký MCP chính thức · Glama (Hạng A, huy hiệu Chính thức) · Smithery
Giấy phép	Apache-2.0

Ba bản chuyển tham chiếu cùng nhóm (JS / Python / Go) khớp nhau trên tất cả 21 bộ kiểm thử và 331 vector. Riêng biệt, một triển khai Rust được viết bên ngoài, được xây dựng lại từ cây nguồn công khai được ghim, vượt qua bộ clean-room 16 bộ kiểm thử/164 vector được ghim và chiến dịch thù địch 359 trường hợp, được chạy lại trong làn CI riêng của nó ở mọi thay đổi. Các bộ kiểm thử chấp nhận AEC mới hơn và phân giải bốn kết quả không được gán cho Rust. Đó là bằng chứng khả năng tương tác bên ngoài, không phải chấp nhận xây dựng clean-room nghiêm ngặt; trường hợp CI tổng hợp ghi nhận số lần chấp nhận nghiêm ngặt là không cho đến khi có chứng thực độc lập. Xem CONFORMANCE.md, hoặc tự xác minh một biên nhận tại emiliaprotocol.ai/verify.

---

Ngăn xếp quyền hạn

Lớp	Chức năng
Phạm vi ủy quyền (Mandate)	Xác định sứ mệnh, giới hạn, bằng chứng, thời hạn, ủy quyền lại và các quy tắc ngoại lệ.
CAID / hành động chính xác	Đóng băng đối tượng thực thi vật chất để bằng chứng không thể chuyển sang công việc khác.
AEC	Đánh giá liệu bằng chứng được xác minh độc lập và khớp có đáp ứng yêu cầu của bên phụ thuộc hay không; nó không ủy quyền.
AEB / Gate	Đưa ra quyết định ủy quyền cục bộ, dành quyền hạn được bao phủ và kiểm soát việc vào của nhà cung cấp.
Bằng chứng kết quả	Giữ cho lời gọi, phản hồi của nhà cung cấp, hiệu quả quan sát được và sự không chắc chắn tách biệt.

---

Điểm chứng minh

Chỉ số	Giá trị
Trường hợp kiểm thử tự động	8.865 trên 533 tệp; mọi trường hợp áp dụng cho nền tảng phải vượt qua
Thuộc tính an toàn TLA+	26 bất biến có giới hạn được giữ trong không gian trạng thái đã cấu hình; không phải chứng minh tinh chỉnh triển khai hay không giới hạn — xem PROOF_STATUS.md
Khẳng định quan hệ Alloy	35 sự kiện + 32 khẳng định trên bốn mô hình — được xác minh trong CI
Trường hợp đội đỏ được lập danh mục	85 — RED_TEAM_CASES.md
Trạng thái bảo mật bản phát hành	Các kiểm tra bảo mật của kho lưu trữ đều vượt qua; mọi phát hiện Strix trên các thay đổi được kiểm toán đều được khắc phục kèm phạm vi hồi quy và chuỗi đánh giá của nó đã được giải quyết
Tuân thủ (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Tuân thủ đa ngôn ngữ	331 vector · 21 bộ kiểm thử: biên nhận · xác nhận thiết bị · phân giải bốn kết quả · túc số đa bên · thu hồi · Ràng buộc Kết quả (ngữ nghĩa + mật mã thực) · nối nhà phát hành Tài liệu/Bằng chứng Quyền hạn · chứng thực thời gian · biên nhận tin cậy (x2 hồ sơ) · nguồn gốc · bản ghi bằng chứng · chuẩn hóa · ranh giới · chấp nhận AEC · tiền tệ · chứng thực người khởi tạo · bằng chứng tiêu thụ · nhân chứng · bằng chứng dấu thời gian (RFC 3161). Các trình xác minh JS / Python / Go khớp nhau (node conformance/run.mjs). Đường cơ sở Rust bên ngoài vẫn là 164 vector / 16 bộ kiểm thử. Xem CONFORMANCE.md.
Tạo bắt tay p95	575ms tại 50 VU — PERFORMANCE_PROOF.md

---

Đối tượng giao thức lõi

Đối tượng	Nó là gì
Chương trình quyền hạn / khả năng có giới hạn	Một phạm vi ủy quyền hữu hạn với phạm vi, ngân sách hoặc đơn vị, thời hạn, ủy quyền lại và quy tắc tiêu thụ rõ ràng.
CAID	Một định danh chuẩn cho một hành động vật chất theo một hồ sơ ánh xạ có tên; khớp không phải là ủy quyền.
Yêu cầu bằng chứng và kết quả AEC	Quy tắc được ghim của bên phụ thuộc và đánh giá SATISFIED, UNSATISFIED hoặc INDETERMINATE của nó.
Bản ghi chấp nhận và lưu giữ AEB	Bản ghi phía bên thực thi về ủy quyền, dành trước, vào của nhà cung cấp và trạng thái đối chiếu.
Bằng chứng ủy quyền và kết quả	Các tạo tác EP hoặc gốc di động giữ nguyên nhà phát hành, phạm vi và ranh giới tuyên bố chính xác của chúng.

---

Bắt đầu nhanh

1. Chạy npx @emilia-protocol/scan protect ./tools.json để lập bản đồ các bề mặt đã khai báo được hỗ trợ.
2. Xem xét bản kê khai hành động được tạo, các trường vật chất, thông tin xác thực và các điểm mù được đặt tên.
3. Cài đặt Gate trên đường dẫn nắm giữ thông tin xác thực của nhà cung cấp và trạng thái tiêu thụ bền vững.
4. Xác định phạm vi ủy quyền vận hành và mọi quy tắc ngoại lệ con người mới hoặc túc số.
5. Chạy các trường hợp từ chối, hành động chính xác, phát lại, hết thời gian và đối chiếu trước khi bật thực thi.

Bản demo 90 giây · Bắt đầu nhanh · Hướng dẫn tác nhân · IETF Draft · Discord

---

EP là gì — và không phải là gì

EMILIA là hạ tầng quyền hạn cho công việc tự động, không phải hệ thống danh tính, ví, điểm uy tín, đường ray thanh toán hay công cụ chính sách phổ quát.

• Là: một mặt phẳng điều khiển cho các phạm vi ủy quyền vận hành hữu hạn, xác minh hành động chính xác, trạng thái chấp nhận bền vững, sự không chắc chắn trung thực và bằng chứng di động trên các đường dẫn thực thi được bao phủ.
• Không phải: sự thay thế cho OAuth/OIDC, danh tính khối lượng công việc hoặc công cụ chính sách. Chúng vẫn là các đầu vào gốc dưới các ghim của bên phụ thuộc.
• Không phải: yêu cầu con người phê duyệt mọi hành động. Một phạm vi ủy quyền có thể cho phép công việc tự động trong các giới hạn hữu hạn và chỉ yêu cầu quyền hạn mới ở ranh giới.
• Không phải: bằng chứng rằng một hành động được chấp nhận đã thực thi thành công hoặc gây ra hiệu quả dự kiến.
• Không phải: kiểm soát giao thức độc quyền. Phần lõi là Apache-2.0 và các Internet-Draft là các bài nộp cá nhân, không phải RFC hay sự xác nhận của IETF.

Xem CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutrality Covenant