Building a Cognitive Control Plane in Rust — GCF 2.0 Stages 27, 28, and 29

By Billy P. — 18 min read

If you’ve been following GCF 2.0, you know the first phase built a framework that could model the world, predict what would happen before executing, and recursively expand hard tasks into bounded child subcubes. That gave us a system that could think carefully. But “could” isn’t the same as “should,” and the work didn’t end there.

Stages 27, 28, and 29 turn that capability into a real control plane. The framework now decides when more cognition is worth the cost, runs non-essential work on a dedicated background thread that yields to foreground activity, and ties every subsystem together with a single ownership and lock map. This post walks through what we built, why, and what we learned — and it ends with three findings we deferred to stage 29.1.

Here’s the punchline up front, before we dive in:

TL;DR. Stage 27 adds a marginal-utility advisor that gates mode upgrades and recursive expansions in 7–8 nanoseconds. Stage 28 adds a bounded, preemptible background worker with a strict lifecycle state machine and an RAII timeout guard. Stage 29 integrates everything (stages 18–28) into one E2E pipeline, with 65/65 tests passing, 8,850 req/s, 0 leaks, and a 4.51% worst-case regression against the stage 18 baseline.

The Shape of the Phase

GCF 2.0 is built as a sequence of stages, each owning a single concern. The earlier stages established telemetry, invariance detection, persistent state, adaptive planning, governance, world modeling, predictive cognition, and recursive expansion. Stages 27, 28, and 29 build the next layer on top: deciding when cognition is worth its cost, running cognition in the background when foreground attention should not be preempted, and integrating the whole stack into a single coherent system.

A few design rules hold across all three:

• Advisory. The cognitive economy advisor never overrides the planner; the planner never overrides governance; governance never overrides any of them — it just gates the call.
• Bounded. Every collection has a hard cap. Every counter uses checked arithmetic. Every recursion has a depth limit.
• Toggleable. Each new subsystem is enabled by an environment flag and completely bypassed when disabled.
• Tested. Six cargo gates (fmt, check, clippy, test, test –release, build –release) plus an explicit 100k stability run and a stage 18 regression check.

The three stages form a coherent request pipeline:

• Task / Request → inbound task context and fingerprint
• Stage 25 → Prediction → advisory confidence, outcome, and resource estimate
• Stage 22 → Plan → authorizes (or denies) recursive expansion
• Stage 27 → Cognitive Economy → advises on mode upgrade and recursive expansion decisions
• Stage 23 → Governance → proceed-only gate for world updates and child spawns
• Stage 26 → Recursive Expansion → bounded child-cube execution under isolated world view
• Stage 28 → Background Cognition (optional) → off-thread non-essential work with preemption and RAII timeout
• Deterministic Result Merge → outputs fused with precedence-ordered status resolution
• Stage 29.0 → Integration Verification → E2E tests, ownership map, stress workload

Let’s look at each stage.

Stage 27: Cognitive Economy

Stage 27 introduces an allocation-light, deterministic cognitive economy optimization layer. GCF now evaluates whether more cognition is worth the resources it will consume before taking optional execution steps:

• Mode Upgrades — gating Rapid → Standard and Standard → Deep transitions.
• Recursive Expansion — gating optional child cognitive subcube spawns under stage 26.

Under GCF_COGNITIVE_ECONOMY_ENABLED = false, stage 27 has a zero-allocation, extremely low-latency path that preserves all previous behaviors unmodified with negligible measured overhead or heap overhead.

The Marginal Utility Model

The stage 27 utility model compares marginal benefit against marginal cost. Two distinct utility functions cover the two integration points.

Mode Upgrade Utility. For an upgrade from the current execution mode to a target mode:

MU_upgrade = Δ B – (w_base · Δ C + w_scarcity · S · Δ C)

Where:

• $\Delta B$ — expected-value benefit of the upgrade = $EV_{parent} \times (M(\text{target}) – M(\text{current})) \times \text{ImportanceFactor}$
• $EV$ (expected value) — $\text{confidence} \times \text{OutcomeMultiplier}(O)$, where $O \in \{\text{LikelySuccess}, \text{LikelyPartial}, \text{LikelyFailure}\}$
• $\text{OutcomeMultiplier}$ — LikelySuccess → 1.0, LikelyPartial → 0.6, LikelyFailure → 0.2
• $\Delta C$ — $\text{clamp}((candidate\_ms – current\_ms) / max\_increment\_cost\_ms, 0.0, 1.0)$
• $S$ (scarcity) — $1.0 – \text{Capacity}$, where Capacity is calculated using the stage 22 calculate_capacity function
• $w_{base}, w_{scarcity}$ — configurable weights in EconomyConfig; the second term amplifies the cost penalty when the system is resource-starved

