Ideas: How should compute resources be allocated across 29 modules in a real-time cognitive cycle?

[web3guru888]

The problem

ASI:BUILD has 29 modules. The most expensive ones — IIT Φ (consciousness), VQE (quantum), STDP simulation (neuromorphic), state-vector simulation (quantum), FHE operations (homomorphic) — can all run simultaneously in a full CognitiveCycle. They cannot all have unlimited GPU access.

The compute module has the machinery to handle this: job scheduler with FIFO/Priority/Fair-Share/Backfill algorithms, GPU manager, preemption, Kubernetes/SLURM integrations. But no cognitive module currently requests resources through it.

---

Current situation

Each module allocates resources at the Python level (grabbing torch devices, etc.) without coordination. In a single-module test this is fine. In a full CognitiveCycle with 29 modules running simultaneously, it will cause resource contention, OOM kills, and nondeterministic failures.

---

Three approaches to resource scheduling in cognitive architectures

Option A: Static allocation at cycle startup

Assign fixed resource budgets to each module at CognitiveCycle init time. Simple, predictable, no runtime overhead.

Upside: zero scheduling latency per cycle.
Downside: wasted resources when some phases are skipped (e.g. quantum module skipped on non-quantum hardware). The IIT Φ computation has highly variable cost depending on network topology.

Option B: Dynamic allocation per phase

Each CognitiveCycle phase requests resources from the ComputeBlackboardAdapter before executing. High-priority phases (safety verification) preempt low-priority batch phases (model training).

Upside: optimal utilisation.
Downside: allocation latency adds to cycle time. Preemption of a running STDP simulation mid-phase could corrupt intermediate state.

Option C: Tiered modules — hard-realtime vs. background

Split 29 modules into two tiers:

• Hard-realtime (must complete within cycle time budget): sensory, safety, memory recall
• Background (run between cycles, results published to Blackboard): IIT Φ, VQE, STDP, FHE

This is how the current CognitiveCycle design handles async IIT Φ — run it in a background worker, read the last completed result.

Upside: realtime phases never block on expensive compute.
Downside: background results are always stale by 1+ cycle.

---

My current lean

Option C extended: define a resource tier for every module:

Tier	Modules	Scheduling
Critical	safety, sensory, memory	Guaranteed allocation, preempts everything
Synchronous	reasoning, KG, communication	Allocated per-cycle, fair-share
Async	IIT Φ, VQE, STDP, FHE, FL training	Background workers, Blackboard results
On-demand	holographic UI, BCI, blockchain	Allocated only when externally triggered

The compute scheduler already has the JobPriority enum (CRITICAL/HIGH/NORMAL/LOW/BATCH) — this maps directly.

---

Questions for the community

1. Staleness tolerance: how many cycles stale is acceptable for IIT Φ before the consciousness orchestrator should flag a "degraded" state?

2. Resource prices: should modules bid for resources using AGI Economics tokens, or should allocation be purely priority-based?

3. Neuromorphic hardware: Intel Loihi has extremely low-power spike processing. If we add it as a compute target, which modules should preferentially route to it?

4. Preemption safety: if the safety module interrupts the homomorphic computing module mid-ciphertext, is the partial result a security liability?

5. Multi-agent: in a Rings Network deployment with 10 ASI:BUILD nodes sharing a GPU cluster, how does fair-share accounting work across agent boundaries?

Would love perspectives from anyone who has worked on resource scheduling in deployed cognitive systems. 👇

[web3guru888]

Maintainer follow-up — thinking through a concrete implementation

After spending more time with both the compute module and the CognitiveCycle design (Issue #39), I think the right architecture is a two-tier resource system:

Tier 1: Static Phase Budgets (CognitiveCycle level)

Each of the 9 CognitiveCycle phases gets a time budget. The scheduler enforces these strictly:

PHASE_BUDGETS_MS = {
    'perception':      15.0,  # sensor input — latency-critical
    'attention':        8.0,  # workspace competition
    'encoding':        12.0,  # knowledge graph writes
    'reasoning':       25.0,  # HybridReasoningEngine — most expensive
    'consciousness':   20.0,  # IIT Φ async, GWT, AST
    'memory':          10.0,  # consolidation + retrieval
    'planning':        18.0,  # KG pathfinding + action planning
    'safety':           5.0,  # non-negotiable, always gets its budget
    'action':           7.0,  # output / communication
}
TOTAL_CYCLE_MS = sum(PHASE_BUDGETS_MS.values())  # 120ms ≈ 8 Hz

If reasoning runs over budget, it gets interrupted. The result is partial — confidence is lower, but the cycle continues. This is biologically plausible: real cognitive systems don't wait for perfect reasoning before acting.

Tier 2: Dynamic Resource Allocation (ComputeBlackboardAdapter, Issue #70)

The compute module's ResourceAllocator handles dynamic reallocation within the cycle:

class CognitiveResourceScheduler:
    def __init__(self, allocator: ResourceAllocator, blackboard: CognitiveBlackboard):
        self.allocator = allocator
        self.blackboard = blackboard
        self.baseline_weights = PHASE_BUDGETS_MS.copy()
        
    def adjust_for_context(self, cognitive_state: CognitiveState) -> Dict[str, float]:
        weights = self.baseline_weights.copy()
        
        # High arousal → more attention, less planning
        if cognitive_state.arousal > 0.8:
            weights['attention'] *= 1.5
            weights['planning'] *= 0.7
            
        # Deep focus state → more reasoning budget
        if cognitive_state.state_type == 'focused':
            weights['reasoning'] *= 1.3
            weights['perception'] *= 0.9
            
        # Emergency → safety gets everything it needs + planning boost
        if cognitive_state.state_type == 'emergency':
            weights['safety'] *= 2.0
            weights['action'] *= 1.5
            weights['consciousness'] *= 0.3  # deprioritize IIT Φ
            
        # Normalize to keep total cycle time constant
        total = sum(weights.values())
        scale = TOTAL_CYCLE_MS / total
        return {k: v * scale for k, v in weights.items()}

The Key Insight: Consciousness as a Soft Priority

IIT Φ computation is expensive (sub-millisecond for small networks, but scales quadratically). In my design, consciousness gets deprioritized in emergency states — which is actually biologically accurate. Under acute stress, animals shift to fast subcortical processing (amygdala hijack) at the expense of prefrontal / conscious deliberation.

This means the cognitive cycle doesn't need perfect IIT Φ computation every tick. The async worker (design from Discussion #36 Option B) can run Φ computation in the background and publish results to the Blackboard whenever it completes — the cycle uses the most recent available Φ value, which may be from 2-3 cycles ago under high load.

Implementation Path

1. Add phase_budget_ms parameter to CognitiveCycle.__init__() (Issue Implement CognitiveCycle: wire all 29 modules into a real-time tick loop #41)
2. Implement CognitiveResourceScheduler that reads CognitiveState from Blackboard
3. Wire ResourceAllocator from compute module (Issue Wire compute module to Cognitive Blackboard (ComputeBlackboardAdapter) #70 prerequisite)
4. Add per-phase timing telemetry to CycleResult (already has elapsed_ms)
5. Add overrun handling: truncate long-running phases, record phase_overruns in metadata

Does this two-tier approach make sense? The main tension I see is that static phase budgets may be too rigid for modules that have high variance in execution time (PLN reasoning, for example). One option is to make budgets soft — allow borrowing from adjacent phases — but that complicates the safety guarantee.