GPT Direction — Add Incremental Governance Candidate Scan Design

Date: 2026-06-01 Reviewer: GPT Council

Decision

The current One-Roof Governance technical design is missing an explicit incremental candidate-scanning layer between Birth/Registry and Governance Coverage. Birth should remain stable and should not be expanded into a giant governance gate. Instead, after objects are born/registered, a second independent layer should detect governance relevance using group/snapshot/ruleset-based invalidation.

Principle

Do not store "object already checked" as a permanent truth. Store scan results by object/group + source snapshot + ruleset version + time. When the group, source registry, policy, axis, owner, approval, or ruleset changes, invalidate/rescan the affected group.

Required next design topic

Future technical design must include:

• governance candidate layer;
• dirty group / dirty source invalidation;
• event-driven + incremental scan + periodic full audit;
• source snapshot and ruleset version tracking;
• group_key design;
• relation to count>1 candidacy trigger;
• relation to birth-orphan vs governance-orphan detection;
• queue/state tables or views if needed;
• anti-spam/coalesce rules;
• resource-budget controls;
• production gate behavior.

Architectural placement

Birth Layer: ID and existence. Registry Layer: known list/source grouping. Candidate Layer: detect possible governance relevance. Coverage Layer: check owner/approval/audit/rollback/etc. Execution/Production Gate: block if coverage is required but missing.

Next macro implication

Do not implement yet. Add this as a new technical-design branch in the next macro, or create a dedicated technical design doc inside the active implementation-index package.