v2.0.0 · Locked · L1 · March 19, 2026

§12 Governance Activation Logic

§11 specifies what governance content exists and how it is structured — the registry. This section specifies what happens when an organization engages with that registry: which patterns activate, what gaps exist, how gaps are assessed with verification precision, how gaps are prioritized by conservation criticality, and how closure proceeds through named stages.

§12 operationalizes what §8 derives — graduation as variety engineering — and what §9 establishes — conservation law preservation as the ordering principle for gap prioritization. The activation pipeline processes organizational events against the organizational world model, making the governance registry (§11) operational for a specific organization by detecting gaps and guiding remediation.

§12.1 The Activation Pipeline

The governance activation pipeline transforms an organizational profile into an ordered closure roadmap through six sequential stages. Each stage has defined inputs, outputs, and architectural constraints.

Table 12.1.1: Activation Pipeline Stages

The pipeline is not a one-time operation. Stage 6 creates a feedback loop: conformance test results from the policy projection layer (§13.6) flow back as gap register updates, which trigger closure roadmap re-prioritization. Profile changes trigger re-evaluation starting at Stage 2. New governance source registrations trigger re-evaluation starting at Stage 3.

SDK Constraints:

• MUST: The pipeline exposes each stage as a distinct, queryable operation with typed inputs and outputs.
• MUST: Every pipeline execution produces an audit trail — who triggered it, when, what changed.
• MUST NOT: The pipeline execute autonomously on a schedule. Activation is event-triggered: profile change, source update, or conformance feedback.
• DESIGN SPACE: Batch vs. incremental re-evaluation when inputs change is an implementation choice. The architecture requires that the output is equivalent regardless of evaluation strategy.

§12.2 Rule-Based Activation Model

Activation is rule-based. Each governance source in the registry (§11) declares one or more trigger conditions. The activation engine evaluates which sources apply to a given organizational profile by matching profile attributes against trigger conditions.

Table 12.2.1: Activation Rule Structure

Activation Algorithm

The activation algorithm evaluates each governance source independently against the organizational profile:

FUNCTION evaluate_activation(profile, registered_sources):

    activated = []

    FOR EACH source IN registered_sources:
        FOR EACH rule IN source.activation_rules:
            IF evaluate_trigger(rule.conditions, profile):
                activated.add({
                    source: source,
                    activation_type: rule.activation_type,
                    mandatory: rule.mandatory
                })
                BREAK  // First matching rule wins per source

    // Apply tier-aware filtering (§12.5)
    activated = filter_by_active_tiers(activated, profile.active_tiers)

    RETURN activated


FUNCTION evaluate_trigger(conditions, profile):

    IF conditions.type == "ANY_OF":
        RETURN ANY(evaluate_single(c, profile) FOR c IN conditions.clauses)

    IF conditions.type == "ALL_OF":
        RETURN ALL(evaluate_single(c, profile) FOR c IN conditions.clauses)

    RETURN evaluate_single(conditions, profile)


FUNCTION evaluate_single(condition, profile):
    actual = profile[condition.attribute]
    RETURN apply_operator(actual, condition.operator, condition.value)

The algorithm produces an activation proposal — a set of governance sources with their activation types. The proposal is computational; the confirmation is a governance act.

SDK Constraints:

• MUST: Activation rules are declarative. The trigger conditions are data, not code — they are evaluated by a generic engine, not hard-coded per source.
• MUST NOT: The activation engine auto-activate sources without human confirmation. The engine proposes applicability; a human with traceable authority (B5) confirms. Mandatory sources are flagged as mandatory in the proposal — they are not silently activated.
• MUST NOT: Activation be continuous or polling-based. Activation evaluates when a profile is assessed or when a governance source is registered or updated.
• DESIGN SPACE: The operator vocabulary for trigger conditions (equals, not_equals, greater_than, less_than, contains, member_of) is implementation-defined. The architecture requires that conditions are expressible as composable Boolean expressions over profile attributes.

§12.3 Invariant Enforcement in the Activation Pipeline

The activation pipeline produces governance state — activated sources, gap assessments, closure decisions, change propagation events. This state MUST satisfy all ten behavioral invariants (§5). Each invariant maps to specific pipeline stages where enforcement is required.

Table 12.3.1: Invariant-to-Pipeline Enforcement Mapping

