Quy trình khiếu nại

Khi có tranh chấp về một hồ sơ bản quyền trên Registry

Trang này mô tả đúng workflow kỹ thuật hiện tại của hệ thống: từ lúc gửi khiếu nại, kiểm tra chống spam và Captcha, tiếp nhận, rà soát quản trị cho tới các tình huống chấp thuận, từ chối hoặc đóng hồ sơ.

Nguyên tắc quan trọng: việc gửi khiếu nại không tự động gỡ một Evidence khỏi Registry. Hồ sơ vẫn được xử lý theo workflow quản trị. Chỉ quyết định APPROVED mới thực hiện tác động cưỡng chế đã được lập trình cho Evidence cũ.

2. Gửi và tiếp nhận khiếu nại

Form khiếu nại công khai gắn với một Evidence ID cụ thể. Backend chỉ tiếp nhận nếu hồ sơ đang ở trạng thái SEALED và đang hiển thị PUBLIC.

Thông tin người khiếu nại

Họ tên 2–160 ký tự, email liên hệ tùy chọn nhưng phải hợp lệ nếu cung cấp.

Quan hệ với quyền

Có các lựa chọn: author, rights_holder, authorized_representative, licensee hoặc other.

Nội dung vụ việc

Tiêu đề 5–200 ký tự; nội dung 20–5.000 ký tự; có thể gửi tối đa 5 liên kết chứng minh và các liên kết này phải là HTTPS.

Cam kết

Người gửi phải xác nhận thông tin cung cấp là trung thực và có căn cứ.

Sau khi tiếp nhận thành công

1. Tạo mã tham chiếu
Dạng CP-....
2. Lưu trạng thái
Trạng thái ban đầu là OPEN.
3. Thông báo quản trị
Hệ thống có cơ chế gửi thông báo Telegram cho quản trị khi một đơn được nhận.

3. Lớp bảo vệ đầu vào

Trước khi đơn đi vào hàng chờ quản trị, backend có các lớp kiểm tra nhằm hạn chế spam và dữ liệu không hợp lệ.

Anti-spam theo IP

Mỗi IP được theo dõi trong bộ nhớ của tiến trình Node. Khi vượt quá 3 đơn liên tiếp, hệ thống chặn 1 giờ ở cấp đầu; các lần vi phạm tiếp theo có thể bị chặn 24 giờ. Bộ đếm giảm dần theo thời gian để hạ nhiệt.

Cloudflare Turnstile

Khi backend được cấu hình secret Turnstile, token phải được xác minh thành công trước khi lưu đơn. Nếu chưa cấu hình secret, lớp này được bỏ qua.

AI lọc rác trước hàng chờ

Hệ thống có thể dùng AI để nhận diện nội dung vô nghĩa, chửi bới, spam hoặc yêu cầu không liên quan. Nếu AI đánh giá is_spam=true và confidence > 0,8, đơn được ghi nhận ở trạng thái REJECTED ngay tại bước tiếp nhận và không đi tiếp vào luồng duyệt thủ công.

Nếu dịch vụ AI lỗi, workflow được thiết kế để bỏ qua lớp AI và cho phép đơn đi vào duyệt thủ công.

4. Luồng xử lý quản trị

Bước 01
OPEN
Đơn hợp lệ đã được lưu.
Bước 02
UNDER_REVIEW
Quản trị viên rà soát.
Bước 03
APPROVED
Chấp thuận khiếu nại.
Bước 04
REJECTED / CLOSED
Kết thúc hoặc từ chối.

Workflow API cho phép quản trị chuyển trạng thái giữa UNDER_REVIEW, APPROVED, REJECTED và CLOSED. Backend không áp đặt một máy trạng thái chỉ đi một chiều; do đó tài liệu này mô tả ý nghĩa của từng quyết định thay vì hứa hẹn mọi chuyển đổi đều được bật trong giao diện.

5. Ý nghĩa từng trạng thái

Trạng tháiÝ nghĩa trong workflowTác động lên Evidence
OPENĐơn hợp lệ đã được tiếp nhận.Chưa có enforcement tự động đối với Evidence chỉ vì đơn được mở.
UNDER_REVIEWĐang được quản trị viên xem xét.Không có đoạn workflow hiện tại nào tự động gỡ Evidence chỉ vì trạng thái này.
APPROVEDKhiếu nại được chấp thuận.Evidence chuyển sang REMOVED, OTS bị disable, lịch kiểm tra OTS bị dừng và hash được giải phóng để khai báo lại.
REJECTEDKhiếu nại bị từ chối.Endpoint xử lý khiếu nại không thực hiện enforcement lên Evidence cho quyết định này.
CLOSEDĐóng case.Việc đóng case không tự động khôi phục Evidence đã từng bị APPROVED; workflow restore không nằm trong endpoint quyết định khiếu nại hiện tại.

6. Các tình huống có thể xảy ra

Tình huống A — Khiếu nại được chấp thuận

