KB-50B1

09 — Prompt Path Decision & Next Macro (Workstream G)

4 min read Revision 1
registries-pivottopic-axisprompt-pathnext-macro2026-06-03

09 — Prompt Path Decision & Next Macro (Workstream G)

Goal: decide what to do with the previous macro plan, and name the next macro.

Decisions

Question Decision
Discard the previous INFORMATION_PIECE_RESUME... prompt? YES — replaced. It optimized for consuming the surface / counting IUs (PIV-311=219), which is necessary but treats counting as the goal. The owner's clarification (map through governed axes/topics) supersedes it.
Replace it with this topic-axis macro? YES. This pack is the new semantic anchor. The UI-consume work (RP_UI_CONSUME_SURFACE_AND_CANDIDATES) is not discarded but re-sequenced after the topic-axis contract — the UI must consume the axis surface, not just the tree surface.
Should the UI/API patch wait until the topic-axis contract is clear? YES. Patching the UI now would bake in a tree-only assumption and a "headline = IU count" framing that this pack reverses. Lock the contract (this pack) → ratify axis law → then patch UI to consume the axis surface.
What is the next macro? See below.

Why "do not patch UI blindly" is the right call (honoring §10)

The live UI/API was verified honest on the registry tree (152 ok / 5 unverified / 3 failed, no Nuxt math). But topics are a DAG, and the headline measure shifts from IU-count to the topic axis. A UI patch made before ratifying the axis contract would: (a) assume a tree, dropping multi-parent topics; (b) keep IU-count as the headline. Both are reversed here. So the semantic target is locked first; UI follows.

Sequenced next macros

NEXT (immediate, owner/operator-gated): TOPIC_AXIS_RATIFY_AND_PILOT_POPULATE

  1. Owner ratifies axis_registry + axis_assignment law (the 2 new objects) and the AX-TOPIC registration.
  2. GOV-COUNCIL approves the initial FAC-08 root topics (via approval_requests, Điều 32). AI/DOT may propose candidates only.
  3. Reconcile the 7 live iu_metadata_tag topic:* tags into FAC-08 candidate nodes (never auto-active).
  4. Apply the doc-07 apply-packet (companion surface + resolver + PIV-310/320..332) — operator-gated, additive, reversible.
  5. Assign topic ownership rows in governance_object_ownership.

THEN:

  • RP_UI_CONSUME_AXIS_SURFACE — UI consumes v_registries_pivot_axis_surface + axis API (the re-sequenced successor to RP_UI_CONSUME_SURFACE_AND_CANDIDATES).
  • TOPIC_AXIS_EDGE_POPULATION_AND_AUTOMATION — populate topic↔workflow/DOT/event edges (universal_edges) → activate PIV-327/328 and the 4-Mothers control surface.
  • RP_AGGREGATE_LAW_OWNER_RATIFICATION — the still-open aggregate law (orphan/phantom/drift/KG/unmanaged/grand-total), unchanged by this pack.

What this pack deliberately did NOT do

  • No live mutation (Live mutation = NO): no FAC-08 nodes, no axis tables, no pivot rows inserted, no UI patch. The apply-packet is held.
  • No AI-proposed topic promoted to an approved root.
  • No new collections beyond the 2 proven-necessary objects.
  • No change to birth/governance/pre-birth infrastructure; no RP cleanup; no dot-pivot-update.

Workstream G completion: old prompt explicitly replaced; UI patch deferred behind the contract; next macro named and sequenced.

Back to Knowledge Hub knowledge/dev/reports/architecture/information-piece-topic-axis-registries-pivot-design-2026-06-03/09-prompt-path-decision-and-next-macro.md