Enforcement timing. B1–B6 enforcement follows the two-pass validation architecture (§5.3). Pass 1 shapes (B1, B2, B3, B4, B5 immediate, B6 binding) enforce synchronously on every pipeline write — a closure work item without a Commitment link is rejected immediately. Pass 2 shapes (B5 transitive, B6 universal, B8, B9) enforce on a configurable schedule — signal routing availability and IQ resolution completeness are monitored, not gated per-operation.

§12.4 Graduated Gap Assessment

Gap assessment uses the seven verification types from §6.7, not binary pass/fail. A gap is not simply present or absent — it is characterized by which verification types the existing governance pattern satisfies and which it does not.

The seven verification types form a precision spectrum:

EXIST → COMPLETE → CURRENT → APPROVED → CONSISTENT → COMPLIANT → RATIFIED

A pattern that EXISTS but is not COMPLETE is a structurally different gap than one that is COMPLETE, CURRENT, and APPROVED but not yet CONSISTENT with related patterns. The graduated model transforms gap assessment from "is it implemented?" to "is it implemented to the required verification standard?"

Table 12.4.1: Verification-Type-Qualified Gap Assessment

Not all patterns require all seven verification types. The required verification depth depends on the pattern's materiality level.

Table 12.4.2: Materiality-Based Required Verification

RATIFIED is not included in any materiality level by default. It applies only to specific patterns where collective endorsement is explicitly required — board-level governance decisions, constitutional organizational policies. Profiles configure which patterns require RATIFIED.

A gap is closed when the governance artifact satisfies all verification types required by its materiality level. A pattern at baseline materiality is closed when it passes EXIST and COMPLETE. The same pattern at certification-grade materiality requires six verification types to close. The gap register tracks both the current verification state and the required verification state for each pattern, producing a precise closure distance.

§12.5 Tier-Aware Activation

The activation engine filters patterns by the organization's active primitive tiers, which are gated by graduation stage. An organization that has not demonstrated governance capability at lower tiers should not be governed by pattern expectations that reference higher-tier primitives.

Table 12.5.1: Graduation Stage Gates

Filtering mechanism. Each pattern signature carries a primitive alignment field (§11.7) listing the Tier 1 primitives it maps to. Tier 2–5 primitives are referenced through the pattern's activation context. The activation engine compares each pattern's tier requirements against the organization's active tier set. Patterns requiring primitives above the active tier set are excluded from the activation proposal.

SDK Constraints:

• MUST: The activation engine skip patterns whose primitive alignment or activation context references primitives above the organization's active tier set.
• MUST NOT: A Stage A organization activate Tier 3+ patterns. This is a structural constraint, not a recommendation — it prevents governance overreach.
• DESIGN SPACE: How tier requirements are encoded on pattern signatures (explicit tier field vs. inferred from primitive alignment) is an implementation choice. The architecture requires that tier filtering produces correct results regardless of encoding strategy.

§12.6 Conservation-Aware Gap Prioritization

Gap prioritization uses the four-level governance criticality classification defined in §11.7 Table 11.7.2. Each pattern signature carries a criticality level. When a gap exists in a pattern, the criticality level determines the gap's position in the closure roadmap.

Table 12.6.1: Gap Prioritization Scheme

Within-level ordering. When multiple gaps share the same criticality level, secondary ordering applies:

1. Governance layer (§11.3): Layer 1 (External Standards) before Layer 2 (AI-Native) before Layer 3 (Operational Authorities) — foundational governance before extensions.
2. Layer 1 tier (§11.4): Foundational before Risk & Security before Specialized — dependencies before dependents.
3. Materiality level (§12.4): Certification-grade before high-risk before baseline — higher verification requirements indicate higher organizational stakes.
4. Cross-framework dependency (§11.4 Table 11.4.2): Dependency sources before dependent sources — COSO IC gaps before SOC 2 gaps.

This ordering is deterministic. Given the same gap register and the same criticality scheme, any implementation produces the same closure sequence.

SDK Constraints:

• MUST: The closure roadmap order conservation-critical gaps before all other gaps regardless of other ordering factors.
• MUST: Within-level ordering follow the four-factor sequence: layer → tier → materiality → dependency.
• DESIGN SPACE: Whether the closure roadmap is computed eagerly (full roadmap on every gap register change) or lazily (next-N items on demand) is an implementation choice.

§12.7 Closure Roadmap Architecture

A gap is a governance coverage observation, not a failure state. "Governance coverage has not yet extended here" is a roadmap input — it positions the organization on a known path, not in an error condition. Closure is the progression from gap identification to governance coverage.

Four named closure stages structure this progression. Each stage has entry criteria that the preceding stage must satisfy before the gap can advance.

