Brainiak Topological Al drives LLM by loRa runtime adapters

1. Brainiak first, Brainiak_Q second

Brainiak

Brainiak is the decision brain (ZTTM).It is designed for:

• Decision sovereignty outside the LLM.
• Stateful runtime with bounded active context.
• Verifiable transitions through receipts.
• Memory that becomes actionable, not just textual.

Brainiak_Q

Brainiak_Q is the governed LLM runtime layer on top of Brainiak.“Q” refers to Qwen 3.5 27B (+ LoRA adapters via vLLM).

Role split:

• Brainiak/ZTTM decides.
• ToolHub executes.
• Brainiak_Q orchestrates governed runtime projection.
• The LLM verbalizes and reformulates, but does not decide.

2. Non-negotiable architecture constraints

Brainiak is defined by strict invariants:

• The LLM does not decide.
• The frontend does not carry decision context.
• Tools are not “intelligent.”
• ToolHub executes but does not arbitrate.
• ZTTM remains the decision authority.
• Every action emits a receipt.
• Receipts feed live memory.
• Memory becomes operational (affordance-generating), not only conversational.

3. Canonical loop

Brainiak runs this loop:

perception -> ZTTM decision -> ToolHub action -> receipt -> live memory -> affordance -> next ZTTM decision -> next action

This is fundamentally different from:

conversation history -> LLM answer

4. Minimal proof: “weather in Lille” -> “the 1”

The scenario is intentionally simple.

Turn 1

• User asks for weather in Lille.
• ZTTM selects web_search.
• ToolHub executes.
• System emits a verifiable indexed receipt ([1], [2],...).
• Receipt is written into live memory (memory_w, LoRA_context_layer, dynamic_knowledge_payload).

Turn 2

• User says only: “the 1”.
• ZTTM resolves this pointer from prior receipt state.
• ZTTM selects http_request.
• ToolHub executes and emits a second clean receipt (title, canonical URL, description).

Expected diagnostics in this flow:

• llm_used=false on action decision in turn 2.
• Route trace consistent with receipt-driven decision flow (for example: brainiak_q_zttm_toolhub_receipt).

Why this is a big deal:The UI interaction is tiny, but the architecture signal is huge:a prior event is transformed into next executable intent without LLM arbitration.

5. Why this is not just RAG or classic tool-calling

RAG

Retrieves context to improve text generation.

Classic tool-calling agents

Often let the LLM decide tool routing.

Chat-history bots

Mostly replay textual context.

Brainiak

Uses receipts as operational state:

• Action result -> receipt.
• Receipt -> affordance.
• Affordance -> next ZTTM decision.
• ToolHub executes under explicit decision authority.

6. Runtime model: bounded active state, extensible memory horizon

Brainiak does not claim infinite token context in one window.

It uses:

• Bounded active runtime state (sliding discipline).
• Persistent memory layers (Postgres/Qdrant via memory_w).
• Controlled reprojection into live operational context.

So the right framing is:bounded runtime, extensible memory horizon.

7. CPU-first, on-prem, traceable

Brainiak is built around CPU-first conceptual/topological inference in the decision core.The LLM is integrated as a governed effect layer.

Practical consequences:

• Better control over system behavior.
• Explicit separation of decision/execution/verbalization.
• Natural on-prem deployment posture.
• Auditable action transitions through receipts.

8. What is claimed (and what is not)

Claimed

• A validated receipt-mediated operational memory loop.
• Decision sovereignty outside the LLM in the demonstrated flow.
• End-to-end auditable transitions.

Not claimed

• No AGI claim.
• No universal “zero hallucination” claim across all tasks.
• No “first in the world” absolute claim.

The strong, defensible claim is architectural:Brainiak changes control topology, not just model size.

9. Screenshots to include (evidence pack)

For credibility, include these images in your Hackster post:

• Turn 1 user query (“weather in Lille”).
• Tool selection (web_search) trace.
• Receipt #1 with indexed results.
• Live memory write/projection evidence.
• Turn 2 input: “the 1”.
• Decision diagnostics (llm_used=false for action arbitration).
• http_request execution trace.
• Receipt #2 with canonicalized output.
• Architecture diagram: Brainiak -> Brainiak_Q -> ToolHub -> receipts -> memory -> affordances.

Important: redact secrets, tokens, private hostnames, and sensitive infra details.

10. Theoretical foundation (arXiv preprints)

A General Equilibrium Theory of Orchestrated AI Agent Systemshttps://arxiv.org/abs/2602.21255

• A General Equilibrium Theory of Orchestrated AI Agent Systemshttps://arxiv.org/abs/2602.21255

Agentic Hives: Equilibrium, Indeterminacy, and Endogenous Cycles in Self-Organizing Multi-Agent Systemshttps://arxiv.org/abs/2603.00130

• Agentic Hives: Equilibrium, Indeterminacy, and Endogenous Cycles in Self-Organizing Multi-Agent Systemshttps://arxiv.org/abs/2603.00130

Fractal Algebraic Topology of Semantic Computation. A Peer-Review-Oriented Formalization of the SSTD/Brainiak Concept Bundlehttps://arxiv.org/abs/2606.24240

• Fractal Algebraic Topology of Semantic Computation. A Peer-Review-Oriented Formalization of the SSTD/Brainiak Concept Bundlehttps://arxiv.org/abs/2606.24240

Conclusion

Brainiak is not “a bigger LLM.”It is a different architecture class:

• Topological decision core (ZTTM).
• Tool execution under explicit authority (ToolHub).
• Receipt-driven operational memory.
• Governed LLM runtime (Brainiak_Q) for effect and verbalization.

The “the 1” demo looks small from a user perspective.Architecturally, it demonstrates a major transition: from passive history to quasi_infinite actionable memory