Recursive Utility. For a recursive child spawn:

MU_recursive = Δ B_recursive – (w_base · Δ C_recursive + w_scarcity · S · Δ C_recursive)

Where:

• $\Delta B_{recursive}$ — $EV_{child} \times \text{Residual} \times recursive\_depth\_decay^{depth} \times \text{ImportanceFactor}(child)$
• $\text{Residual}$ — $\text{clamp}(1.0 – EV_{parent}, 0.0, 1.0)$ — how much value the parent leaves on the table
• $\text{recursive\_depth\_decay}$ — geometric decay factor applied per depth level (later descendants contribute less)
• $\Delta C_{recursive}$ — $w_{cost} \cdot \Delta C_{estimate} + w_{scarcity} \cdot \Delta C_{scarcity\_budget}$

Each evaluation returns an EconomyResult with one of two actionable decisions: Continue (proceed) or Stop (veto the optional step).

Bounded Prediction Cache & Audit Log

Stage 27 introduces two allocation-bounded state structures on the HierarchicalManager:

Both structures guarantee a flat memory footprint and zero leaks under sustained load.

Walkthrough & Verification

The full six-cargo release gate passed cleanly. Both economy decisions run in single-digit nanoseconds.

The 100k economy control plane workload finished in 0.0008 seconds with 0 KB net memory growth. The disabled-path overhead measured at 1.4050 ns — ≤ 0.00005% of total GCF task execution time. Stage 18 → stage 27 cumulative regression: +4.51% (≤ 5% gate — PASS).

Stage 28: Background Cognition

Stage 28 adds an off-thread background execution path to GCF. The framework can now defer non-essential work to a dedicated worker thread, yield to foreground activity automatically, and shut down cleanly under load.

The architectural goals are:

• Thread safety — all types crossing the worker boundary are verified Send/Sync.
• Bounded resources — queue, result buffer, prediction cache, and string sizes are all hard-capped.
• Cooperative preemption — the worker yields at legal checkpoints when foreground work is active.
• Pure RAII unwinding — guards (TimeoutGuard, ExpansionReservationGuard, ForegroundActivityGuard) restore state on drop or panic.
• Failure-closed behavior — if the worker thread itself dies, foreground execution is unaffected.
• Reversibility — GCF_BACKGROUND_COGNITION_ENABLED = false completely bypasses the subsystem with no observable overhead.

Task Lifecycle State Model

Every background task moves through a strict state machine. Transitions are defined by a single transition table; illegal transitions are unrepresentable.

Background Queue, Yielded Slot, and Preemption

The background queue and the yielded slot are the two primary data structures. The queue holds pending tasks; the yielded slot holds at most one in-progress task that was preempted.

The PreemptionController coordinates worker preemption using three atomics and a Condvar:

rust

pub struct PreemptionController {
    pub active_foreground_requests: Arc<AtomicUsize>,
    pub condvar:                    Arc<Condvar>,
    pub fail_closed:                Arc<AtomicBool>,
}

• CAS saturation — saturated guard registration increments mark fail_closed = true and notify the condvar. Background workers stop/yield at the next legal cooperative checkpoint.
• Foreground fail-safe — saturated guards allow foreground requests to proceed without delay or abortion.
• Yield recovery — the background worker remains disabled until fail_closed is reset to false via reset_background_system(), which notifies the condvar.

ModelBridge Timeout and Scoped RAII Guard

GCF uses reqwest::blocking for HTTP model calls. To enforce strict, configurable timeouts on the background thread without modifying the foreground path, stage 28 introduces a thread-local timeout variable and an RAII guard:

rust

// In src/model/bridge.rs
thread_local! {
    pub static BACKGROUND_TIMEOUT: Cell<Option<Duration>> = Cell::new(None);
}

pub struct TimeoutGuard { old_value: Option<Duration> }

impl TimeoutGuard {
    pub fn new(timeout: Duration) -> Self {
        let old_value = BACKGROUND_TIMEOUT.with(|t| {
            let old = t.get();
            t.set(Some(timeout));
            old
        });
        Self { old_value }
    }
}

impl Drop for TimeoutGuard {
    fn drop(&mut self) {
        BACKGROUND_TIMEOUT.with(|t| t.set(self.old_value));
    }
}

Inside ModelBridge::generate(), the thread-local is consulted: if Some(to) is set, a client is built with builder.timeout(to); if None, the foreground path uses the unmodified Client::new() with default OS-level timeouts.

