Status
Draft • Baseline Candidate
Purpose
Thiết lập Core Identity Standard (CIS) v1.0 để mọi managed objects trong CFP+ có bộ thuộc tính định danh tối thiểu, phục vụ:
•định danh nghiệp vụ thống nhất (UNID),
•truy vết và tương thích ngược (Technical/Legacy IDs),
•export/import liên nền tảng,
•AI routing và tự động hóa,
•audit/rollback.
Managed Object definition
Managed object là bất kỳ record/page nào thuộc phạm vi CFP+ cần:
•quản trị vòng đời,
•truy vết governance,
•liên kết/ánh xạ liên nền tảng,
•hoặc được AI/hệ thống bên ngoài tham chiếu ổn định.
Managed objects có thể nằm trong Website, Work Orders, Templates, Evidence, Standards, Governance, Registry, Knowledge Library, AI artifacts...
Architecture update proposal — Chapter Namespace & Namespace Expansion (long-term)
Additive extension: không thay đổi baseline authority của UR; không thay đổi add-only; không ảnh hưởng Baseline v1.0 đang chuẩn bị trình phê duyệt.
1) Chapter-first identity (Chapter 0–9)
•Mọi managed object thuộc đúng 1 Chapter (0–9).
•“Chapter digit” được dùng như routing hint: nhìn ID biết object thuộc Chapter Root.
•Chapter nên được biểu diễn bằng metadata/property (ví dụ Chapter/Domain/Group) thay vì bắt buộc encode vào UNID để tránh phá tính platform-independent.
2) Descendant-first execution (operational)
•Cho phép object cấp Con/Cháu/Chắt hoạt động trước khi cấp trên hoàn chỉnh (placeholder/partial hierarchy).
•Yêu cầu tối thiểu: UNID/UNID Key (hoặc Reserved), Object Type, Status; có ghi chú audit về mức hoàn thiện.
3) Chapter-based allocation (parallel-safe)
•Cho phép cấp phát theo Chapter để nhiều AI triển khai song song.
•Tuy nhiên: UR vẫn là authority duy nhất cấp/commit UNID; uniqueness global vẫn do UR đảm bảo.
4) Namespace expansion (scale without longer IDs)
•Mở rộng bằng namespace mới (mỗi namespace có đủ 4 nhóm + 10 chapter), kế thừa standards + governance.
•UR vẫn là authority identity chung xuyên namespace.
4.1) Namespace replication (Governance clarification)
•Khi cần mở rộng quy mô: không kéo dài ID hoặc tạo nhiều tầng hậu duệ.
•Governance có thể tạo namespace mới (khái niệm V1 / V2 / V3 …) bằng cách sao chép nguyên kiến trúc chuẩn, gồm:
\t- 4 nhóm nội dung,
\t- 10 Chapter (0–9),
\t- kiến trúc điều hướng,
\t- governance rules,
\t- standards,
\t- registry mappings.
•Mỗi namespace hoạt động độc lập nhưng vẫn tuân theo cùng UR + CIS.
•Scope: cơ chế mở rộng ở cấp kiến trúc (namespace), không phải mở rộng ID; do đó không cần đưa mô hình ID nhiều tầng (con/cháu/chắt) vào CIS.
5) Governance Namespace (V) as Namespace Coordinator
•Namespace V đóng vai trò điều phối/khởi tạo namespace mới khi governance quyết định mở rộng.
Authority baseline (dependency rules)
•Universal Registry (UR) là authority duy nhất cấp và quản lý UNID.
•UNID/UNID Key trong các database nghiệp vụ chỉ là bản sao được kiểm soát để vận hành.
•Nếu có xung đột dữ liệu định danh → UR có precedence cao nhất đối với business identity.
Required core properties (mọi managed databases)
1) UNID (Number)
•Canonical business identity value (được cấp từ UR).
•Dùng cho filter/sort/batch/export/AI routing.
2) UNID Key (Text/Formula)
•Khóa hiển thị/search/export (khuyến nghị prefix cố định + zero-pad).
•Có thể là formula dựa trên UNID hoặc text được đồng bộ từ UR.
3) Technical ID (Text)
•Mã kỹ thuật/legacy (CFP-WEB-001, CFP-WO-001...).
•Không canonical; phục vụ traceability, compatibility, audit, rollback, migration.
4) Object Type (Select)
•Enum chuẩn để phân loại object.
•Không encode vào UNID.
5) Status (Status/Select)
•Trạng thái vòng đời theo domain.
•Nên map được về các trạng thái chuẩn ở UR (Reserved/Active/Redirected/Retired...).
Optional properties (khuyến nghị theo nhu cầu)
•Registry Entry (Relation → Universal Registry) — convenience layer trong Notion cho UX/audit/rollup; không phải canonical dependency.
•Owner (Person)
•Aliases (Text) — các mã/tên phụ (nếu chưa tách bảng alias)
•External Key / Public ID (Text/URL) — nếu object có public identifier riêng (website slug...) nhưng không nên nhầm với UNID.
•Created time / Last edited time (native)
Object Type enum (v1.0 baseline)
Principles
•Object Type là “class” ổn định, dùng cho routing/governance.
•Domain/Group/Chapter (nếu cần) là metadata riêng, không nằm trong UNID.
Candidate enum (có thể tinh chỉnh khi pilot)
•[Website.Page](http://Website.Page)
•Website.NavItem
•Ops.WorkOrder
•Ops.Template
•Evidence.Record
•Evidence.ReviewPackage
•Gov.Standard
•Gov.Decision
•Registry.Entry
•AI.Artifact
UNID and UNID Key rules
UNID rules
•UNID là immutable sau khi đăng ký.
•UNID không được tự cấp trong database nghiệp vụ.
•UNID không được tái sử dụng.
UNID Key rules
•Khuyến nghị format: `U-` + zero-pad cố định (ví dụ 7 chữ số): `U-0006314`.
•UNID Key phải ổn định cho search/copy/paste/export.
•Nếu thay đổi format ở tương lai: phải giữ backward compatibility (UR lưu legacy key hoặc có rule migrate).
Technical ID and alias rules
•Technical ID có thể đổi theo chuẩn nội bộ, nhưng phải:
\t- giữ alias/legacy values để trace,
\t- không làm mất khả năng rollback.
•Nếu một object có nhiều mã legacy: lưu trong Aliases hoặc bảng alias (v1.1).
Immutability rules
•UNID: immutable.
•Object Type: chỉ đổi khi có quyết định governance (đổi class ảnh hưởng routing).
•Technical ID: mutable nhưng phải trace.
•Registry Entry relation: convenience; có thể thiếu tạm thời trong pilot nhưng phải có cơ chế reconcile.
Registry relation rules (convenience layer)
•Business DB có thể có relation `Registry Entry` trỏ UR để:
\t- điều hướng nhanh,
\t- audit,
\t- rollup thuộc tính registry,
\t- kiểm tra divergence.
•Kiến trúc đa nền tảng không phụ thuộc relation này.
•Canonical precedence vẫn là UR.
Platform independence rules
•UNID/UNID Key phải dùng được ngoài Notion (CSV/JSON/API).
•Không encode Notion-specific identifiers vào UNID.
•Platform mappings nằm trong bảng Platform Mappings (PM), không nằm rải rác trong mọi DB.
AI routing requirements
•AI và automation khi cần định danh ổn định phải ưu tiên dùng:
\t1) UNID Key (giao tiếp/con người/LLM-friendly)
\t2) UNID (numeric canonical)
\t3) Technical ID (compat/trace)
•Không dùng Notion URL/page id làm business identity trong prompt/trao đổi liên nền tảng.
Export/import requirements
•Mọi export “managed objects” phải gồm tối thiểu: UNID, UNID Key, Object Type, Status, Technical ID (nếu có).
•Import phải có cơ chế reconcile với UR (không tạo UNID mới ngoài UR).
Compliance levels
•Level 0 — Unmanaged: không bắt buộc CIS.
•Level 1 — Managed (CIS): có đủ required core properties.
•Level 2 — Managed + Registry-linked: có Registry Entry relation và/hoặc PM mapping đầy đủ.
•Level 3 — Managed + Audited: có checklist validate định kỳ (uniqueness/divergence/mapping health).
Validation checklist (per database)
•[ ] UNID present (Number) cho mọi row thuộc managed scope.
•[ ] UNID unique trong phạm vi database (và reconcile với UR).
•[ ] UNID Key format đúng chuẩn.
•[ ] Object Type populated theo enum.
•[ ] Status populated.
•[ ] Technical ID populated nếu object có legacy ID.
•[ ] (Nếu có) Registry Entry relation trỏ đúng UR record.
Adoption roadmap (no-op until governance decision)
Phase 1 — Pilot add-only
•Thêm core properties (UNID, UNID Key, Technical ID, Object Type, Status, optional Registry Entry).
•Không sửa automation/workflow hiện hành.
Phase 2 — Backfill controlled
•Tạo UR records → propagate UNID vào business DB theo batch.
•Validate divergence.
Phase 3 — New records compliance
•Template/checklist để mọi record mới thuộc managed scope có UNID.
Pilot proposal (không triển khai nếu chưa có WO + phê duyệt)
Đề xuất 2–3 database pilot (giới hạn) để chứng minh CIS hoạt động mà không phá hệ vận hành:
1) Work Orders (WO)
2) Templates (TPL)
3) Evidence / Review Packages (EVD/RP)
Pilot chỉ add-only properties + backfill batch + reconcile với UR/PM.