Status
Draft • Baseline Candidate
Purpose
Thiết lập Universal Registry v1.0 như lớp quản trị định danh nghiệp vụ thống nhất cho CFP+, cung cấp:
•UNID (Universal Numeric ID) duy nhất toàn cục cho mọi managed objects.
•Cơ chế cấp phát, quản trị vòng đời, audit và truy vết thay đổi.
•Lớp ánh xạ đa nền tảng (Notion/Website/Drive/GitHub/...) không khóa kiến trúc vào một platform.
Scope
Áp dụng cho mọi managed objects trong phạm vi CFP+ (Website, Work Orders, Templates, Evidence, Registry, Standards, Governance, Knowledge Library, AI artifacts...).
Không thay đổi/can thiệp:
•Notion Page ID / Database ID.
•Relations/Rollups/Formulas/Automations/API hiện hành (add-only).
Architecture Role
•Identity Control Plane của CFP+.
•Nguồn “authority record” duy nhất cho business identity (UNID).
•Cung cấp platform bindings (mappings) cho mọi tài nguyên kỹ thuật trên từng nền tảng.
Authority and Precedence
Definitions
•UNID: canonical business identity (danh tính nghiệp vụ) của một managed object.
•Universal Registry (UR): canonical authority record quản trị UNID (nơi có thẩm quyền).
•Business database record: bản ghi nghiệp vụ trong Notion (WO, template, evidence...), có thể lưu bản sao UNID để vận hành.
•Platform Mapping: bản ghi ánh xạ kỹ thuật giữa UNID và tài nguyên trên một nền tảng.
Authority rule
1) Universal Registry là authority duy nhất cấp, quản lý và quyết định trạng thái của UNID.
2) Các database nghiệp vụ:
\t- không được tự cấp UNID độc lập;
\t- không được tự sửa UNID sau khi đã đăng ký;
\t- chỉ lưu bản sao được kiểm soát của UNID/UNID Key để filter/sort/export/AI routing.
3) Nếu có khác biệt giữa UR, database nghiệp vụ, hoặc Platform Mapping → UR có thẩm quyền cao nhất đối với business identity.
Data Model
Mô hình v1.0 gồm:
1) Universal Registry — Entity Master (UR)
2) Platform Mappings — Platform Binding Records (PM)
3) UNID Counter / controlled allocation mechanism
4) Core Identity properties trong các managed databases (theo Core Identity Standard v1.0)
5) Registry Entry relation như convenience layer trong Notion (không canonical dependency)
Universal Registry schema (UR)
Mỗi row = 1 managed object = 1 UNID.
Required properties
•UNID (Number) — global unique; immutable
•UNID Key (Text/Formula) — search/export friendly (khuyến nghị pad + prefix)
•Object Type (Select) — theo enum chuẩn
•Status (Status/Select) — theo lifecycle chuẩn
•Title/Label (Text) — nhãn mô tả độc lập platform (không phụ thuộc Notion title)
Recommended properties
•Technical ID (primary) (Text) — legacy/prefix ID (nếu có)
•Technical IDs / Aliases (Text) — danh sách alias (hoặc tách bảng Alias ở v1.1)
•Owner (Person)
•Notes / Audit (Text)
•Created time / Last edited time (native)
Platform Mappings schema (PM)
Mỗi row = 1 binding giữa UNID và một platform resource.
Required properties
•Registry Entry (Relation → UR)
•Platform (Select) — Notion / Website / Google Drive / GitHub / ...
•External ID (Text) — ID kỹ thuật (page_id/file_id/repo_id/...)
•External URL (URL) — link mở trực tiếp
•External Type (Select) — page / database / file / repo / issue / ...
•Mapping Status (Select) — Active / Replaced / Broken / Archived
Recommended properties
•Scope/Environment (Select) — prod / staging / draft
•Observed Title (Text) — snapshot tên tại thời điểm mapping
•Last Verified (Date)
•Notes (Text)
UNID allocation mechanism
Goals
•Đảm bảo global uniqueness.
•Tránh race condition.
•Cho phép cấp phát có kiểm soát (governance).
Architecture update proposal — Chapter Namespace & Namespace Expansion (long-term)
Additive extension: không thay đổi nguyên tắc authority hiện hành; không thay đổi add-only; không ảnh hưởng Baseline v1.0 đang chuẩn bị trình phê duyệt.
A) Chapter-first identity (routing layer)
•Mọi managed object thuộc đúng 1 Chapter (0–9).
•Chapter digit (0–9) được dùng làm “routing hint” để nhìn ID biết object thuộc Chapter Root.
•Lưu ý: trong UR/CIS, “Chapter” là metadata phục vụ routing/governance; UNID vẫn là canonical numeric identity và không encode business meaning bắt buộc nếu điều đó làm tăng rủi ro về compatibility.
B) Descendant-first execution (operational rule)
•Chapter là Root Authority (“Ông”), nhưng các object ở cấp Con/Cháu/Chắt được phép hoạt động trước khi cấp trên hoàn thiện.
•Cho phép tạo placeholder + nghiên cứu/viết/review/chuẩn bị liên kết trong khi quan hệ phân cấp được hoàn thiện dần.
•Yêu cầu tối thiểu để “hoạt động trước”:
\t- có UNID/UNID Key hợp lệ (hoặc Reserved nếu chưa Active),
\t- có Object Type và trạng thái lifecycle tối thiểu,
\t- có ghi chú rõ “placeholder/partial hierarchy” trong Audit/Notes.
C) Chapter-based allocation (parallel-safe)
•Bổ sung lựa chọn: allocator theo Chapter để nhiều AI triển khai song song, giảm xung đột.
•Invariant vẫn giữ nguyên: UR là authority duy nhất; uniqueness được đảm bảo ở UR.
•Hình thức triển khai (định hướng v1.x): mỗi Chapter có “allocation lane” riêng (counter/queue), nhưng commit cuối cùng vẫn ghi vào UR theo quy trình controlled allocation.
D) Namespace expansion (scale without longer IDs)
•Không mở rộng bằng cách kéo dài ID; mở rộng bằng Namespace Expansion.
•Mỗi namespace mới:
\t- giữ nguyên kiến trúc chuẩn,
\t- có đầy đủ 4 nhóm và 10 chapter,
\t- kế thừa architecture/governance/standards/routing model của namespace gốc.
•Universal Registry tiếp tục là authority chung quản lý identity xuyên namespace.
D.1) Namespace replication (Governance clarification)
•Khi cần mở rộng quy mô: không mở rộng bằng cách kéo dài ID hoặc thêm nhiều tầng hậu duệ.
•Governance có thể tạo namespace mới và sao chép nguyên một kiến trúc chuẩn, bao gồm:
\t- đầy đủ 4 nhóm nội dung,
\t- đầy đủ 10 Chapter (0–9),
\t- toàn bộ kiến trúc điều hướng,
\t- governance rules,
\t- standards,
\t- registry mappings.
•Ví dụ (khái niệm): V1 / V2 / V3 … mỗi namespace có cùng cấu trúc chuẩn.
•Mỗi namespace hoạt động độc lập nhưng vẫn tuân theo cùng Universal Registry và Core Identity Standard.
•Scope: đây là cơ chế mở rộng kiến trúc (namespace), không phải cơ chế mở rộng ID; do đó không cần bổ sung mô hình ID nhiều tầng (con/cháu/chắt) trong UR/CIS.
E) Governance Namespace (V) as Namespace Coordinator
•Mở rộng vai trò namespace V: ngoài governance, là “namespace coordinator” sẵn sàng khởi tạo namespace mới khi có quyết định governance.
v1.0 controlled allocation options
1) Manual-safe allocation (khuyến nghị v1.0)
\t- Cấp UNID bằng thao tác có checklist.
\t- UR là nơi tạo record trước; sau đó mới propagate vào các DB nghiệp vụ.
2) UNID Counter database (semi-controlled)
\t- 1 row counter “Global Next UNID”.
\t- Quy trình: reserve → increment → commit UR.
3) External allocator (v1.x)
\t- Script/automation cấp UNID + tạo UR/PM atomically.
Allocation invariant
•UNID chỉ được tạo mới trong UR thông qua cơ chế controlled allocation.
•UNID không được tái sử dụng sau retirement.
Identity lifecycle
Lifecycle states (UR.Status)
•Reserved: UNID đã được giữ chỗ, chưa gắn object chính thức.
•Active: UNID đang đại diện một managed object.
•Redirected: UNID cũ chuyển hướng sang UNID mới (merge/replace).
•Retired: UNID ngừng dùng, không tái sử dụng.
•Deleted: chỉ dùng trong trường hợp bắt buộc; ưu tiên Retired + audit hơn.
State transition rules (high-level)
•Reserved → Active (khi đã có object và mapping tối thiểu)
•Active → Redirected (khi merge/replace)
•Active → Retired (khi kết thúc vòng đời)
•Redirected → Retired (khi đóng vòng đời redirect)
Status lifecycle (platform mappings)
•Active: mapping hiện hành
•Replaced: mapping cũ được thay bằng mapping mới
•Broken: link/id không còn hợp lệ (cần xử lý)
•Archived: mapping giữ để audit nhưng không còn dùng
Redirect, merge, retirement, deletion rules
Redirect
•Khi một object được thay thế bởi object khác nhưng cần giữ traceability.
•UR record cũ chuyển Status = Redirected và lưu UNID target (v1.1: explicit property).
Merge
•Nhiều UNID trỏ về một object canonical.
•Mọi UNID không canonical chuyển Redirected → canonical UNID.
Retirement
•Khi object không còn dùng, set Retired.
•UNID không bao giờ được tái sử dụng.
Deletion
•Tránh dùng. Nếu bắt buộc: phải giữ audit trail và bằng chứng.
Validation rules
Global uniqueness
•UNID phải unique trong UR.
Required field completeness (Active)
UR.Status = Active phải có tối thiểu:
•UNID, UNID Key, Object Type, Status, Title/Label
•≥1 platform mapping “primary” hoặc giải thích lý do chưa có mapping
Format
•UNID Key: prefix cố định + zero-pad (khuyến nghị) để search/export ổn định.
Audit requirements
•Mọi thay đổi trạng thái UR phải truy vết được (who/when/why).
•Mọi Redirect/Merge phải có rationale.
•Platform mappings phải có lịch sử thay thế (Replaced) thay vì overwrite.
Migration rules
•Migration là add-only: không phá Technical ID, không phá automation.
•Backfill theo batch nhỏ, có kiểm tra uniqueness.
•Khi backfill, tạo UR record trước → sau đó propagate UNID vào business DB.
Rollback plan
•Nếu pilot thất bại:
\t- Dừng propagate UNID.
\t- Giữ UR/PM như lớp tham chiếu (không xóa), set trạng thái phù hợp.
\t- Không cần sửa relations/rollups hiện có.
Operational risks
•Trùng UNID do cấp phát không kiểm soát.
•Divergence giữa UR và business DB do người dùng sửa tay.
•Mapping drift (URL thay đổi, resources bị move/delete).
•Search nhiễu nếu UNID Key không có prefix/pad.
Acceptance criteria
•Có thể tạo mới UR record và cấp UNID duy nhất toàn cục.
•Có thể tạo PM record cho Notion và ít nhất 1 nền tảng khác (mẫu).
•Pilot 2–3 database: backfill UNID không phá workflow hiện hành.
•Có checklist validate: uniqueness, completeness, divergence detection.
Pilot proposal (không triển khai nếu chưa có WO + phê duyệt)
Đề xuất pilot giới hạn 2–3 database có lợi ích rõ ràng và ít rủi ro:
1) Work Orders (WO): dễ thấy giá trị filter/sort/audit + có Technical ID sẵn.
2) Templates (TPL): thường được tham chiếu nhiều, cần ổn định export.
3) Evidence / Review Packages (EVD/RP): yêu cầu traceability cao.
Pilot chỉ bao gồm: thêm property theo CIS + backfill theo batch + tạo UR/PM records tương ứng.
Không thay đổi schema/automation hiện hành ngoài add-only.