Preemption and time bounds:

Background-Specific Types

The exact Rust types used by stage 28:

rust

#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct BackgroundTaskId(pub u64);

#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
pub enum TaskPriority { Low = 0, Medium = 1, High = 2 }

#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
pub enum TaskLifecycleState {
    Queued, Eligible, Running, Yielded, Completed,
    Cancelled, Failed, Expired, NeedsRevalidation,
}

/// Held inside the preallocated pending queue. Carries no live WorldSnapshot
/// or live RecursionBudget — those are obtained at execution time.
pub struct BackgroundQueuedTask {
    pub task_id:                     BackgroundTaskId,
    pub query_fingerprint:           String,   // max 64 bytes
    pub input_query:                 String,   // max 256 bytes
    pub enqueue_sequence:            u64,
    pub priority:                    TaskPriority,
    pub path_plan:                   ExecutionPlan,
    pub cancel_token:                CancellationToken,
    pub result_tx:                   SyncSender<BackgroundResult>,
    pub expected_world_revision:     u64,
    pub max_acceptable_revision_skew: u64,
    pub created_at:                  Instant,
    pub attempts:                    usize,
    pub checkpoint:                  BackgroundCheckpoint,
    pub lineage_depth:               u8,   // bounded at 3
}

/// Owned by the worker thread or the supervisor yielded_slot.
pub struct BackgroundRunningTask {
    pub payload:         BackgroundQueuedTask,
    pub world_snapshot:  WorldSnapshot,
    pub state:           TaskLifecycleState,
}

Byte limits (256 bytes for input queries, 64 bytes for fingerprints, 10,248 bytes for responses, 512 bytes for errors) are strictly enforced at construction/API boundaries.

Runaway and Recursion Safety

• Queued tasks carry no live RecursionBudget snapshot. The standard request-scoped recursion slots are accessed via the normal approve_expansion path at the point of background recursive entry.
• Background tasks cannot enqueue new background tasks. Proposals are returned via callbacks to the normal planning/governance pipeline.
• Lineage limit — bounded at lineage_depth = parent_lineage_depth + 1. If lineage_depth > 3, the task is immediately rejected with BackgroundLineageLimitExceeded.

Walkthrough & Verification

The six-cargo release gate passed cleanly: 54/54 tests, including three new safety tests (test_direct_self_enqueue_rejection, test_background_lineage_limit, test_stage23_governance_denial).

Stage 18-comparable performance workload (60 inputs, 25 repetitions, thermally balanced):

Worst cumulative stage 18 → stage 28: 4.51% (≤ 5% gate) — PASS.

The 100k stability run completed in 89.00 s with 16.00 KB memory growth (bounded, near-flat), 1,123.59 req/s throughput, 0 panics, 0 deadlocks, 0 thread leaks. Shutdown under a blocking HTTP request (500 ms configured timeout, 2000 ms simulated server delay) joined the worker in 306.79 ms with no leaked worker.

Stage 29.0: GCF 2.0 Integration

Stage 29.0 integrates and verifies the full GCF 2.0 cognitive stack (stages 18–28) as one coherent, end-to-end execution system, preserving subsystem ownership, state consistency, and preemption boundaries.

This stage does not add new cognitive capabilities. All subsystems remain frozen, and stage 29.0 connects them via adapters, unified context wrappers, and integration tests.

The E2E Call Graph

The integrated request flow across all subsystems:

Figure 1 — E2E call graph of the integrated GCF 2.0 cognitive stack (stages 18–28). Each node is a function call; each arrow is a control-flow or dependency edge. The numbering (1–18) follows the canonical sequence of the request pipeline.

The call chain for recursive child execution is:

RecursiveProposal (RecursiveExpansionNode)
    │
    ▼
ChildExecutor::execute (expansion.rs)
    │
    ▼
CognitiveEconomyAdvisor::evaluate_recursive_expansion
    │   (if Continue)
    ▼
ChildExecutor::spawn_child
    │
    ▼
approve_expansion
    ├── 1. plan.allow_recursive_expansion (stage 22)
    ├── 2. Governance triggers (depth / risk)
    ├── 3. evaluate_governance (stage 23)
    └── 4. RecursionBudget reservation (stage 26)
    │
    ▼
ChildExecutor::start_execution
    │
    ▼
HierarchicalManager::new_child_scoped (isolated)
    │
    ▼
execute_child_scoped → MergeAccumulator::merge_child
    │
    ▼
ExpansionReservationGuard Drop (RAII budget release)

Ownership and Lock Map

Every subsystem’s mutable state is owned by a single module. Locks are short-held; network calls always happen outside structural locks.

