Câu hỏi trang này trả lời: ai dùng sản phẩm, ai được phục vụ, ai xây, và ai chịu trách nhiệm khi có chuyện.

Nguyên tắc gốc: vai là năng lực theo ngữ cảnh, không phải nhãn vĩnh viễn

Đa số nền tảng chia người dùng thành các tầng lớp cố định: người bán, người mua, người kiểm duyệt. DubaiGift từ chối cách chia đó, vì nó giết chết chính hành vi cần khuyến khích.

Mọi người vừa là người tặng vừa là người nhận. Một người có thể tặng một giờ kèm cặp vào buổi sáng và nhận một cuốn sách số vào buổi chiều. Hệ quyền được thiết kế quanh năng lực trong một ngữ cảnh, không quanh nhãn gắn lên tài khoản.

Một trong các chỉ số sản phẩm được theo dõi chính là tỷ lệ người vượt qua ranh giới vai — tỷ lệ người từng chỉ nhận rồi trở thành người tặng. Nếu tỷ lệ đó thấp, sản phẩm đã trượt về mô hình phát chẩn, không phải mạng lưới.

Mười ba vai trong hệ thống

Sơ đồ

Sơ đồ: Mười ba vai chia làm ba nhóm — người dùng, tổ chức, vận hành nền tảng — cộng hai vai đặc biệt: đại sứ giai đoạn sau và trợ lý AI với quyền uỷ nhiệm có giới hạn.

Vai đáng chú ý nhất là vai cuối: trợ lý AI được coi là một chủ thể có quyền, và quyền đó luôn là quyền được uỷ nhiệm, có phạm vi và được ghi vết. Trợ lý không bao giờ nhận đặc quyền không giới hạn — nguyên tắc này được cài vào mô hình phân quyền chứ không chỉ nằm trong hướng dẫn.

Bốn chân dung người dùng chính

Chân dung	Hoàn cảnh	Điều họ cần từ DubaiGift
Người có kỹ năng, ít tiền	Sinh viên, người mới ra nghề, người làm tự do	Một cách để thứ mình biết trở thành thứ tặng được — và được ghi nhận vì đã tặng
Người bận, có tiền, thiếu ý tưởng	Người đi làm, phải tặng vào các dịp	Trợ lý biến hoàn cảnh người nhận thành một kế hoạch quà cụ thể, không phải một danh sách sản phẩm
Người cần nhưng ngại xin	Người mới tới, gia đình khó khăn, người đang chuyển nghề	Một khung giữ được phẩm giá: có điều kiện rõ, cách chọn minh bạch, không phải cầu xin công khai
Người tổ chức cộng đồng	Quản trị nhóm nghề, nhóm thành phố, nhóm trường, nhóm công ty	Quỹ quà có sổ cái, sứ mệnh có mục tiêu đo được, hàng đợi kiểm duyệt riêng của cộng đồng

Bên tổ chức: doanh nghiệp, nhà cung cấp, tổ chức xã hội

Nhóm	Họ làm gì trên nền tảng	Đã dựng tới đâu
Nhà cung cấp	Đăng ký → nộp hồ sơ pháp lý và vận hành → chọn ngành và vùng phục vụ → nộp tài liệu thẩm định → cấu hình danh mục → qua vòng rà soát theo ngành → chạy thử giới hạn → tốt nghiệp lên trạng thái đã thẩm định sau khi giao hàng thành công	✅ Toàn bộ quy trình; 🔧 tải tài liệu còn là bản rỗng gắn cờ, chưa bật
Doanh nghiệp tài trợ	Tạo chiến dịch quà được tài trợ, xác định đối tượng và điều kiện, phân bổ số lượng, xem hiệu quả	✅ Phần máy chủ; 🔧 giao diện tài trợ chưa dựng
Tổ chức xã hội và công ích	Tạo sứ mệnh đã thẩm định, đặt tiêu chí người thụ hưởng, quy trình bằng chứng, báo cáo kết quả	✅ Đầy đủ

Điểm quan trọng về nhà cung cấp: hệ thống không phơi ra một điểm tổng mờ đục. Chất lượng được đo trên chín chiều — tỷ lệ giao thành công · đúng hạn · hài lòng của người nhận · tỷ lệ khiếu nại và hoàn trả · bằng chứng xác thực · chất lượng trình bày · mức độ phản hồi · khả năng cá nhân hoá · độ tin cậy theo địa bàn — và mỗi chiều hiển thị kèm giải thích.

