P3D Principle — Thuật ngữ chuẩn + Ma trận đa chiều + DB sống của thực thể

Date: 2026-05-12 Author: GPT-5.5 Thinking / Incomex Hội đồng AI Source: User directive + terminology-glossary.md + dieu26-pivot-law.md + composition-level-law.md Status: Governing principle for P3D Pack 1 before continuing Phase 5C2

0. Vì sao có principle này

Trong P3D Pack 1, nếu chỉ xử lý species + composition_level như hai field riêng lẻ thì sẽ sai tinh thần thiết kế ban đầu.

Thiết kế gốc yêu cầu:

- thuật ngữ phải chính xác tuyệt đối;
- metadata phải là ma trận đa chiều;
- mỗi thực thể có DB sống của chính nó;
- counting/monitoring dùng Pivot, không dùng logic Nuxt/code;
- thêm/sửa phân loại bằng metadata/registry, không bằng hardcode;
- dữ liệu thông minh lên theo thời gian để phục vụ Điều 39.

1. Thuật ngữ chuẩn, bắt buộc dùng đúng

1.1. Tầng

Tầng dùng cho kiến trúc kỹ thuật toàn hệ thống theo Điều 5:

Tầng 1: Hạ tầng kỹ thuật
Tầng 2: Cơ sở — registries, metadata, DOT, fields, taxonomy, pivot, birth
Tầng 3: Modules nền tảng
Tầng 4: Chuyên môn / business
Tầng 5: Giám sát + cải tiến

Không dùng “tầng nguyên tử”. Cụm đó sai.

1.2. Lớp

Lớp dùng cho cấu tạo vật chất thông tin theo Điều 0-B:

Lớp 1: nguyên tử / atom
Lớp 2: phân tử / molecule
Lớp 3: hợp chất / compound
Lớp 4: vật liệu / material
Lớp 5: sản phẩm / product
Lớp 6: công trình / building

Loài / species là meta-layer đứng ngoài 6 lớp.

Cách gọi đúng:

6 lớp + 1 loài

1.3. Layer

Layer dùng cho navigation / UI / Pivot theo Điều 26:

Layer 1: Tổng hợp
Layer 2: Danh sách nhóm
Layer 3: Danh sách cá thể
Layer 4: Chi tiết cá thể
Layer 5: Ma trận đa chiều

Layer không phải Tầng. Layer cũng không phải Lớp cấu tạo.

1.4. Lớp 3 — DB sống của entity

Lớp 3 trong ngữ cảnh Điều 21 / glossary là trang chi tiết sống của mỗi entity, không phải Lớp 3 hợp chất trong Điều 0-B.

Để tránh nhầm, trong P3D nên gọi rõ:

Entity Living DB / DB sống của entity

Nó có 6 heading:

Identity
Relations
Dependencies
History
Labels
Metrics

2. Ma trận đa chiều là contract nền

Metadata không được hiểu là một cây đơn giản hoặc CASE ladder.

Mỗi entity là một điểm/tọa độ trong ma trận nhiều chiều, ít nhất gồm:

species / loài
composition_level / lớp cấu tạo
identity_class
unit_kind
section_type
publication_type
publication_authority_ref
lifecycle_status
conformance_status
owner_lookup_ref
labels/facets
relations
dependencies
history
metrics
vector boundary
UI layer/facet

Quy tắc: không enumerate tổ hợp, không hardcode nhánh theo loài/lớp. Tất cả phải có khả năng được group/pivot/join bằng metadata.

3. DB sống của mỗi thực thể

Lớp cuối cùng của entity là DB sống của chính nó.

Ngay cả field rất nhỏ như một tên vài ký tự, ở tầng sống cuối cùng vẫn có thể có vài trang dữ liệu khi hệ thống làm giàu theo thời gian:

ai dùng nó?
nó dùng ai?
ai chứa nó?
nó thuộc ai?
ai sửa nó?
lịch sử thay đổi?
nhãn/facet?
metrics/health?
vector/chunk nào liên quan?
ảnh hưởng đến workflow/UI/release nào?

Vì vậy birth/migration không chỉ insert một row; nó phải để đúng slot cho DB sống được làm giàu sau này.

4. Pivot là cách đếm và giám sát, không phải Nuxt code

Điều 26 đã đổi từ “Registries & Đếm” sang “Luật Pivot”.

Contract:

Mọi thứ đếm bằng pivot_count / PG pivot.
Nuxt chỉ đọc và render.
Thêm dòng/ma trận = metadata, không sửa code.

Layer 5 UI là ma trận đa chiều, xuất hiện cuối mỗi layer. Một ma trận có:

1 chiều chính + tối đa 6 chiều phụ = max 7 chiều

Nếu cần hơn 7 chiều, tách thành nhiều ma trận.

5. Anti-hardcode rule

Không được hardcode:

số loài
số lớp
species list
composition list
table/column names trong executable prompt
count gate từ report cũ
UI grouping logic trong Nuxt
CASE ladder theo loài/lớp

Được phép dùng constant chỉ khi là design-scope constant do GPT/User khóa và vẫn được live-verify nếu liên quan runtime.

6. Immediate impact on Phase 5C2

Phase 5C2 migration DIEU-35 must not proceed as a mere TAC→IU row-copy.

Before dispatch, 5C2 prompt must prove:

1. It writes one coordinate only: species=information_unit_atom, lớp=atom.
2. It does not implement global 6-lớp logic.
3. It preserves metadata needed for Entity Living DB:
   - source provenance
   - publication context
   - render order
   - TAC hierarchy
   - unit_kind / section_type / publication_type
   - publication_authority_ref
   - owner/ref
   - content hash / source hash
4. It leaves hooks for later relations/edges/pivot/UI enrichment.
5. It does not hardcode branch logic by species/lớp/layer.

7. Required design before continuing migration

Because this is foundational architecture, do not continue 5C2 migration until Opus produces a concise but complete design:

P3D Multidimensional Entity DB Architecture Design

That design must reconcile:

terminology
6 lớp + 1 loài
UI Layer 1–5 / Pivot
Entity Living DB
relations/dependencies/history/labels/metrics
birth registry / species mapping
TAC/IU migration
vector boundary
events/UI future use

8. Status

phase5c2_migration=PAUSED
reason=multidimensional_entity_db_contract_required
next_action=OPUS_CREATE_MULTIDIMENSIONAL_ENTITY_DB_DESIGN_AND_REVIEW_5C2_IMPACT