Table 12.7.1: Closure Progression Stages

Progression invariants. The four stages enforce a strict ordering: Awareness → Enablement → Management → Governance. A gap cannot advance to Management without first being enabled (authority acknowledged). A gap cannot be closed without passing the conformance test at the required verification depth. Backward transitions are permitted: a gap in Management can return to Enablement if the authority holder withdraws commitment, or return to Awareness if the underlying profile changes.

SDK Constraints:

• MUST: Gap closure produce a Decision primitive (§4) linking to the Account that provides the gap's state context (B4 enforced). The closure decision records which verification types passed, under whose authority, and against what organizational state.
• MUST NOT: Gap closure be automated. Closing a gap is a governance act: it asserts that the organization has extended governance coverage to a previously uncovered area. This assertion requires human authority. AI agents MAY compute gap projections, verify conformance test inputs, and draft closure evidence — but the closure decision is a human act.
• MUST NOT: AI agents perform activation acts: source activation, gap closure, or change approval. These are governance acts requiring human authority consistent with the AI-Cannot-Be-Principal constraint (§22).
• DESIGN SPACE: Whether closure stages are tracked as explicit state on the gap record or inferred from the presence of related primitives (a Work item with gap-specific criteria implies Management stage) is an implementation choice.

§12.8 Actor Constraints

Activation pipeline operations divide into two categories: computational acts (pattern matching, gap projection, roadmap ordering) and governance acts (source confirmation, gap closure, change approval). The distinction determines which actors may perform which operations.

Table 12.8.1: Actor Participation in Activation Pipeline

The table enforces a structural principle: AI agents amplify human governance capacity by performing computational acts at machine speed, but governance acts — the decisions that create, modify, or close governance state — require human authority. This is not a transitional limitation. The principle derives from the architectural position that governance legitimacy requires traceable human authority (B5), not from a temporary distrust of AI capability.

SDK Constraints:

• MUST: The pipeline enforce actor type and governance posture constraints at each operation boundary. A governance act attempted by an AI agent is rejected, not logged for later review.
• MUST: Every governance act in the pipeline produce an audit record identifying the human actor, their authority chain (B5), and the Account context (B4).
• MUST NOT: AI agents perform governance acts even when operating in Agentic posture. Agentic posture permits autonomous computational acts within delegation bounds — it does not extend to governance acts in the activation pipeline.

§12.9 Evidence Cold Start

A new organizational world model instance has structure (primitives and relationships from TMI translation, §20) but no evidence history. The first governance activations encounter an empty evidence base. This section specifies how the activation pipeline behaves under evidence-absent conditions.

The Environment Interface as Cold Start Mechanism

Evidence cold start is not "no evidence exists" — it is "evidence enters through the Environment Interface (§4.6.3) from external systems at genesis." The Environment Interface primitive is the protocol-level cold start mechanism.

At genesis, the first Authoritative Evidence enters the substrate through Environment Interface connectors:

Activation Pipeline Behavior at Genesis

Truth Type at Genesis

Evidence arriving through Environment Interface at genesis carries truth type according to its source: Authoritative for legally binding records (business registration, regulatory filings), Declared for organizational assertions (internal policies, org charts), Derived for AI-extracted content (document parsing output). The TMI translation output (§20) produces Declared evidence — it is a human-reviewed representation of organizational structure, not yet Authoritative until the organization ratifies it through the standard promotion workflow.

§12.10 Governance Maturity Framework

Governance maturity describes the arc of an organization's relationship with its organizational world model over time — from initial setup through full evidenced governance.

Maturity Stages

Maturity Metric: Evidence Coverage Ratio

The primary maturity metric is the evidence coverage ratio: the proportion of conservation-critical constraints (§12.6) that have Authoritative or Declared evidence supporting their satisfaction.

coverage_ratio = (constraints_with_evidence / total_conservation_critical_constraints)

This metric is computable from the gap register and closure roadmap. It provides a single quantitative indicator of governance maturity.

DESIGN SPACE

• Advancement criteria (what specific evidence thresholds trigger stage transitions) are substrate-level configuration.
• Whether maturity is self-assessed or externally certified.
• How maturity interacts with profile graduation (PAS → BAS → EAS, §21.4) — maturity may be a prerequisite for profile graduation, or profile graduation may drive maturity advancement.
• Whether maturity stage is visible externally (e.g., in federation contexts, §23.4) as a trust signal.

No Tier 2-5 metadata for this document.