GPT Analysis — Governance Operational Workflow Gaps for IU Axes / Topic / Containment

Date: 2026-06-01 Reviewer: GPT Council

Context

User asked to reason from real operation before adding more technical design. Current concern: governance has been designed around objects already visible in PG, but practical workflows such as IU topic classification and parent-child containment axes are not yet fully specified operationally.

Current evidence

Existing concept docs already define open-axis principle: an axis is a governed object, future axes must be registry rows, and no fixed axis array should control runtime. IU coverage docs state the live three-axis envelope is a denormalized envelope, not the complete axis model; live/implied IU axes already exceed three and include composition/species, relation/KG, label/taxonomy, vector/index, lifecycle/version, workflow.

Preliminary conclusion

There is still a real design gap before operational build: the system needs an end-to-end IU axis governance workflow, not only substrate tables. It must define how topic axes are proposed, provisionally used, validated, merged, retired, and promoted to governed axes; how parent-child containment differs from semantic topic classification; and how wrong/low-confidence classification is detected.

Recommended next direction

Before coding Phase 1 build or any IU/axis operational scanner, run a broad operational-workflow gap audit covering:

• IU creation and chunking;
• reconstruction to original document;
• containment / parent-child axis;
• topic/professional semantic axis;
• candidate topic discovery;
• axis registry lifecycle;
• approval thresholds;
• human vs agent proposal rights;
• quality checks and correction loops;
• governance ownership and issue routing;
• interaction with GCOS candidate/input-quality/snapshot/ruleset model.

This should be treated as a design-level operational validation pass, not a build task.