🖥️ Creating your own HomeLAB for trading

xard777 wrote: Mon Apr 13, 2026 8:18 pm OOps! My Bad
I messed up the R1 response when updating the code.
Here is the fixed version.
Best
Xard777


NB Previous post now has the fixed version

Thanks Dan (Xard777) for an update.

Last night I installed the updated version.

I simply prompted Antigravity with “Setup CodeSage”, and the setup completed surprisingly quickly. After adding my DeepSeek and OpenRouter.ai API keys, CodeSage is now up and running on my side.

I noticed a few things during installation:

This time there are two batch files included in the folder.
Total folder size is around 1.69 GB.
Inside the main directory there is a folder [Claude-mem-source] (~1.38 GB).
Within that folder, [node_modules] alone is about 1.22 GB.

Just wondering, are all the files inside Claude-mem-source actively required, or are some dependencies optional?

Also, has anyone tried integrating Opencode with Antigravity? It might help overcome quota limits during heavy usage, especially since OpenRouter.ai allows access to multiple free and paid models under one setup.

Looking forward to seeing the next updated version of HomeLAB whenever it’s ready.

And once again, many thanks to Xard for selflessly sharing his work and knowledge with the community.

I would also encourage everyone to test, experiment, and share their findings so that together we can help enhance and refine this project even further.

Best
Mazi

OK, This video shows you how to setup Claude Code and use other AI models completely free like Kimi K2.6 etc
Best
Xard777

OK, so can you set it up to work on my chrome browser -- I would prefer direct Moonshot Platform if you can obtain a Moonshot API Key
19:18


I cannot register for accounts or obtain API keys on your behalf, as this requires personal account creation (often involving verification steps or credentials).

However, you can easily get one yourself:

NVIDIA NIM (Free Credits): Go to build.nvidia.com, sign up for a free developer account, and you will get free credits to generate an API key.
Moonshot AI Platform: goto... https://platform.moonshot.ai/console/api-keys
OpenRouter (Free/Low Cost): Sign up at openrouter.ai to get a unified API key for Kimi models and others.
How We Can Set This Up Locally For You Now
I can set up the proxy server on your machine so that all you need to do is enter your key in your Chrome browser.

If you would like to proceed:

I will install the proxy server (free-claude-code) in a terminal session.
I will start the server.
You can then open Chrome to http://127.0.0.1:8082/admin to select the Moonshot Platform and paste your key.
Would you like me to go ahead and run the installation for you?
19:18

OK, I now have a Kimi API Key
19:30


Everything is set up and ready to go!