Crucial rule: Network and model requests (ModelBridge::generate) are made strictly outside GCF structural locks. The background worker releases the queue and slot locks prior to executing task strategy increments.

WorldModel Commitment Boundary

The WorldModel commit boundary is the same in both recursive and background flows: the authoritative parent WorldModel is only mutated on the foreground thread under the governance gate.

• Recursive flow — spawning a child manager calls HierarchicalManager::new_child_scoped, which instantiates a separate isolated child WorldModel populated from a cloned parent WorldSnapshot. All asserts and invalidations during child execution update only the isolated instance. Child updates are never merged back to the parent WorldModel.
• Background flow — background workers run in a scoped worker context utilizing an isolated child WorldModel cloned at run time.
• Authoritative commits — the parent WorldModel is only mutated inside execute_task_stabilized on the foreground thread under (is_governance_approved && validation.passed).

Feature-Toggle Matrix

All seven behavioral permutations of the three feature flags are explicit and tested.

Unified Task Context and Bounded Error Model

Stage 29.0 defines a small, borrowed, stack-allocated context to avoid God-objects and WorldSnapshot clones. EarlyTaskIdentity is constructed at entry; UnifiedTaskContext is completed only after planning.

rust

pub struct EarlyTaskIdentity<'a> {
    pub task_id:       u64,
    pub input_query:   &'a str,
    pub fingerprint:   &'a TaskFingerprint,
    pub cancel_token:  &'a CancellationToken,
}

pub struct UnifiedTaskContext<'a> {
    pub identity:        EarlyTaskIdentity<'a>,
    pub plan:            &'a ExecutionPlan,
    pub world_snapshot:  &'a WorldSnapshot,
    pub lineage_depth:   u8,
}

The bounded integration error model prevents uncontrolled payload sizes:

rust

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum IntegrationErrorCategory {
    Planning, Prediction, Governance, WorldState, Recursion,
    Economy, Background, Cancellation, Timeout, Persistence,
    InternalInvariant,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct IntegrationError {
    pub category:       IntegrationErrorCategory,
    pub subsystem_code: &'static str,   // e.g. "PLAN-01"
    pub detail:         String,          // clamped to exactly 256 bytes
}

Stage 29.0 Walkthrough — Benchmark Results

The stage 29.0 walkthrough (v2) reports the final integration benchmarks and full E2E test matrix reconciliation.

Timing Benchmarks (60 inputs, 25 reps, thermal-balanced runner):

Integrated Mixed Stress Workload (100k Operations):

Full Cargo Release Gates: cargo fmt --check, cargo check, cargo clippy --all-targets --all-features, cargo test (65 passed), cargo test --release (65 passed), cargo build --release — all PASS.

E2E Integration Matrix — Final Reconciliation

All 9 categories of integration tests pass cleanly. The walkthrough explicitly distinguishes passing capabilities from three known defects deferred to stage 29.1:

Stage 29 Findings (Deferred to 29.1)

The walkthrough enumerates three findings, in order of severity:

• Finding 1 [MEDIUM] — Stage 28 background worker loop in hierarchy.rs does not check task.payload.cancel_token.is_cancelled(); continues executing task strategies to completion even when the task is cancelled.
• Finding 2 [CRITICAL] — Background receiver channel _result_rx is dropped inside enqueue_background_task_with_plan at creation. The worker thread encounters a disconnected receiver and fails to save results to result_buffer. (Escalated from medium to critical based on empirical walkthrough results.)
• Finding 3 [LOW] — Ordinary foreground tasks in stages 18–27 do not perform cancellation checks and cannot be aborted.

All three findings are tracked for stage 29.1. The walkthrough’s E2E matrix above explicitly tags the affected capabilities as KNOWN-DEFECT so reviewers can see at a glance which paths are deferred.

Cross-Stage Verification Summary

Stages 27, 28, and 29.0 form a single verified control plane on top of stages 18–26. The table below summarizes the headline verification metrics from each walkthrough.

Common verification themes:

• Bounded memory — every stage reports a flat or near-flat memory footprint over 100,000 operations.
• Zero panics / deadlocks — no stress workload reports panics, deadlocks, or leaked references.
• Sub-microsecond core paths — economy decisions in 7–8 ns, validation in fractions of a microsecond.
• Regression discipline — all stages stay under the 5% ceiling against the stage 18 baseline.
• Six-gate cargo discipline — every stage passes cargo fmt, check, clippy, test, test --release, and build --release.

Related Documents in the GCF Library

This post is one part of a larger library of GCF 2.0 deliverables. The companion documents provide the broader context — flagship whitepapers that introduce the system, prototype plans that motivated the architecture, roadmap and project reports that frame the work, and the full set of stage implementation plans and walkthroughs that the consolidated documents draw from.

Flagship Whitepapers

• GCF: A Recursive Cognitive Framework for Small-Model Amplification — Introduces GCF as a model-agnostic cognitive execution system that amplifies small models (≈4 GB) through structured orchestration. Sets the founding premise: MODEL ≠ INTELLIGENCE, GCF = INTELLIGENCE.
• Meet ISAC: The AI That Thinks Before It Speaks — Public-facing narrative about ISAC, the desktop AI built on GCF. Explains how the cognitive cube works through the chess-piece analogy and contrasts it with naive LLM usage.

Prototype Plans

• The Cognitive Cube: A Hierarchical, Budgeted Reasoning Architecture Using Nested Chessboards — Foundational paper that introduces the 6-face × 8×8-board cube, the 384 cells, the chess-piece execution modes, and the budget-and-decay model.
• A Blueprint for a Governed Cognitive Framework — General-purpose architecture specification for safe, deterministic, auditable artificial reasoning. Separates cognition from personality, intent from action.
• Deterministic Scoring in Governed Cognitive Architectures — Foundational treatment of why and how deterministic scoring — not probabilistic LLM judgement — is the right basis for governed decisions.
• Deterministic Scoring Mapped to Mini-Board Chess Pieces — Concrete numeric ranges, thresholds, and decision gates for the MVP. Maps each chess piece to a deterministic score band.
• Governed Decision Flow in the Cognitive Cube — How attention is allocated, hypothetical outcomes evaluated, and human authority routed in the cube.
• ISAC Phase 1 Implementation Blueprint — Concrete implementation plan for phase 1 of ISAC — translates the cognitive-cube architecture, governance model, and safety constraints into a modular system design ready to build.

Roadmap & Project Reports

• GCF Roadmap: Stage 13.8 → Stage 15.5 — Defines the post–memory-learning roadmap: Adaptive Optimization → Prediction → Fusion → Emergence → Autonomy.
• GCF: Global Cognitive Framework — Project Documentation & Progress Report — Comprehensive 20+ page executive report covering technical architecture, implementation progress, performance achievements, and intellectual-property protection.
• Building a Bounded, Governance-Aware Cognitive Framework in Rust — Long-form engineering article covering GCF 2.0 stages 24, 25, and 26 (World Model Engine, Predictive Cognition, Recursive Cognitive Expansion). Pairs naturally with this post.
• Today’s Session Summary (April 19, 2026) — End-of-day record of benchmark analysis, IP protection setup, and the memory-learning system implementation.

Companion Implementation Plans (Stages 27–29)

Recommended Reading Order

For someone new to the GCF library:

1. Start with the flagship whitepapers for the public framing.
2. Move to the prototype plans for the design rationale.
3. Read the GCF Roadmap + Project Progress Report for the executive view.
4. Read the engineering article on stages 24–26 to ground yourself in GCF 2.0 specifically.
5. Read this post for the GCF 2.0 stages 27, 28, and 29.0 work.
6. Drill into the per-stage implementation plans and walkthroughs only when you need the full version history.

Conclusion & Next Steps

Stages 27, 28, and 29.0 close out the second coherent phase of GCF 2.0. A framework that already understood the world, predicted the cost, and recursively scaled now also decides when to spend cognition, runs it in the background, and ties every subsystem together through a unified context.

Recommended next steps:

• Apply the Stage 29.1 cancellation-check fix to the background worker (Finding 1) and re-run the stage 18 regression check.
• Fix the dropped receiver channel in enqueue_background_task_with_plan (Finding 2) and verify that worker results are correctly delivered to the BoundedResultBuffer.
• Wire the CognitiveEconomyAdvisor::evaluate_mode_upgrade into the executor’s retry path so its Stop decision actually short-circuits a transition.
• Promote the unified EarlyTaskIdentity / UnifiedTaskContext wrappers to a stable API and document them for downstream integrators.
• Build a synthetic cross-stage end-to-end test that exercises all three stages together and locks in the ≤ 5% regression ceiling.

If you’re building a reasoning system in Rust — or any system with budget, governance, recursion, and background work — I’d love to compare notes. The full implementation plans for all three stages are on the way in a longer-form report, but the patterns above should give you a head start.

— Billy P.

Reposted from the GCF 2.0 engineering notebook. Tested on branch=2.0, last verified August 2026. Cover diagram: integrated E2E call graph for stages 18–28.