Backend cập nhật case thành APPROVED, ghi enforcement vào Evidence Chain, chuyển visibility của hồ sơ sang REMOVED, đặt ots_disabled=true và dừng lịch OTS tiếp theo. Hash của file cũ được giải phóng để có thể khai báo lại theo quy trình xác minh áp dụng.

Tình huống B — Khiếu nại bị từ chối

Case chuyển sang REJECTED. Đoạn xử lý hiện tại không thay đổi visibility/Ots của Evidence. Lý do quyết định được lưu và có thể được đưa vào email thông báo.

Tình huống C — Đơn được đưa vào UNDER_REVIEW

Đây là trạng thái rà soát; chưa có enforcement tự động lên Evidence. Quản trị viên phải tiếp tục đưa ra quyết định hoặc đóng case.

Tình huống D — Đóng case sau khi đã APPROVED

Trạng thái complaint có thể được chuyển sang CLOSED, nhưng endpoint hiện tại không có nhánh restore. Vì vậy CLOSED không đồng nghĩa với việc Evidence cũ tự xuất hiện lại.

Tình huống E — Đơn bị AI đánh dấu spam

Nếu AI kết luận spam với confidence > 0,8, hệ thống vẫn ghi complaint record nhưng ở trạng thái REJECTED và trả về lỗi REJECTED_BY_AI. Đơn không bước vào hàng chờ quản trị.

Tình huống F — Vượt ngưỡng chống spam

Khi vượt ngưỡng gửi liên tiếp theo IP, request bị trả 429 SPAM_BLOCKED. Đây là lớp bảo vệ đầu vào và không phải quyết định về nội dung bản quyền.

7. Ảnh hưởng đến Evidence, OTS và Registry

Trước khi APPROVED

OPEN hoặc UNDER_REVIEW chỉ là trạng thái của case. Workflow complaint không tự chuyển một Evidence PUBLIC thành REMOVED ở hai trạng thái này.

Khi APPROVED

Visibility → REMOVED; OTS → disabled; lịch OTS tiếp theo bị dừng; Evidence Event ghi COMPLAINT_APPROVED; redeclaration được ghi rõ trong event payload.

R2 / OTS

Workflow moderation của hệ thống có cơ chế xóa object OTS đã stage trên R2 khi Evidence bị gỡ. Điều này nằm trong lớp enforcement/storage chứ không phải trong bản thân form khiếu nại.

Hash & khai báo lại

Khi complaint APPROVED, workflow hiện tại ghi nhận rằng hash được giải phóng để file có thể được khai báo lại theo quy trình áp dụng.

8. Thông báo cho các bên

Hệ thống có hai lớp thông báo liên quan đến khiếu nại.

Thông báo quản trị

Khi complaint hợp lệ được tạo, backend gọi cơ chế thông báo Telegram cho quản trị viên nếu kênh Telegram đã được cấu hình.

Email quyết định

Khi quản trị xử lý case và SMTP hoạt động, email quyết định được lưu trạng thái gửi. Người khiếu nại được gửi thông báo nếu có email; khi APPROVED, chủ hồ sơ cũng có thể được thông báo nếu email của họ khác email người khiếu nại.

Mã tham chiếu

Mỗi complaint có complaint_ref dạng CP-.... Nên giữ mã này trong mọi trao đổi hỗ trợ liên quan.

9. Audit và khả năng truy vết

Khi quản trị xử lý complaint, hệ thống ghi audit với action PROCESS_COMPLAINT, mã complaint, trạng thái, enforcement action, lý do và thông tin gửi mail.

Evidence Chain

Khi APPROVED, hệ thống append một Evidence Event loại COMPLAINT_APPROVED. Event chain của Evidence được thiết kế immutable trong hoạt động bình thường, vì vậy quyết định xử lý được lưu như một phần lịch sử của hồ sơ thay vì sửa ngược event cũ.

10. Câu hỏi thường gặp

Gửi khiếu nại có làm Evidence biến mất ngay không?

Không. OPEN và UNDER_REVIEW không chứa nhánh enforcement tự động. Tác động gỡ khỏi public registry được thực hiện khi quyết định APPROVED.

REJECTED có xóa hồ sơ không?

Workflow complaint hiện tại không thực hiện enforcement lên Evidence khi decision là REJECTED.

APPROVED rồi CLOSED có tự khôi phục hồ sơ không?

Không theo endpoint khiếu nại hiện tại. CLOSED chỉ đóng case; không có nhánh restore trong thao tác này.

Nếu AI nhận nhầm complaint là spam thì sao?

Workflow hiện tại tự động REJECT khi confidence vượt ngưỡng 0,8. Khi lớp AI không hoạt động, code lại cho phép đơn đi tiếp vào duyệt thủ công. Trang này phản ánh đúng hành vi backend hiện tại; không coi AI là phán quyết pháp lý.

Thông tin nào được lưu trong complaint?

Workflow lưu complaint reference, Evidence record, thông tin người khiếu nại, quan hệ, subject, statement, links chứng minh, yêu cầu xử lý, cờ xác nhận, status, hash IP/user-agent và language code. IP và user-agent được lưu dạng SHA-256 hash thay vì plaintext.