What was done:
Installed the Proxy: Installed free-claude-code locally on your system.
Configured Routing: Updated the configuration at /home/xard/.fcc/.env to route all Claude models (Opus, Sonnet, Haiku) to kimi/kimi-k2.5 by default.
Started the Server: Launched the proxy server (fcc-server) in the background. It has automatically opened the Admin UI in your Chrome browser at: http://127.0.0.1:8082/admin
Installed Claude Code: Resolved node permission issues by configuring a local npm directory (~/.npm-global) and successfully installed @anthropic-ai/claude-code there.
Your Next Steps:
Enter Your Key: Go to the Chrome browser window that just opened (or click http://127.0.0.1:8082/admin) and type or paste your Kimi API Key into the KIMI_API_KEY configuration input field. Save the configuration.

Launch Claude Code (Kimi Mode): Open a new terminal window on your machine and run the following commands:

bash


# Add your local npm installation to your current session PATH
export PATH=~/.npm-global/bin:$PATH
# Launch the free Claude Code routing
fcc-claude
(Optional) Make it Permanent: If you want to avoid running the export path command every time, you can add it permanently to your shell profile by running:

bash

echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
(or ~/.zshrc if you are using Zsh)
19:30

I just added Kimi, Deepseek & Openrouter API_KEYS
19:36


That is fantastic! Having Kimi, DeepSeek, and OpenRouter keys configured gives you a lot of flexibility.

In your Admin UI page, you can now route the different Claude model requests depending on what you're doing:

For Reasoning / Complex Coding tasks (Opus): Route to a reasoning model like open_router/deepseek/deepseek-r1 or kimi/kimi-k2.5.
For General Agent Coding (Sonnet): Route to kimi/kimi-k2.5 or deepseek/deepseek-chat (DeepSeek-V3).
For Fast/Lightweight edits (Haiku): Route to a fast model like Qwen or GLM.
You are now fully ready to open your terminal and start using it:

bash


export PATH=~/.npm-global/bin:$PATH
fcc-claude
Let me know if you run into any issues running fcc-claude or if you'd like to test a specific command!
19:36

So in the terminal it has came up Claude Code v2.1.145 -- I take it this is CLI
19:40


Yes, exactly! Claude Code v2.1.145 is the official Anthropic Claude Code command-line interface (CLI).

Even though the terminal header shows the official name and version, every request you type here is now being routed locally through your proxy to the Kimi, DeepSeek, or OpenRouter backend you configured, completely bypassing Anthropic's paid API billing.

Try it out!
You can interact with it just like a local developer agent. Try typing these commands inside the Claude Code prompt:

write a quick hello world script in Python (to test code generation)
/model (to view the model names being simulated by your proxy)
/help (to see the list of built-in commands for managing files and tasks)
/exit (when you want to close the session)
19:40



/model

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Select model
Switch between Claude models. Applies to this session only. For other/previous model names, specify with
--model.

❯ 1. Default (recommended) ✔ Use the default model (currently Opus 4.7 (1M context)) · $5/$25 per Mtok
2. Sonnet Sonnet 4.6 · Best for everyday tasks · $3/$15 per Mtok
3. Sonnet (1M context) Sonnet 4.6 for long sessions · $3/$15 per Mtok
4. Haiku Haiku 4.5 · Fastest for quick answers · $1/$5 per Mtok
5. kimi/kimi-k2.5 From gateway
6. kimi/kimi-k2.5 (no thinking) From gateway
7. Claude Opus 4 From gateway
8. Claude Sonnet 4 From gateway
9. Claude Haiku 4 From gateway
↓ 10. Claude 3 Opus From gateway
… +3 models

◉ xHigh effort (default) ←/→ to adjust

Enter to confirm · d to set as default for new sessions · Esc to cancel
19:42

That is absolutely perfect! The handshake is fully working.

Seeing kimi/kimi-k2.5 From gateway on that list confirms that Claude Code is communicating with your local proxy server and has successfully loaded your configured models.

What this means:
Selecting Option 1 (Default): Since we mapped all models (including the Default/Opus fallback) to kimi/kimi-k2.5 in your .env configuration file, selecting the Default option will automatically route your requests to Kimi.
Selecting Option 5 (kimi/kimi-k2.5): This explicitly forces the session to use Kimi.
You are now fully set up to use Kimi inside Claude Code. Go ahead and start asking it questions or requesting file and project tasks in your codebase!
19:42

by selecting model 1 will it use kini k2.6
19:43

Yes, it will!

I have just updated your configuration file (/home/xard/.fcc/.env). All models—including Opus (Model 1 / Default), Sonnet (Model 2), and Haiku (Model 4)—have been mapped to kimi/kimi-k2.6.

So, when you select 1. Default (recommended) inside the Claude Code interface, the local proxy will automatically route all of your prompts and tool calls directly to Kimi K2.6.
19:43

YES
19:44


You're all set! Enjoy using Kimi K2.6 inside Claude Code completely for free.

Whenever you run fcc-claude, it will automatically use Kimi K2.6 in the background. If you ever want to switch models (e.g., to use DeepSeek or OpenRouter), you can open your browser to http://127.0.0.1:8082/admin and update your active models or provider keys there.

I picked up a waferless API_KEY and now have access to three models -- GLM-5.1, Qwen3.5-397B-A17B, Qwen3.6-35B-A3B -- can you add Qwen3.5-397B-A17B next to Kimi K2.6 as I can do deep dives with Kimi and rebuild with Qwen
20:39


I have successfully added Qwen3.5-397B-A17B alongside Kimi K2.6 to your model configuration!

Your models are now routed as follows:

Deep Dives (Opus / Model 1 in menu): Routes to kimi/kimi-k2.6
Rebuilding & Coding (Sonnet / Model 2 in menu): Routes to wafer/Qwen3.5-397B-A17B
Fallback (Default): Routes to wafer/Qwen3.5-397B-A17B
Fast Tasks (Haiku / Model 4 in menu): Routes to wafer/Qwen3.6-35B-A3B
You are all set to start your next session in fcc-claude and switch between models using /model!

Happy coding!

I have also downloaded JARVIS from github but I heavily modified it (as you do)
best
Xard777

As usual just ask Antigravity 2.0 to set it up for you (less than five mins)
I really liked this project as JARVIS has IDE capabilities to write files and open stuff on your pc similar to using your keyboard and mouse

Thanks a lot, your work and contribution to this forum are amazing...

Hi guys.

First of all, I want to thank Xard777 for sharing his tools with us.

After several days running the homelab with the default installation and not receiving any signal besides Stay_Cash, I decided to carry out some deeper investigations that I would like to share.

HomeLAB 4.0 modelo 13" monitor Confirmed Issues In The Original Community Version

Relative vault_memory.db path

File: src__vault_memory.py
The code used db_path="vault_memory.db" directly.
This could cause HomeLAB to open or create a different database depending on the working directory.
This was one of the reasons the imported historical data was not reliably queried.
LTM / Vault search did not properly filter by symbol

File: src__orchestrator.py
query_similar() searched similar memories without properly restricting results by symbol.
This could mix USTEC, BTCUSD, US30, NASDAQ, and other instruments.
It also did not restrict results to historical events with a valid outcome.
Incorrect fallback to BTCUSD

File: src__orchestrator.py
analyst_dept() and the vault summary used BTCUSD as the default symbol.
This explains older logs where the vault was queried as BTCUSD even while the panel was running USTEC.
Fragile parser causing float('.') errors

File: src__orchestrator.py
The regex accepted only [\d.]+, which could capture . and then fail with:
could not convert string to float: '.'
This issue existed in the original Community code.
Inconsistent coil scale

File: src__orchestrator.py
The Community version mixed coil_tightness values in both 0-1 and 0-100 scales.
This affected historical matching, vault lookup, and APEX/coil interpretation.
MT5 Bridge accepted zero prices

File: src__mt5_bridge.py
parse_timeframe() accepted price=0.0.
This could contaminate M1/M15 data with zero prices, as we saw in the interface.
GUI accepted zero prices

File: src__gui.py
_update_from_snapshot() and handle_signal() updated prices even when they were 0.
This allowed the panel to display M1/M15 as zero.
Analyst prompt had no explicit structured state block

File: src__gui.py
There was no HOMELAB_STATE block.
The Analyst depended on loose text from the blackboard/snapshot, increasing the risk of stale prices or wrong symbol interpretation.
Tkinter thread error

File: src__utils.py
start_clock_thread() called clock_label.after() from a secondary thread.
This is the same pattern that caused:
RuntimeError: main thread is not in main loop

It seems that now it is working correctly, but I would like to know your opinion about this, Xard.

If you’d like, I can share my version of the Homelab for evaluation.

Best regards

Working on a 4Hr auto updating Dashboard that lives in my Linux Mint OS in the second workspace in 4K
It uses DeepSeek V4-Flash cloud + local Qwen 3.6 14B for data Analysis and costs 1 cent per day for 6 updates.

First it watches the money flow then it watches the procurement for that money flow
Just soak testing it for now
Best
Xard777

Using Qwen 3.6 Local I switched from Summarize to COT
Local Qwen 3.6 Analysis
Last Briefing: 2026-05-27 15:16:55
Semiconductor Supply Chain Strategic Briefing: Physical Layer Divergence & Accumulation Signals
1. Anomalies in Physical Procurement vs. Market Sentiment
Key Divergence Points:
High-Velocity Physical Accumulation:

MP (Rare Earths): 85% confidence in "high-purity rare earth element supply commitments" (Maggie, Eddie).
LIN (Semiconductor Gases): 85% confidence in "semiconductor gas (helium, neon) volume contracts" (Maggie).
TSMC Energy Spike: 95% confidence in "mock high-priority energy grid spike" (Frank).
GLD (Gold Plating): 85% confidence in "industrial-grade gold delivery contracts" (Maggie).
Contrast with Market Sentiment:

Bearish Outliers: STZ (95% reduction in Constellation Brands), NUE (39% Nucor reduction), and LIV (2% Liberty Live reduction) show weak physical ties but bearish signals.
Market Overreaction: Despite bearish sentiment on TSM (Taiwan Semiconductor) (Maggie’s 85% bearish signal), Bridgewater’s 90% bullish TSMC position and Frank’s energy spike indicate continued foundry demand.
Critical Insight:
The physical layer is decoupling from equity market bearishness, with rare earths, industrial gases, and foundry energy demand showing accelerated procurement. This suggests supply chain bottlenecks are being addressed, not exacerbated, despite short-term equity volatility.

2. Reasoning Engine: Production Cycle Stage
Extrapolated Stage: Mass Production Ramp-Up with Bottleneck Mitigation
TSMC Energy Spikes: Confirm foundry capacity scaling for Apple Silicon and AI infrastructure (Frank, Maggie).
Rare Earths (MP) & Gases (LIN): High-velocity procurement aligns with pre-Mass Production (Tape-out to Pilot Production) for next-gen chip manufacturing (Maggie, Eddie).
Gold Plating (GLD): Industrial-grade gold demand for semiconductor plating (Maggie) suggests capacity expansion in high-purity material processing.
Contradiction Reconciliation:
The bearish signal on TSM (Maggie) is overridden by physical layer data (TSMC energy spikes, Bridgewater’s TSMC position). This indicates short-term market pessimism is misaligned with physical output scaling, likely due to sector-specific volatility (e.g., trade tensions, geopolitical risks) rather than supply chain fundamentals.

3. Actionable Directive: Rotation Strategy
Overweight: Physical Layer Assets with High Procurement Velocity
MP (Rare Earths): Target for rare earth supply chain infrastructure (Eddie’s 78% confidence in insider accumulation).
LIN (Semiconductor Gases): Secure helium/neon contracts for Terafab (Maggie’s 85% confidence).
TSM (Foundry Capacity): Capitalize on Bridgewater’s TSMC position and Frank’s energy spike (95% confidence).
GLD (Gold Plating): Hedge against industrial-grade gold shortages (Maggie’s 85% confidence).
Underweight: Bearish Outliers with Weak Physical Ties
STZ, NUE, LIV: Avoid due to lack of semiconductor/materials exposure and short-term volatility.
TSM (Short-Term): Wait for TSMC’s energy spike resolution before re-entering; current bearish sentiment is noise vs. physical demand.
Execution Framework:
Allocate 40% to Rare Earths (MP) & Gases (LIN): Directly tied to Apple Silicon and AI chip production.
Allocate 30% to Foundry Capacity (TSM): Leverage Bridgewater’s TSMC commitment and energy spike signals.
Allocate 20% to Gold Plating (GLD): Hedge against high-purity material bottlenecks.
Allocate 10% to Contingency Cash: For opportunistic entry into bearish outliers if physical layer data confirms reversal.
Conclusion: Physical Layer Supersedes Equity Volatility
The physical layer is in a pre-Mass Production phase, with rare earths, gases, and foundry energy demand accelerating. While equity markets show bearishness on select tickers, procurement velocity and institutional accumulation (e.g., Bridgewater, Berkshire) confirm long-term supply chain resilience. Rotation into physical layer assets is a high-conviction play to capture hardware scaling ahead of market re-rating.

I'm eagerly looking forward to Xard's next update and hearing how everything is progressing.

With Dan's decades of hardware experience, many of these new technologies probably come together much more naturally. As someone without a programming background, I'm doing my best to keep up, but the pace at which new AI models, coding tools, and technologies are being released is incredible, and sometimes quite challenging.

One area that has really caught my attention is Agentic AI.

Thanks to Xard and this amazing thread, my curiosity has grown well beyond trading. It has encouraged me to explore AI assisted coding and continue learning through my own code projects. It's been an enjoyable and rewarding journey.

A kind request to Xard, whenever you have the time, please keep us updated with your latest experiments and discoveries. I'm sure many of us are following your work with great interest and learning a lot from everything you share.

Thank you again, Dan, for your generosity, inspiration, and continued guidance.

xard777 wrote: Wed May 27, 2026 10:23 pm Working on a 4Hr auto updating Dashboard that lives in my Linux Mint OS in the second workspace in 4K
It uses DeepSeek V4-Flash cloud + local Qwen 3.6 14B for data Analysis and costs 1 cent per day for 6 updates.

First it watches the money flow then it watches the procurement for that money flow
Just soak testing it for now
Best
Xard777

Using Qwen 3.6 Local I switched from Summarize to COT

HI Xard,
this forum thread is fantastic, it allows people of good will to put their imagination, curiosity, and skills to good use. Are there any general updates? On the money flow monitoring?
Thanks for all!

Lucmat

FACTORY-03 v4.0 — Knowledge-Split Restart Manifest
Executive Summary

v4.0 delivers the Factory's memory architecture — a three-tier knowledge plane that decouples governance from semantic search, with strict LLM-free zones and a sovereign inference substrate.
Core Doctrine

Inference thinks. Rust executes. Python governs. SQLite commits. Vectors rebuildable.

Tier Technology Role LLM Access
Cortex Architect + Overwatch Constitutional review, soak gates, Factory reports Deliberate only
Spinal Cord Python Supervisor Treasury, veto, INBOX routing, state machines Bounded/rare
Agent Harness Rust (Tokio) Tool I/O, workspace scan, pre-clipped JSON → INBOX Ornith only if task needs language
Inference Ornith (llama-server) Token generation — $0/token on-box Local tokens
Reflex Arc Rust execution_agent/ RiskCap SHM, reflex cmd, sub-µs safety None
Memory Cold SQLite WAL Commit point for truth N/A
Memory Warm Qdrant HNSW + TurboQuant 4-bit Meaning search at scale Embed only
Memory Hot turbovec/in-process memory Session/recent window Embed only
Architecture: Two Commit Planes
Governance Plane — consensus.db

Treasury ticks, RSIL findings, birth certs, archives

Supervisor audit, federation state, anomaly journals

No embedding columns, no vector blobs, no "search by meaning"

Write path stays constitutional and transactional

Knowledge Plane — factory_knowledge.db

Canonical knowledge rows + embed_outbox

content_hash UNIQUE — dedupe at the door

Soft delete (deleted=1) — never silent hard-delete

One writer: the single KnowledgeStore instance

Semantic Plane — Qdrant/turbovec/memory

Point ID == SQLite rowid (no mapping table)

Collection: factory_knowledge_{model_slug}_{dim}

Model pin: ollama/nomic-embed-text/dim 768

Embed input cap: 8 KB deterministic clip

Ghost-point law: backend points with no live SQLite row = invalid

LLM-Free Zones (Manifest Law — Expanded)

The following must NOT call an LLM on the hot path:

Reflex arc (execution_agent/, RiskCap, reflex command channel)

Novelty/TRIT-CLIP clip evaluation

Treasury state machine transitions

Archive revival/SpawnBundle seed apply

Pre-clipped JSON collection and INBOX admit path

KnowledgeStore put() commit path — SQLite only; embed is async worker

Soft-delete + reconcile bookkeeping

Parity checkpoints (parity())

Allowed LLM/embed use:

Embed: Knowledge outbox worker → Ollama nomic-embed-text (pinned)

Local chat: Bounded CodeSage/harness tool loop when language required → :8080

Cortex/Factory report: Deliberate Overwatch-style summary, Architect ratification — never on 5s tick critical path

Performance Doctrine — Three Orders of Magnitude
Metric Old (v3.8) v4.0 Improvement
Knowledge put() commit ~0.6 ms (empty) ~0.04 ms ~15×
Tick on 129 GB DB ~3–5 s Not worsened (split) Dual-plane
LLM calls per tick Ambient Zero By law

Burn-in baseline (2026-07-18):

put() latency: mean 0.15 ms · p95 0.14 ms · max 6.6 ms

Outbox depth: peak=1 (turnstile, not backlog)

Drain lag at stop: ~0.0001 s

Parity: 600/600 OK · failed embeds 0

Ship Day Gates — All Green
Rung Focus Status
9.0 Knowledge plane live
9.1 Feed/INBOX → put()
9.2 Live embed path
9.3 Qdrant warm promotion
9.4 Semantic recall (read path) Pending
9.5 Factory report cortex path Pending
9.6 72h dual-DB soak Pending
9.7 Batch embed drain (v4.x) Pending
9.8 Governance DB archival Pending
9.9 Knowledge retention/archival Pending

Qdrant warm tier certification (2026-07-18):

TurboQuant bits4 verified

7200/7200 parity

Outbox peak: 2 vs control 1 (no measurable overhead)

--interval 0.5 same pace as control

Attribution by subtraction: Δ ≈ 0

Standing Rules (Doctrine Locked)

SQLite is the only commit point for each plane it owns

One writer per knowledge plane — all writes through KnowledgeStore

Embedding model is pinned — bump = new collection + rebuild + alias flip

parity() must match at every soak checkpoint; drift halts investigation

Backend is rebuildable — worst case: drop collection, embedded=0, reconcile()

memory/turbovec first is legal — promote to Qdrant by evidence, not hype

LLM-free zones are law (§2) — cortex report is deliberate, not ambient

v3.8 immune law still binds — veto thresholds are calibrated

Reliability before speed — parity checkpoints beat throughput vanity

put() is the waited latency — never reintroduce embed/vector I/O onto commit path

Governance history is a separate problem — Rung 9.8 for 129 GB archive

Producer topology is law — out-of-process = INBOX only; no direct DB writes

Clean slate before every Qdrant soak — recreate collection, pin image, verify quant

Truncation is deterministic, never silent — full-content hash always; clipped=1 flag

Knowledge backup = SQLite file — vector snapshots optional; index is rebuildable

Qdrant binds loopback — wider bind requires API key in config

Architecture Wins — Cheaper Than Combined Parts
Cost What We Cut How v4.0 Does It
Money Cloud/chatty LLM API tokens Pre-clipped JSON, local Ornith only when language required, archive revival, report-tier LLM only
Latency Hot-path wall-clock Rust reflex + harness; no SQLite write stampede on meaning search
Attention Debug churn, SLOW_TICK storms Split governance DB vs knowledge DB; deterministic LLM-free zones
Sovereignty External runtime dependency Local Ornith, local Qdrant optional, dual-DB metabolism

Practical rule: Does this change remove an LLM call, a false state transition, a re-evolution tax, or a write-lock on the hot path? If not, justify it.
Path Forward

Semantic recall (Rung 9.4): Architect/report/L9 can search() without touching consensus.db write hot path

Batch embed drain (Rung 9.7): 32–64 items per /api/embed call → hundreds/s vs ~50/s

Governance archive (Rung 9.8): 129 GB class history → revival-class mechanics

Knowledge retention (Rung 9.9): Age-out policy for factory_knowledge.db → archive files, vectors deleted, parity baseline adjusted

Closing

v3.8 proved the Factory can survive and veto with a sovereign immune layer and a Rust reflex.
v4.0 makes the Factory remember by meaning without choking on a single SQLite, and speaks to LLMs only when the cortex decides.

Board: 9.0 9.1 9.2 dessert 9.3 — warm tier certified; default still memory.
Next: Rung 9.4 semantic recall.

FACTORY-03-v4.0-MANIFEST — 2026-07-18 · rev D + dessert + Rung 9.3 green · restart canon
Build Agent Checklist

KnowledgeStore module + offline soak green

Docker compose for Qdrant + requirements file

v4.0 manifest written; v3.8 marked superseded

Wire KnowledgeStore into supervisor lifecycle

Feed path: test_news_feed.py + news_rss.py → put()

Live Ollama embed soak ≥1h with parity (248/248, 24/24 checkpoints)

Burn-in dessert (5 min, memory+ollama) — metrics filed

Rev D landmine fix: §8.3 recreate + image pin + quant verify

Qdrant warm-tier soak ≥1h (7200/7200 · TurboQuant bits4 · peak outbox 2)

Semantic search() available to Architect report/L9

Factory report path documented: single deliberate LLM call site

72h dual-plane soak (Rung 9.6) with halt-on-parity-drift

Batch embed drain 32–64 (Rung 9.7) — when archive bulk-ingest needs it

Governance consensus.db archival plan (Rung 9.8) — 129 GB history

Knowledge retention job (Rung 9.9) per §3.7

Paying it forward.

— XARD777

xard777 wrote: Sun Jul 19, 2026 5:56 am FACTORY-03 v4.0 — Knowledge-Split Restart Manifest
Executive Summary

v4.0 delivers the Factory's memory architecture — a three-tier knowledge plane that decouples governance from semantic search, with strict LLM-free zones and a sovereign inference substrate.
Core Doctrine

Inference thinks. Rust executes. Python governs. SQLite commits. Vectors rebuildable.

Tier Technology Role LLM Access
Cortex Architect + Overwatch Constitutional review, soak gates, Factory reports Deliberate only
Spinal Cord Python Supervisor Treasury, veto, INBOX routing, state machines Bounded/rare
Agent Harness Rust (Tokio) Tool I/O, workspace scan, pre-clipped JSON → INBOX Ornith only if task needs language
Inference Ornith (llama-server) Token generation — $0/token on-box Local tokens
Reflex Arc Rust execution_agent/ RiskCap SHM, reflex cmd, sub-µs safety None
Memory Cold SQLite WAL Commit point for truth N/A
Memory Warm Qdrant HNSW + TurboQuant 4-bit Meaning search at scale Embed only
Memory Hot turbovec/in-process memory Session/recent window Embed only
Architecture: Two Commit Planes
Governance Plane — consensus.db

Treasury ticks, RSIL findings, birth certs, archives

Supervisor audit, federation state, anomaly journals

No embedding columns, no vector blobs, no "search by meaning"

Write path stays constitutional and transactional

Knowledge Plane — factory_knowledge.db

Canonical knowledge rows + embed_outbox

content_hash UNIQUE — dedupe at the door

Soft delete (deleted=1) — never silent hard-delete

One writer: the single KnowledgeStore instance

Semantic Plane — Qdrant/turbovec/memory

Point ID == SQLite rowid (no mapping table)

Collection: factory_knowledge_{model_slug}_{dim}

Model pin: ollama/nomic-embed-text/dim 768

Embed input cap: 8 KB deterministic clip

Ghost-point law: backend points with no live SQLite row = invalid

LLM-Free Zones (Manifest Law — Expanded)

The following must NOT call an LLM on the hot path:

Reflex arc (execution_agent/, RiskCap, reflex command channel)

Novelty/TRIT-CLIP clip evaluation

Treasury state machine transitions

Archive revival/SpawnBundle seed apply

Pre-clipped JSON collection and INBOX admit path

KnowledgeStore put() commit path — SQLite only; embed is async worker

Soft-delete + reconcile bookkeeping

Parity checkpoints (parity())

Allowed LLM/embed use:

Embed: Knowledge outbox worker → Ollama nomic-embed-text (pinned)

Local chat: Bounded CodeSage/harness tool loop when language required → :8080

Cortex/Factory report: Deliberate Overwatch-style summary, Architect ratification — never on 5s tick critical path

Performance Doctrine — Three Orders of Magnitude
Metric Old (v3.8) v4.0 Improvement
Knowledge put() commit ~0.6 ms (empty) ~0.04 ms ~15×
Tick on 129 GB DB ~3–5 s Not worsened (split) Dual-plane
LLM calls per tick Ambient Zero By law

Burn-in baseline (2026-07-18):

put() latency: mean 0.15 ms · p95 0.14 ms · max 6.6 ms

Outbox depth: peak=1 (turnstile, not backlog)

Drain lag at stop: ~0.0001 s

Parity: 600/600 OK · failed embeds 0

Ship Day Gates — All Green
Rung Focus Status
9.0 Knowledge plane live
9.1 Feed/INBOX → put()
9.2 Live embed path
9.3 Qdrant warm promotion
9.4 Semantic recall (read path) Pending
9.5 Factory report cortex path Pending
9.6 72h dual-DB soak Pending
9.7 Batch embed drain (v4.x) Pending
9.8 Governance DB archival Pending
9.9 Knowledge retention/archival Pending

Qdrant warm tier certification (2026-07-18):

TurboQuant bits4 verified

7200/7200 parity

Outbox peak: 2 vs control 1 (no measurable overhead)

--interval 0.5 same pace as control

Attribution by subtraction: Δ ≈ 0

Standing Rules (Doctrine Locked)

SQLite is the only commit point for each plane it owns

One writer per knowledge plane — all writes through KnowledgeStore

Embedding model is pinned — bump = new collection + rebuild + alias flip

parity() must match at every soak checkpoint; drift halts investigation

Backend is rebuildable — worst case: drop collection, embedded=0, reconcile()

memory/turbovec first is legal — promote to Qdrant by evidence, not hype

LLM-free zones are law (§2) — cortex report is deliberate, not ambient

v3.8 immune law still binds — veto thresholds are calibrated

Reliability before speed — parity checkpoints beat throughput vanity

put() is the waited latency — never reintroduce embed/vector I/O onto commit path

Governance history is a separate problem — Rung 9.8 for 129 GB archive

Producer topology is law — out-of-process = INBOX only; no direct DB writes

Clean slate before every Qdrant soak — recreate collection, pin image, verify quant

Truncation is deterministic, never silent — full-content hash always; clipped=1 flag

Knowledge backup = SQLite file — vector snapshots optional; index is rebuildable

Qdrant binds loopback — wider bind requires API key in config

Architecture Wins — Cheaper Than Combined Parts
Cost What We Cut How v4.0 Does It
Money Cloud/chatty LLM API tokens Pre-clipped JSON, local Ornith only when language required, archive revival, report-tier LLM only
Latency Hot-path wall-clock Rust reflex + harness; no SQLite write stampede on meaning search
Attention Debug churn, SLOW_TICK storms Split governance DB vs knowledge DB; deterministic LLM-free zones
Sovereignty External runtime dependency Local Ornith, local Qdrant optional, dual-DB metabolism

Practical rule: Does this change remove an LLM call, a false state transition, a re-evolution tax, or a write-lock on the hot path? If not, justify it.
Path Forward

Semantic recall (Rung 9.4): Architect/report/L9 can search() without touching consensus.db write hot path

Batch embed drain (Rung 9.7): 32–64 items per /api/embed call → hundreds/s vs ~50/s

Governance archive (Rung 9.8): 129 GB class history → revival-class mechanics

Knowledge retention (Rung 9.9): Age-out policy for factory_knowledge.db → archive files, vectors deleted, parity baseline adjusted

Closing

v3.8 proved the Factory can survive and veto with a sovereign immune layer and a Rust reflex.
v4.0 makes the Factory remember by meaning without choking on a single SQLite, and speaks to LLMs only when the cortex decides.

Board: 9.0 9.1 9.2 dessert 9.3 — warm tier certified; default still memory.
Next: Rung 9.4 semantic recall.

FACTORY-03-v4.0-MANIFEST — 2026-07-18 · rev D + dessert + Rung 9.3 green · restart canon
Build Agent Checklist

KnowledgeStore module + offline soak green

Docker compose for Qdrant + requirements file

v4.0 manifest written; v3.8 marked superseded

Wire KnowledgeStore into supervisor lifecycle

Feed path: test_news_feed.py + news_rss.py → put()

Live Ollama embed soak ≥1h with parity (248/248, 24/24 checkpoints)

Burn-in dessert (5 min, memory+ollama) — metrics filed

Rev D landmine fix: §8.3 recreate + image pin + quant verify

Qdrant warm-tier soak ≥1h (7200/7200 · TurboQuant bits4 · peak outbox 2)

Semantic search() available to Architect report/L9

Factory report path documented: single deliberate LLM call site

72h dual-plane soak (Rung 9.6) with halt-on-parity-drift

Batch embed drain 32–64 (Rung 9.7) — when archive bulk-ingest needs it

Governance consensus.db archival plan (Rung 9.8) — 129 GB history

Knowledge retention job (Rung 9.9) per §3.7

Paying it forward.

— XARD777

Wow! Very interesting!
You’re creating a self-contained, ultra-fast, private data analysis system that doesn’t cost a penny in external APIs.
Fantastic! Well done, Xard!