---

title: 05 — Pin / Ghim Policy (PG-backed, governed, propose-only) date: 2026-05-31

05 — Pin / Ghim Policy

Each list/layer should support pinned (ghim) rows so humans/AI can monitor key rows quickly. Pins must be PG-backed, governed, scoped, counted/auditable — never frontend local-only.

Reuse search result (verified live)

Searched public for %pin%, %favorit%, %watch% and the KB for pin/favorite/watchlist/monitoring artifacts. No pin/favorite/watchlist table exists. Closest live concepts are issue monitoring (system_issues) and audit queue (entity_audit_queue, surfaced by PIV-018) — neither is a user/role pin. → Pin/ghim is genuinely NEW.

Proposed minimal registry (PROPOSE-ONLY — do NOT implement unless approved)

registry_pin (name TBD by governance):

column	type	note
id	int PK
object_ref	text	the pinned object (entity_code / pivot filter-path / substrate key)
object_kind	text	species/composition kind so the pin survives drill-layer changes
surface_ref	text	which surface/list/layer (e.g. registries-pivot:PIV-007)
pinned_by	text	actor (user/agent id)
scope	text	global | user | role | team
scope_ref	text	role/team id when scope ≠ global/user
reason	text	why pinned (monitoring rationale)
priority	int	display/triage order
created_at	timestamptz
active	bool	soft state (Đ-style soft-retire, never hard delete)

Governance (must hold before implementation)

• Birth: created via the birth registry path (Đ19/Đ0-G) → gets an ID + birth record like every entity; counted by a new pivot PIV-32x registry_pin (PIVOT_MISSING until born).
• Registered: added to meta_catalog (so it is itself visible, monitored, and subject to the orphan/phantom invariant — a pin table that isn't registered would itself be an orphan).
• Governed: owner = a governance Mother (likely GOV-COUNCIL / a monitoring sub-registry); scope changes auditable; soft-retire only.
• Auditable: every pin/unpin is an event (design: event_outbox pin.created / pin.removed), not silent UI state.
• Pivot-countable: pinned_count per surface is a pivot dimension, surfaced on the reflection screen.

Node contract field

A node carries pin_state (pinned | unpinned | pinned-by-role | pinned-by-team), resolved server-side from registry_pin filtered by the viewer's scope. Nuxt renders the flag; it never stores pins locally.

No-hardcode test (doc 08)

• T-PIN-1: pin_state derives from a PG registry_pin query; any localStorage/in-memory pin array in web/ ⇒ system_issues('hardcode_violation').
• T-PIN-2: registry_pin itself appears in meta_catalog and has a pivot (else it is an orphan by Đ23/Đ26).

Verdict

NEW, propose-only. Minimal, governed, scoped, born+registered+counted. Not implemented this session — design contract only, pending approval (Đ32-class additive change).