NỀN TẢNG · CHECKID

Điều phối tin cậy

Luồng Định danh → xác minh → đảm bảo tin cậy → quyết định → tiếp tục → giám sát.

NGHIỆP VỤĐầu vào → Xử lý → Đầu ra
KIỂM SOÁTChính sách · rủi ro · tiêu chuẩn
BẰNG CHỨNGKết quả · truy vết · phạm vi
NỀN TẢNG

Điều phối tin cậy

Luồng Định danh → xác minh → đảm bảo tin cậy → quyết định → tiếp tục → giám sát.

Mục đích

Luồng Định danh → xác minh → đảm bảo tin cậy → quyết định → tiếp tục → giám sát.

Ranh giới tin cậy

Năng lực chỉ được công bố trong phạm vi có nguồn/bằng chứng.

Tích hợp cho nhà phát triển

SDK · REST API · bằng chứng đặc tả

↗
THAM CHIẾU KỸ THUẬT

Điều phối tin cậy: Mô hình quy trình tại thời điểm thực thi

Chủ thể → quy trình → bằng chứng → thực thi → trạng thái → quyết định/bằng chứng

Đặc tả hiện hành

CheckID đặc tả API V1.2.260123 dùng chủ thể và quy trình làm hai đơn vị chính. Một chủ thể có thể chứa nhiều quy trình; `POST /v1/create/process` tạo quy trình cho mục đích/process_type, `PUT /v1/perform/process` thực thi bằng chứng phù hợp, và `GET /v1/get/process/detail` đọc trạng thái/kết quả.

Không phát minh máy trạng thái

công khai nguồn hiện chỉ chứng minh các trạng thái/kết quả xuất hiện trong đặc tả mẫu, ví dụ `PROCESSING`, `ACCEPTED` và `perform_result` theo loại quy trình. Tài liệu công khai không biến một vòng đời mang tính khái niệm thành API máy trạng thái nếu nguồn không định nghĩa bảng chuyển đổi trạng thái.

Phân nhánh luồng và có điều kiện bằng chứng

Phân nhánh luồng phải xuất phát từ loại quy trình, mục đích, cấu hình và bằng chứng được yêu cầu bởi triển khai. Khi chính sách yêu cầu thêm bằng chứng, nội dung phải phân biệt “chính sách tăng cường xác minh” với cơ chế thử lại kỹ thuật do lỗi thu nhận hoặc lỗi nguồn.

Cơ chế thử lại, thời gian chờ và tính bất biến khi lặp

Nguồn trong ZIP chưa định nghĩa một chính sách chung cho cơ chế thử lại, thời gian chờ hoặc tính bất biến khi lặp. Các thuộc tính này phải được coi là đặc thù theo từng bản đặc tả hoặc chưa công bố công khai thay vì mặc định theo thông lệ REST.

Tích hợp bất đồng bộ

Website hiện không có có thẩm quyền webhook delivery đặc tả. Do đó callback/webhook cơ chế thử lại, thứ tự xử lý gói tin, kiểm soát chuyển phát trùng lặp, phòng chống tấn công phát lại phải được ghi là NOT PUBLICLY SPECIFIED cho tới khi API chủ sở hữu cung cấp nguồn.

Khả năng truy vết

Mỗi bước điều phối cần duy trì tương quan giữa chủ thể, quy trình, billcode/tham chiếu giao dịch và bằng chứng/kết quả ở nơi đặc tả hỗ trợ, để bên tin cậy có thể tái dựng quyết định mà không phụ thuộc vào một màn hình UI đơn lẻ.