GPT Direction — Registries-Pivot Layer Definition and Grouping Clarification (2026-05-31)
GPT Direction — Registries-Pivot Layer Definition and Grouping Clarification
Date: 2026-05-31 Reviewer: GPT Council
User observation
The production route /knowledge/registries-pivot is now visually close to the old /knowledge/registries table format, but the underlying layer philosophy is not yet complete.
The old Registries concept had a wider Wikipedia-like / system-reflection philosophy:
- Layer 1 pins major rollups/categories: atom, molecule, compound, material, product, building, species classification, orphan, phantom, unmanaged, system issues.
- Layer 2 after clicking a rollup shows the children/components of that rollup.
- Layer 3 after clicking a registry such as DOT Tools shows the concrete objects in that group.
- The current DOT layer is still poorly grouped and needs clearer principles.
Clarification needed
The team must define “layer” explicitly and reconcile it with existing laws/design:
- Information Atom Law;
- Composition Layer Law / 6 composition layers;
- Species Taxonomy;
- Registry Law;
- Pivot Law;
- Display/Nuxt boundary.
Recommended definition
A Registries-Pivot layer is not a fixed UI level. It is a data-driven projection level in a drill-down path from rollup summary to concrete substrate.
A layer exists whenever the current node has multiple child objects that need explanation or grouping. The final layer is always the object's own substrate: DB table/collection, primary key/code, relations, IU/profile/KG/DOT/audit/governance where available.
Two concepts must be separated:
- Composition level: atom, molecule, compound, material, product, building. This is a semantic classification axis.
- Display/drill layer: UI/data layer generated dynamically to keep lists understandable and inspectable.
Do not force fixed 5 layers if the data requires more or fewer layers. Do not treat composition level as identical to display layer.
Grouping principle
Top-down grouping is preferred for Registries-Pivot: root rollup → composition/species → collection/registry → semantic group/label → object list → object substrate.
If a list is too long or unclassified, the backend must trigger classification/grouping. The maximum ungrouped threshold is a ceiling, not a target. Pagination does not replace semantic grouping.
For DOT Tools specifically, the layer below DOT Tools should not be a flat 309/5000/10000-row list. It should group by existing PG-backed dimensions, for example operation/category/domain/paired status/test status/coverage/governance owner where available. If no adequate grouping exists, mark CLASSIFICATION_REQUIRED and propose PG-backed label/taxonomy dimensions.
Required next action
Before further UI polishing, run a law-grounded layer taxonomy and grouping clarification macro. Output should update canonical design docs and only then guide UI/route changes.
No hardcode. No frontend grouping arrays. No Nuxt count logic. Every layer/group must be PG/pivot-backed or explicitly marked PIVOT_MISSING / CLASSIFICATION_REQUIRED / DATA_MISSING.