GPT Direction — Registries-Pivot Counting / Orphan-Phantom / Labels / Pin Addendum

Date: 2026-05-30 Reviewer: GPT Council

User requirements added after master design report

The Registries-Pivot surface must not be a human-facing report only. It must be the automatic PG reflection screen for the whole system, driven by pivot counting.

New requirements:

1. Count everything automatically and scale automatically.
2. Preserve the old Registries homepage metrics: layer, composition/species/group, count, plus/minus, orphan, phantom, verification.
3. Orphan/phantom must be defined by law and scanned accurately; detections should feed cleanup workflows/notifications later.
4. Accounting invariant: every object must either be counted in registries-pivot or classified as orphan/phantom. If equation fails, system is wrong and should raise notification.
5. Dynamic drill-down: if count > 1, backend must provide a child layer, grouping children into manageable lists until reaching singular object and final DB/relationship substrate.
6. Label/grouping: long lists must be automatically grouped with labels; labels must live in PG and themselves appear in registries.
7. Suggested max group size: around 50 items before auto-label/grouping is required.
8. Pinning: each layer/list needs a pin column so important rows can be pinned to the top for humans/AI; pin state must be data-driven and governed.
9. The surface must detect new objects/groups automatically from the birth/registry substrate.
10. No hardcode and no disguised hardcode.

Design implications

The next macro must extend the previous design with:

• counting invariant;
• orphan/phantom scanner contract;
• notification integration contract;
• dynamic child-layer algorithm;
• label/grouping policy and PG-managed label registry;
• pinning policy and PG-backed pin registry;
• OS Agency columns for each node/list;
• no-hardcode enforcement tests.

Guardrails

• Do not implement production UI yet.
• No PG mutation unless explicitly approved later.
• No Nuxt business logic.
• Counts must be pivot-driven.
• Labels/pins must not be frontend arrays.
• If label/pin registries do not exist, mark as DESIGN_GAP / PIVOT_MISSING / REGISTRY_MISSING and propose minimal PG-first design.