Cùng với đó là một luật cứng: vị trí được tài trợ không bao giờ được lặng lẽ vượt qua bộ lọc phù hợp và tin cậy. Luật này không được cài bằng lời dặn mà bằng kiểu dữ liệu: cấu trúc ứng viên trong bước lọc không có trường tài trợ, và thông tin tài trợ chỉ được nạp sau khi lọc xong.

Ai xây

Nhóm	Vai trò
Chủ sở hữu sản phẩm (David)	Chốt định hướng, quyết các điểm mâu thuẫn được nêu thành văn bản, và giữ quyền quyết định cuối về những cổng mà máy không tự đóng được
Đội kỹ thuật	Xây theo mốc, mỗi mốc có "điều kiện qua" đo được; không mốc nào được tuyên bố xong khi mới có khung rỗng
Sáu vai kiểm tra chéo trong quy trình	Kiến trúc · hiện thực · rà soát chất lượng · chạy kiểm thử · rà soát an ninh · viết tài liệu — mỗi vai có tiêu chí riêng, và việc nhạy cảm bắt buộc phải qua rà soát an ninh trước khi hợp nhất

Luật vận hành có ảnh hưởng lớn nhất tới chất lượng: bản vá phải quay lại đúng người đã bắt lỗi. Trong đợt rà soát lớp AI, chính luật này là thứ duy nhất bắt được sáu lỗi liên tiếp — trong đó ba lần bản vá của chính đội mở ra lỗ mới, và một lần bản vá "khoá theo tài khoản" đã vô tình gỡ bỏ giới hạn tần suất khỏi mọi đường ẩn danh.

Ai chịu trách nhiệm khi có chuyện

Đây là phần thường thiếu ở tài liệu giới thiệu, nên nói rõ ba tầng:

Sơ đồ

Sơ đồ: Ba tầng trách nhiệm — xử lý có ghi lý do, nhật ký không sửa được, và quyền khiếu nại tới một người xử lý khác.

Ba điều được cài cứng:

Nhật ký kiểm duyệt là bất biến ở tầng cơ sở dữ liệu — mọi lệnh sửa hoặc xoá đều bị từ chối, kể cả từ tài khoản quản trị. Nó được cài bằng cơ chế ràng buộc mọi đường vào, không phải bằng phân quyền cho một vai.
Quy tắc hồi tị là luật trong mã nguồn, không phải quy ước. Người xử lý có liên quan tới vụ việc — sở hữu nội dung, thuộc tổ chức liên quan, hoặc chính là người đã ra quyết định bị khiếu nại — thì bị từ chối ở tầng hệ thống.
Có một ngoại lệ được cố ý giữ: "người tôi sắp xử lý có báo cáo về tôi" không được coi là căn cứ hồi tị. Vì việc nộp báo cáo là hành vi một chiều, nếu tính là hồi tị thì bất kỳ ai cũng có thể tự miễn nhiễm bằng cách báo cáo hết toàn bộ đội kiểm duyệt.

Một điều còn để ngỏ

Có một điểm đã được nêu thành văn bản và đang chờ quyết định: khi một người bị hạn chế mà họ là thành viên duy nhất của một tổ chức, tổ chức đó bị đình chỉ theo. Vì cơ chế này kế thừa quyền của lệnh hạn chế người, một người xử lý có liên quan tới tổ chức đó về lý thuyết có thể đình chỉ tổ chức một cách gián tiếp, đi vòng qua quy tắc hồi tị trực tiếp.

Mức rủi ro được đánh giá thấp — vì toàn bộ đường đi đều có nhật ký và người bị ảnh hưởng khiếu nại được — nhưng nó được ghi ra, không bị giấu đi. Cách xử lý đúng là quyết định của chủ sở hữu sản phẩm, không phải của đội kỹ thuật.

Câu chốt: thiết kế người dùng của DubaiGift đặt cược vào một điều: nếu vai không bị đóng khung, người ta sẽ vượt qua nó. Người từng nhận sẽ tặng. Đó là lý do "tỷ lệ vượt ranh giới vai" là chỉ số đáng theo dõi hơn số người đăng ký.