05 — Registries-Pivot Topic/Axis Pivot Map (Workstream C)

Goal: the pivot rows Registries-Pivot needs so it has a topic/axis map, not just an IU count. All proposals slot into the live pivot_definitions engine (reads FROM any relation; parent_code graph; group_spec) — no engine change.

Reserved code block: PIV-310 (documents) and PIV-320..332 (topic axis)

PIV-31x is the information/data family (PIV-311 IU, PIV-313 issues live). PIV-310 = documents. PIV-320..332 = topic axis. PIV-32x roots tie to a new axis-root node AX-TOPIC (see auto-scale doc 06); until axis_registry exists they may attach under a holding root or stand as L1 roots flagged count_status.

Code	Name	Source object	Group spec	parent_code	Count definition	Final/Candidate	Safe to add now?	Law needed?	Show on L1?
PIV-310	Documents — Total	knowledge_documents	by category, then status	(root)	count(*) = 5,710	CANDIDATE	YES (additive, source governed)	def ratification only	YES
PIV-320	Topic Axis — Approved Roots	taxonomy (facet 8)	—	(root / AX-TOPIC)	count active FAC-08 nodes, no active parent = 0 today	CANDIDATE	YES	needs FAC-08 populated + owner	YES
PIV-321	Topic Nodes — Total	taxonomy (facet 8)	by status	PIV-320	count active FAC-08 = 0 today	CANDIDATE	YES	as above	drill
PIV-322	Topic Candidates	taxonomy (facet 8)	—	PIV-320	count status IN (candidate,provisional)	CANDIDATE	YES	—	badge
PIV-323	Topic Relations	universal_edges (FAC-08 scope) ∪ taxonomy.parent_id	by edge kind	PIV-320	count broader/narrower/related + parent edges	CANDIDATE	YES (read view)	edge-type registration	drill
PIV-324	Topics by Lifecycle Status	taxonomy (facet 8)	by status	PIV-320	group-by status	CANDIDATE	YES	—	drill
PIV-325	Documents by Topic	knowledge_documents ⋈ topic assignment	by topic node	PIV-310 / PIV-320	count docs per topic = 0 today	CANDIDATE	needs assignment substrate	axis_assignment or tag mapping	drill
PIV-326	Information Pieces by Topic	iu_metadata_tag (topic:%)	by tag_key	PIV-311 / PIV-320	25 assignments / 16 IUs (honest, low)	CANDIDATE	YES (read view)	reconcile tags→FAC-08	drill
PIV-327	Workflows by Topic	universal_edges → workflows	by topic node	PIV-004 / PIV-320	count workflow↔topic edges	CANDIDATE	needs edges	edge population	drill
PIV-328	DOT/Agent/Events by Topic	universal_edges → dot_tools/agents/event_type_registry	by object kind × topic	PIV-007/011 / PIV-320	count control objects per topic	CANDIDATE	needs edges	edge population	drill
PIV-329	Orphan Topics	taxonomy (facet 8)	—	PIV-320	active topic with 0 assignments AND 0 owner	CANDIDATE (report-only)	YES (read view)	—	warning row
PIV-330	Phantom Topic Relations	universal_edges (FAC-08)	—	PIV-323	edge to retired/missing node	CANDIDATE (report-only)	YES	—	warning row
PIV-331	Topics Needing Grouping	taxonomy (facet 8)	—	PIV-320	nodes with child_count > rp_grouping_policy threshold	CANDIDATE	YES	governed ceiling row	warning row
PIV-332	Topics with Governance Gap	taxonomy (facet 8) ⋈ governance_object_ownership	—	PIV-320	active topic not in ownership = governance gap	CANDIDATE	YES (read view)	owner rows must exist	warning row

Safety classification (honest)

• Safe to add now as additive read views / pivot rows (no faking, no mutation of meaning): PIV-310, PIV-320..324, PIV-326, PIV-329..332. These count live data (mostly 0 or small today) and report status honestly (PIVOT_MISSING/CANDIDATE/NEEDS_LAW_DEFINITION), never a fabricated number.
• Blocked on substrate population (need FAC-08 nodes and/or axis_assignment/edges): PIV-325, PIV-327, PIV-328, and the content of PIV-320..324. They are defined but report 0 until topics + edges are populated under governance.

Pattern alignment with live RP law

• Every pivot above carries a count_status (pivot_backed when its source rows exist; PIVOT_MISSING never 0) exactly like the live node contract.
• Candidate/report-only pivots go to v_rp_aggregate_candidate_register-style registers (PIV-329..332), not to canon, mirroring the live treatment of orphan/phantom/drift (PIV-301/302/303). This avoids unretirable birth + unratified law.
• Grouping uses live rp_grouping_policy; pins use live registry_pin.

What this delivers (answer to macro Q6)

A topic/axis pivot map (PIV-310 + PIV-320..332) layered on the existing engine, where the headline of the information map is the topic axis, documents and IU counts are supporting substrate measures, and orphan/phantom/grouping/governance-gap are first-class warning rows — all honestly reporting today's near-empty reality without faking.

Workstream C completion: Registries-Pivot now has a topic/axis pivot map specification, code-reserved and engine-compatible, ready for owner-gated insertion.