P3D Principle — Multidimensional Matrix for Species + Composition

Date: 2026-05-12 Source: User architecture directive + GPT consolidation Scope: P3D Information Unit / Text-as-Code / Species-Composition system

1. Why this principle exists

The system must not treat species and composition as a simple one-dimensional tree. At scale, composition layers and species/facets can explode combinatorially.

The user explicitly warned:

6 lớp chỉ chọn 1 giá trị tại một thời điểm; loài cũng chọn 1, nhưng tổng space của 6 lớp có thể lên đến hàng triệu, và full data có thể lên vài trăm loài hoặc more fine-grained sub-species. Without multidimensional matrix thinking, classification and computation can become exponential.

2. Core distinction

Composition layer

Composition is a single selected value per entity at a given classification point:

atom → molecule → composite → material → product → building

It answers:

Entity này chứa gì bên trong / ở mức cấu tạo nào?

Species

Species is also selected, but species count may grow to hundreds or more, and may later split into finer sub-species.

Species answers:

Entity này thuộc loài nào / contract registry nào?

3. Why 6+1 matters

The “6+1” mental model is:

6 composition layers + 1 species/facet dimension

This does not mean only seven labels. It means the runtime must model classification as coordinates in a multidimensional matrix, not as a giant hardcoded tree or CASE expression.

4. Mandatory architecture consequence

Do not implement classification by:

• hardcoded species lists;
• hardcoded layer counts;
• large CASE/IF ladders;
• per-species custom code paths;
• per-layer custom SQL branches;
• one-off prompt constants not backed by live registry;
• duplicating the birth system for TAC/IU/UI/vector/events.

Instead use:

metadata rows + registry mappings + semantic dimensions + live lookup

and eventually:

species / composition / relation / role / lifecycle / governance / vector boundary / UI facet

as separable dimensions.

5. Immediate implication for current Pack 1

Phase 5C1 correctly restored information_unit into:

species = information_unit_atom
composition_level = atom

But this is only one coordinate in the matrix. It must not be treated as the final global classifier.

Phase 5C2 migration should preserve enough metadata for later dimensional enrichment:

• unit_kind;
• section_type;
• publication_type;
• publication_authority_ref;
• TAC hierarchy metadata;
• render_order;
• source provenance;
• species/composition from birth_registry.

6. Long-term implication

Full runtime must allow recomposition of large structures from simple coordinates:

atom rows → molecules via containment/edges → composites/materials/products/buildings via bundles/releases/UI layers

The solution is not to enumerate all possible combinations. It is to decompose the system into independent dimensions and join them through registry/edge/birth metadata.

7. Governance rule

Any future prompt/design that touches species, composition, IU migration, UI filtering, vector boundary, or build/release bundles must include a short dimensionality check:

Does this add a hardcoded branch per species/layer?
Does this scale by metadata lookup instead of code branching?
Does this preserve future ability to split species/subspecies without code rewrite?
Does this avoid exponential combination logic?

If not, it is not dispatch-ready.