06 — Species / Composition Model Recovery (VERIFIED v2)

v2 ERRATA: v1 described a live "7 kingdom / 12 phylum / 21 species" tree and a composition_levels reference table. Neither exists in runtime. Corrected below from live queries.

Two orthogonal axes — DESIGN vs LIVE

Axis A — 6 COMPOSITION LAYERS (Đ0-B)

• Design: atom(0), molecule(1), compound(2), material(3), product(4), building(5).
• Live reality: there is NO composition_levels table. The 6 layers exist only as string values in composition_level columns (meta_catalog, entity_species, pivot_definitions, birth_registry). Distinct values seen carry dirt: entity_species shows atom, molecule, compound, meta, '1' (the meta and 1 are non-canonical). meta_catalog shows 7 distinct composition_level values (6 layers + 'meta').
• Implication: the anti-hardcode "read layers from a reference table" pattern is not yet realizable — there is no single live enumeration of the 6 layers. A composition_levels reference table is a genuine GAP to build (it does not exist to reuse). Until then UI either hardcodes the 6 (violation) or derives DISTINCT from data (dirty).

Axis B — SPECIES (entity_species, 42 rows, VERIFIED)

• Live: 42 rows, all depth=1 (flat — no live tree). Columns: code (SPE-xxx), species_code, display_name, composition_level, management_mode, prefix, parent_id, depth, kg_metadata. There is no species_kind column and no kingdom/phylum/species hierarchy populated (parent_id present in schema but tree not built).
• Sample species_code values: agent, ai_support, approval_request, business_support, catalog, checkpoint_set/support/type, cms_block, collection, dependency, directus_field, dot_tool, entity_label, entity_rule, governance_agency/infra/relation, help_center, information_unit_atom, junction_table, jurisdiction, label_facet/rule, law, law_enforcement, module, os_crm, page, pivot_result, … (42 total).
• Each species carries a composition_level tag (e.g. dot_tool→atom, collection→molecule, module→compound, law→compound, approval_request→compound).
• Design vs live gap: Species Taxonomy v1.2 (S157) specifies a 3-tier tree (parent_id+depth) and "Registries UI = 7 chiều (6 lớp + 1 species)." The runtime has the catalog (42) but the tree is not populated — a design-ahead-of-build gap.

Mapping & ledger (verified)

• species_collection_map = 164 rows (collection→species, is_primary, discriminator_field/value/operator).
• birth_registry (≈959k) records species_code + composition_level + collection_name per individual; trigger family fn_birth_registry_auto/fn_birth_gate/fn_pre_birth_check.
• meta_catalog CAT-020 = entity_species (42), CAT-021 = species_collection_map (164).

On the user's "6 loài + 1 species" phrasing

Resolved (holds from v1, law-sourced): "6 loài + 1 species" = "6 composition layers + 1 species dimension." Sources: species-taxonomy-complete.md v1.2 ("Registries UI = 7 chiều = 6 lớp + 1 meta-layer species"); gpt-understanding-...-2026-05-12.md §4 (explicitly says the "6 loài + 1" wording means 6 composition layers + species dimension; no literal "6 species + 1" in runtime). Do NOT model as 7 species. The 7-kingdom reading from v1 was an unverified invention and is retracted.

Terminology guardrail (P3D)

TẦNG (tier) ≠ LỚP (composition_level, the 6) ≠ CHIỀU (pivot dimension; species is one chiều). Keep distinct.

Recovery verdict

PARTIAL recovery. Species catalog (42) + per-individual birth ledger are LIVE and reusable. The 6-layer reference table and the species tree are DESIGNED but NOT built — recorded as gaps, not invented as existing.