# Semantic Signal (qrak.org) — full site text

Source: https://qrak.org | Generated from the deployed build; every page of the
site as plain text, for LLM tools and crawlers.

Fact sheet in JSON: https://qrak.org/project.json
Short index: https://qrak.org/llms.txt
Source code: https://github.com/qrak/LLM_trader

Status carried with every page: paper trading only (simulated capital), executor
on an exchange testnet, profitability unproven, not financial advice.


==============================================================================
## Home
URL: https://qrak.org/
==============================================================================

Open source • Python 3.13 • simulated capital by default
Most trading bots do arithmetic. This one reads the chart, remembers its trades, and has to defend every call.
Semantic Signal renders a 1920×1080 candlestick chart for a multimodal model, keeps a 768-dimensional semantic memory of closed-trade experiences, and applies deterministic risk checks before an order can be sent.
Read the 9-month storyLive dashboard ↗GitHub ↗
trading
simulated capital (paper)

live executor
exchange testnet only — no real funds

test suite
2,265 tests · 2,247 passing · 17 skipped · 1 failing (live-dashboard test)

providers
Google AI, DeepSeek, OpenRouter, local — switchable

What this project combines
Open-source trading projects solve different parts of the problem. Freqtrade focuses on mature execution and backtesting; TradingAgents explores multi-agent market research; Vibe-Trading combines vision and agent workflows. This project combines chart vision, local trade memory and deterministic risk limits in one experimental, local-first research loop.
This is not a claim that no other bot has any individual feature, nor a claim of superior returns. Read the linked source code and the risk disclaimer before using any trading software.

chart_vision
An image, not just indicator floats
A Plotly candlestick chart at 1920×1080 with SMA, RSI, CMF and OBV goes to the multimodal model alongside the numeric stack. Wick geometry, volume spikes and wedges are read off the picture — but every number the model cites is checked against the computed values.

vector_memory
768D memory of closed-trade experiences
Closed-trade experiences are embedded with BAAI/bge-base-en-v1.5 into ChromaDB. Before each decision the bot retrieves the three most similar past setups, each tagged with aSurprise Ratio so a lucky win does not become a rule.

risk_governance
Deterministic risk limits constrain the model
The model proposes a trade, but symbol restrictions, position caps and stop/target validation remain deterministic checks. Position sizing is capped and uses documented fallback profiles rather than treating model confidence as a guarantee.

executor
Reasoning and execution are separate processes
The engine emits one atomic JSON decision; a second service does CCXT order placement, leverage and exchange-side stops, and writes a verdict journal the engine reads back. The bot confirms what happened to its own order instead of assuming it.

Built in a Wrocław apartment after warehouse shifts
In December 2025 I was working 8-hour warehouse shifts in Poland and testing "AI trading bot" templates in the evenings. Nine months later the project has 2,265 automated tests, layered agent documentation (a root AGENTS.md plus one per package), and a live executor running against an exchange testnet — not a cent of real money, by design.
Read the full development history →
From the blog
How the bot reads charts
Market history, 79 Numba indicator functions, a 1920×1080 chart image — and a model prompted to defend its call.
Vector memory
How 768D embeddings turn closed trades into lessons the bot retrieves before every decision.
Paper → live: the executor
Why reasoning and order placement are separate services, and what is still missing before real capital.

Where every number on this page comes from
Nothing here is a screenshot from a course. All of it lives ingithub.com/qrak/LLM_trader:
chart image 1920x1080 src/analyzer/pattern_engine/chart_generator.py
market data, 50 lvls config/config.ini · src/analyzer/data_fetcher.py
trade memory 768D src/trading/vector_memory.py (BAAI/bge-base-en-v1.5)
risk limits, pre-entry src/trading/position_management.py
agent docs, 9 files AGENTS.md + one per package (src/trading, src/analyzer, ...)
tests 2,265 python -m pytest tests -q -> 2,247 passed, 17 skipped

⚠️ Risk disclaimer: Semantic Signal is an experimental, open-source software project — not financial advice, not a money machine. It trades simulated capital by default, it has lost money on paper during development, and trading cryptocurrencies carries substantial risk of loss. Read the full disclaimer.


==============================================================================
## The full development story & technology
URL: https://qrak.org/story/
==============================================================================

Published July 2026 · last updated 15 October 2026 · by @qrak
I Built a Trading Bot That Doesn't Just Calculate — It Sees, Remembers, and Learns from Its Failures
The engineering history of an open-source, vision-capable crypto bot — first commit 21 December 2025.
1. The Wrocław warehouse spark
In December 2025 I was living in Wrocław, Poland, working 8-hour warehouse shifts. My back was sore, my energy depleted, and my mind was stuck on one question: why are all the "AI trading bots" out there so dumb?
I did what every YouTube tutorial recommends. Pull RSI, MACD and Bollinger Bands in Python, write a prompt template, dump the floats into an LLM API. The decisions came back confident, articulate — and wrong. "RSI is at 28, oversold. BUY." Then the market went down instead, and the paper portfolio went with it.
The model was not the problem. The architecture was. I had built a stateless calculator and called it a reasoning engine.

2. The timeline, taken from git log
Every date below is the date a file first appeared in the repository or a commit landed. You can check all of them with git log --date=short --diff-filter=A.

Phase 1 — December 2025: the stateless calculator
First commit 21 Dec 2025, multimodal support via OpenRouter on 28 Dec. The candle_limit = 999 value has been in config.ini since that very first commit, the order book is fetched at 50 levels, and the bot had no memory of anything it did.

Phase 2 — January 2026: the bot gets eyes
The dashboard server lands 6 Jan; the ChartGenerator (16 Jan) renders OHLCV and RSI into a PNG the model can actually look at, with the image-export retry logic that Plotly/Kaleido makes necessary. The bot stops reading floats and starts reading a chart.

Phase 3 — May 2026: the brain
16 May: the vector-memory era. brain_experience, brain_context and brain_reflection arrive — closed trades become 768D embeddings in ChromaDB, retrievable before the next decision, with a reflection pass that writes rules in plain language. A few days earlier (12 May) came the blunt commit message "make bot profitable with Gemini Flash 3 Preview" — that one aged badly, and I left it in the history on purpose.

Phase 4 — July 2026: the bot starts maintaining itself
26 Jul: the .ai/ directory appears — a supervisor plus seven specialist agents (Bolt, Palette, Sentinel, Refactor, Concise, Bugfixer, Smoke Tests) with their own journals. 30 Jul: Reddit/RSS sentiment lands, and with it the public landing page.

Phase 5 — August 2026: the executor and the verdict journal
14 Aug: executor integration. The engine stops assuming what happened to its orders and starts reading a verdict journal — one line per decision, written by the executor service, keyed by the bot's own order_id. Orders that cannot be confirmed go to a dead-letter queue instead of vanishing.

Phase 6 — September 2026: providers, tests, and a smaller ego
12 Sep: provider transport consolidation and the official DeepSeek API added next to Google AI. 19 Sep: the test suite is reorganised into domain modules and the entry gate is reduced to expected value alone — the fixed R/R floor is gone, and the brain earns its own floor from its own expectancy. 1,549 tests collected at that point, 1,532 passing, 17 skipped.

3. The mathematics and the engineering
The Numba JIT indicator engine
Indicators are written in NumPy and decorated with Numba's @njit(cache=True), so they compile to machine code on first call and cache the result. src/indicators/ contains 79 Numba-compiled functions (116 across the whole src/ tree) with zero external technical-analysis dependencies. Real code, not a screenshot:
@njit(cache=True)
def supertrend_numba(high: np.ndarray, low: np.ndarray, close: np.ndarray,
length: int = 10, multiplier: float = 3.0) -> tuple[np.ndarray, np.ndarray]:
"""Calculate Supertrend indicator."""
n = len(close)
atr = atr_numba(high, low, close, length)

hl2 = (high + low) / 2
upperband = hl2 + multiplier * atr
lowerband = hl2 - multiplier * atr

# ... band adjustments, then the trend/direction loop
return trend, direction
src/indicators/trend/trend_indicators.py — trimmed; the full function is in the repo.
Chart vision
Plotly renders a 1920×1080 candlestick chart (SMA, RSI, CMF, OBV, swing annotations) to PNG and it is sent to a multimodal model alongside the numeric stack. Images arrive from an export pipeline that hangs often enough that the code carries timeouts and exponential-backoff retries around it — src/analyzer/pattern_engine/chart_generator.py.
The Surprise Ratio
A support break that won because of a random news spike should not become a rule. Every closed trade gets a surprise score:
Surprise Ratio = |Realized P&L − Expected P&L| / |Expected P&L|
Anything above 1.5 is tagged ⚠️ high surprise in vector memory so the model discounts it later (src/trading/brain_reflection.py). The bot learns from what it understood, not from what it got lucky on.
What constrains an entry
The project prompts the model to discuss expected value, but the repository does not currently enforce a deterministic expected-value gate. Deterministic checks concern the symbol whitelist, position caps and validated stop/target values. The optional min_rr_entry setting is currently 0.0, so this page does not present it as an active entry gate.
What is not in here
- No Kelly criterion. An earlier version of this page claimed Kelly-sized positions. There is no Kelly code in the repository. Position size is the model's proposal, clamped to a 10% of capital cap, with 1% / 2% / 3% fallbacks by conviction level.
- No magic win rate. I have no sustained profitable period to show, so I do not quote one.
- No backtest-to-live claim. Simulated fills have no slippage, no partial fills and no liquidity limits. Paper numbers are not live numbers.

4. Honest status — September 2026
- Trading: simulated capital only (a 10,000 USDC paper book). No real funds are involved anywhere in this project.
- Tests: 2,265 collected, 2,247 passing, 17 skipped, 1 failing. The failure is the browser test that drives a live dashboard, run without a dashboard listening. python -m pytest tests -q, measured 15 October 2026.
- Executor: implemented as a separate service and wired to an exchange testnet (ENABLE_TESTNET=true, sandbox endpoints). It has placed test orders and journals their verdicts; live trading with real money is not enabled.
- Profitability: unproven. Development has had losing stretches and the code comments admit it. If that ever changes, this page changes with it.
- Source: the whole thing is at github.com/qrak/LLM_trader. Read the code before you believe a word of this page.

5. Quick start
git clone https://github.com/qrak/LLM_trader.git && cd LLM_trader
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt -c constraints.txt
cp keys.env.example keys.env # add GOOGLE_STUDIO_API_KEY, DEEPSEEK_API_KEY or OPENROUTER_API_KEY
python start.py # dashboard at http://localhost:8000
Paper trading is the default. The executor only sees decisions when you enable it — and it defaults to testnet.

6. Errata — what this page used to claim
Kept visible on purpose, because a page that silently edits its own history is worth less than one that shows its corrections:
- "Kelly Criterion position sizing" — removed. No Kelly code exists in the repo.
- "a hard expected-value or 1.5 R/R gate rejects the signal" — removed. The current code does not enforce an expected-value gate, and min_rr_entry = 0.0.
- "how the system earns real money" — removed. The executor runs against an exchange testnet, and no real capital is at stake.
- "1,270 automated tests" (August) → 1,549 (September) → 2,265 today. The number moves with the code, so it is now generated from a test run, not typed from memory.
- "97 Numba-compiled functions" (September) → 79 today: unused indicator functions were deleted in October, so the figure above is now printed from grep -rhoE "@njit" src/indicators | wc -l.
- Chart vision and vector memory were previously dated February–April 2026. The code says 22 Dec 2025 and 16 May 2026 — the timeline above is the one that matches git log.


==============================================================================
## Articles
URL: https://qrak.org/articles/
==============================================================================

Articles · updated September 2026
Articles
Deep dives into how the system actually works — written by the developer, grounded in the code, corrected in public when the code changes.
Latest
How the bot reads charts: from candles to conviction
The pipeline from raw market data to a reasoned decision — market history, a 50-level order book, Numba-compiled indicators, a 1920×1080 chart image, and deterministic risk limits before an order is sent.

Vector memory: how an LLM trader remembers its mistakes
Closed trades become 768-dimensional vectors in ChromaDB. Before each decision the bot reviews its own history — 3 nearest setups, 20-trade statistics, 5 recent rejections — and a math check separates luck from skill.

From paper to a live executor: why order placement is a separate service
Reasoning and order execution are deliberately decoupled. The seven checks every decision passes, the verdict journal that closes the loop — and the honest state of the live path: testnet only, reconciliation still the weak link.

The full development story (December 2025 – September 2026)
The engineering history with real commit dates, the mathematics behind the gates, an honest status report, and a list of the claims this site got wrong and had to fix.

See the system in action: the live dashboard streams every decision, prompt and reasoning step in real time.
Live dashboard ↗GitHub ↗


==============================================================================
## How the bot reads charts
URL: https://qrak.org/articles/chart-vision/
==============================================================================

Article · first published August 2026 · updated October 2026
How the Bot Reads Charts: From Candles to Conviction
What actually happens inside a 4-hour analysis cycle — from raw exchange data to a reasoned decision with stop-loss and take-profit levels.
The input: more than candles
Most trading bots reduce the market to a handful of indicator values. Semantic Signal starts wider. Every cycle, CCXT pulls 999 candles, a 50-level order book, the funding rate, 24-hour volume and the last 500 trades from the exchange.
The order book matters because it shows where counterparties are actually sitting: bid/ask depth by level, imbalance, spread. That is real market microstructure — information a line chart cannot carry.

79 Numba-compiled functions, microseconds each
The indicator engine is NumPy plus Numba with @njit(cache=True): each function compiles to machine code on first call and caches the result. src/indicators/ holds 79 of them (116 across the whole src/ tree) — EMA, ADX, Supertrend, Ichimoku, Parabolic SAR, CMF, OBV, RSI, custom support/resistance and volatility work — with zero external technical-analysis dependencies.
That matters for the next step: the model receives a numeric stack that was computed deterministically and can be cross-checked line by line, instead of a black-box library's output.

The chart image: seeing like a human trader
Plotly renders a 1920×1080 candlestick chart with SMA, RSI, CMF and OBV panels plus swing-point annotations. That PNG is sent to the multimodal model alongside the raw indicator values.
Why an image at all? Because geometry carries information: the shape of a wick, a volume spike at support, a wedge that is about to break. A human trader sees these at a glance and struggles to express them as floats. The model reads both channels — picture and numbers — and every numeric claim it makes is checked against the computed values. Nothing is taken on faith.
One honest engineering note: Plotly's image export (Kaleido) hangs often enough that the exporter runs in a thread with a hard timeout and exponential-backoff retries. It is in the repo, not hidden.

Fresh context: news and community sentiment
Before reasoning, the cycle ingests up to 5 articles from live RSS feeds (CoinDesk, CoinTelegraph, Decrypt, CryptoSlate) — optionally enriched with the full article body via Crawl4AI — plus Reddit community sentiment from public Atom feeds. On-chain fundamentals come from CoinGecko and DefiLlama, and the mood index from Alternative.me's Fear & Greed. No paid API keys are involved.
X/Twitter is not used: without paid authentication it is not reliably scrapable, so the bot runs on Reddit + RSS rather than pretending otherwise.

The debate: bull vs bear
The multimodal model argues the bull case, then the bear case, then evaluates the trade against the bot's own closed-trade history:
EV = (Win Rate × Average Win) − ((1 − Win Rate) × Average Loss) − Fees
That expected-value calculation lives in the prompt, not in a deterministic gate: the repository does not currently reject a signal on arithmetic alone. What is deterministic is narrower — the symbol whitelist, the position-size cap and the validation of stop/target values — plus one shared R/R floor policy that combines the configured min_rr_entry (currently 0.0, so no fixed 1.5 floor) with the brain's own borderline R/R, so the number shown to the model is the number the executor enforces.

The falsification check
Before a signal is accepted, the model has to write an explicit price invalidation trigger: the exact condition under which the trade is wrong. Like the expected-value discussion, that step lives in the prompt rather than in a deterministic gate; the checks the code enforces stay where they can be tested — symbol, position cap and validated stop/target levels.
The final output is a decision with reasoning, risk parameters and stop-loss/take-profit levels — logged to the audit trail and visible on the live dashboard. Stops are ATR-scaled rather than fixed percentages, and exits poll live prices every 15 minutes in hard mode.

Watch a real cycle end-to-end — the dashboard streams every prompt and decision.
Live dashboard ↗Next: vector memory →
Risk notice: This is an experimental open-source project, not financial advice. It trades simulated capital by default; results are not live trading results. Trading crypto carries substantial risk. See the full risk disclaimer.


==============================================================================
## Vector memory
URL: https://qrak.org/articles/vector-memory/
==============================================================================

Article · first published August 2026 · updated September 2026
Vector memory: how an LLM trader remembers its mistakes
This project stores closed-trade experiences in semantic memory and retrieves the most relevant history before acting.
The problem with stateless bots
An LLM without memory treats every decision as if it were the first one ever made. It does not know that it bought the same breakdown pattern twice before — and lost both times. The first version of this project (December 2025) was exactly that: a stateless prompt pipeline producing confident, articulate, consistently wrong decisions.
The fix was not a better model. It was architecture: give the system a brain that actually remembers.

Every closed trade becomes a vector
When a trade closes, its full context and outcome are embedded with BAAI/bge-base-en-v1.5 — 768 dimensions — and stored in ChromaDB. Three collections carry the memory:
- trading_experiences — closed-trade experiences with their context, outcome and P&L;
- semantic_rules — rules the reflection engine has written from results, in plain language;
- system_constraints_rejections — signals that were refused, and the reason.
Confidence statistics are not a fourth collection: they are computed on demand from the same embeddings (compute_confidence_stats), which keeps one source of truth for "how am I actually doing?".

Retrieval: "have I seen this before?"
Before each decision the brain assembles a context it can reason from:
- 3 most similar past trades — retrieved by vector similarity (over-fetched, then re-scored 70% similarity / 30% recency), each labelled with a match breakdown;
- win-rate statistics computed over the 20 nearest trades in the current market context;
- 5 most recent rejected signals — so the bot remembers what it refused and why;
- 3 learned rules that match the current regime (trend + ADX + volatility label).
If the sample is too thin the prompt says so, in capitals: "⚠️ LIMITED DATA: treat these as ANECDOTES, not as an established pattern". A bot that pretends two trades are a track record is worse than one with no memory at all.

The Surprise Ratio: separating luck from skill
Not all outcomes are equally informative. A support breach that won because of a random news spike teaches the wrong lesson. Every trade therefore gets a surprise score:
Surprise Ratio = |Realized P&L − Expected P&L| / |Expected P&L|
Anything above 1.5 is tagged ⚠️ high surprise in vector memory, so the model discounts it in later cycles. The bot learns from what it understood, not from what it got lucky on.

The reflection engine
Periodically a reflection pass reviews recent outcomes and synthesises new rules from what worked and what did not. The rules are semantic — natural language, embedded, retrieved when conditions match — and they are typed: anti_pattern (things to avoid), corrective (adjustments) and best practice. A matched anti-pattern forces the model to state the conflict and lower its confidence instead of quietly ignoring it.
A missed +EV opportunity is treated as mathematically identical to a realized loss (it is written into the prompt that way), so the loop stays honest about omissions too: act → embed the outcome → retrieve the lesson → act differently.

The dashboard shows the memory bank in action — retrievals, rules and rejections behind every decision.
Live dashboard ↗Next: the executor →
Risk notice: This is an experimental open-source project, not financial advice. It trades simulated capital by default; results are not live trading results. Trading crypto carries substantial risk. See the full risk disclaimer.


==============================================================================
## From paper to a live executor
URL: https://qrak.org/articles/executor-separation/
==============================================================================

Article · first published August 2026 · updated September 2026
From paper to a live executor: why order placement is a separate service
The engine thinks. The executor acts. Keeping those apart is the difference between a research prototype and something you would trust near a real exchange.
Two very different jobs
Reasoning and execution have opposite failure modes. Reasoning is slow, deliberate and benefits from context. Execution is fast, unforgiving and benefits from discipline.
Semantic Signal splits them: the engine produces an atomic JSON decision — symbol, side, size, stop-loss, take-profit, reasoning. A separate service, llm_trader_executor, does everything on the exchange side: CCXT order placement, leverage, exchange-side stops, and a JSONL verdict journal that answers the only question that matters — what actually happened to this order?

The guard chain in the executor
Every decision is checked in order before a single order can leave the process (src/safety.py):
- Duplicate detection — a content hash of the decision, not a timestamp, persisted to disk so a bot restart cannot re-execute the same trade;
- Actionable signal — anything that is not a known entry, close or update is dropped;
- Confidence floor — entries below the configured minimum confidence are blocked, while exits and stop updates are deliberately exempt (you do not want a low-confidence signal keeping you in a losing trade);
- Quantity sanity — entries need a positive size;
- Leverage cap — anything above the configured maximum is rejected;
- Order type enforcement — with market entries configured, limit orders are refused rather than quietly resized;
- Max position notional — quantity × entry price has to fit the USDC limit, re-priced from the exchange if the decision arrives without a price.
On the engine side the same decision already passed the configured pair (crypto_pair = BTC/USDC, 4h — the bot does not roam the market), the shared R/R floor policy and the position cap. A spot SELL is capped to what is actually held, so a short can never be created by accident. Stop distances come from the regime risk profile (a tight 1.5× ATR in choppy markets, a wider 2× ATR in trends) instead of a fixed percentage.
If governance or risk validation cannot decide safely, the system fails closed: no order, no exception. Soft exits trigger at candle close; hard exits poll live prices every 15 minutes.

The verdict journal
A successful HTTP call is not proof that an order exists. Instead of assuming, the executor appends one line per processed decision to a JSONL journal — executed, blocked or error, with the reason, keyed by the bot's own order_id. The engine reads that file back to find out what actually happened to its order.
Friction is reported, not swallowed: if position size gets clamped or a decision is blocked, that shows up in the journal and on the dashboard. When a state genuinely cannot be determined, the dashboard says so instead of showing a green checkmark it cannot back up.

Where this actually stands (September 2026)
No overselling:
- The executor runs against an exchange testnet (ENABLE_TESTNET=true, sandbox endpoints). It has placed test orders — the verdict journal has entries — and it has never touched real funds.
- It was last exercised in August 2026. Since then the work went into the brain, the tests and the R/R policy, so the live path is the least-recently-certified part of the system.
- The part I trust least is reconciliation: proving that what the exchange holds matches what the journal claims. That is exactly what has to be boring and reliable before any real capital is considered — and it is not there yet.
- The executor is a separate local service and is not open-sourced yet; the engine is.
Capital stays simulated until the pipeline proves itself over a sustained period. That is a deliberate decision, not a limitation to hide: demo and live are different worlds, and a system should earn live trading the way it earns everything else — by surviving its own history.

The dashboard shows live position state and the audit trail behind every decision.
Live dashboard ↗GitHub ↗
Risk notice: This is an experimental open-source project, not financial advice. Real-money trading is not enabled; everything you see runs on simulated capital or an exchange testnet. Trading crypto carries substantial risk. See the full risk disclaimer.


==============================================================================
## About the developer
URL: https://qrak.org/about/
==============================================================================

About
About the developer
Self-taught backend developer. AI/LLM specialist. Building autonomous systems after hours in Wrocław, Poland.
Who I am
I'm Piotr Kurnicki (@qrak) — a self-taught backend developer with deep AI/LLM experience. I work in a backend/AI role, and I build autonomous AI systems on my own time. My strength is depth rather than breadth: every line of this codebase was written, tested and understood by me.
Before the warehouse I worked with enterprise SAP environments at BSH Sprzęt Gospodarstwa Domowego, where I learned how large, mission-critical systems are structured — and what happens when they are built carelessly.

What I'm building now
Semantic Signal is an open-source, vision-capable AI trading agent: it reads candlestick charts as images, keeps semantic memory of closed-trade experiences, and uses a Bull/Bear reasoning prompt alongside deterministic risk limits before acting.
Right now I'm hardening the trade executor — the separate service that carries the system from simulated capital towards real exchange orders, under the same guard chain and with a verdict journal that confirms what happened to every order. Capital stays simulated until that path proves itself; today it runs against an exchange testnet, and the site says so instead of implying otherwise.
More on the project: the full development history.

What I actually work on (repositories)
- qrak/LLM_trader — the main project, and the one this site documents: the reasoning engine, the Numba indicator library, the vector memory, the dashboard and this website. Started December 2025, still active.
- qrak/ti_numba — high-performance technical indicators built on Numba JIT, extracted as a standalone library. This is the indicator work the bot runs on.
- qrak/DiscordCryptoAnalyzer — the earlier Discord bot that analysed crypto markets and posted to a server. The precursor to the current project; less maintained, kept public for the history.
- Everything else on my GitHub is older experiments and tools, and I would rather say that than pad the list.

How I work
- Tests before claims. The suite is at 2,265 tests (2,247 passing, 17 skipped, 1 failing without a live dashboard) and runs in about two minutes — python -m pytest tests -q. Numbers on this site come from that run, not from memory.
- A changelog with the ugly parts in it. Decisions, reversals and the "this aged badly" notes are in the public CHANGELOG.md, including a brain-learning reset after a losing streak.
- Corrections in public. When the site claims something the code no longer does, the page changes and the old claim stays visible in the story's errata section.

Where I am now
I work in a backend/AI role; Semantic Signal is what I build on my own time, as an open-source portfolio project rather than a product pitch.
No university degree — the portfolio is the argument: a repo with 2,265 tests you can run yourself, a live dashboard you can inspect right now, and a codebase whose history is fully documented.

Contact
Email: contact@qrak.org · GitHub: @qrak · Discord: community server


==============================================================================
## Contact
URL: https://qrak.org/contact/
==============================================================================

Contact
Contact
Questions about the project, the code, or the development process — I read everything.
Email
The fastest way to reach me: contact@qrak.org. I typically reply within 1–2 business days.

Community & Code
- GitHub: github.com/qrak — the full source lives in qrak/LLM_trader
- Discord: join the community server — build questions, bug reports, feature ideas
- Live dashboard: semanticsignal.qrak.org — watch the bot's decisions in real time

Support the Project
This is an open-source project built in spare time. If it's useful to you, you can buy me a coffee.

Business / Collaboration
For collaboration, sponsorship, or employment inquiries, please use contact@qrak.org with a clear subject line. I'm open to backend/AI engineering opportunities in Wrocław or remote.


==============================================================================
## Risk disclaimer
URL: https://qrak.org/disclaimer/
==============================================================================

Risk Disclaimer · Last updated: September 19, 2026
Risk Disclaimer
Please read this before acting on anything shown on this site.
Not Financial Advice
Semantic Signal is an experimental, open-source software project created for engineering and educational purposes. Nothing on this website — including the project description, the code, the dashboard, or any articles — constitutes financial advice, investment advice, or a solicitation to buy or sell any asset.

This Is Not a Money Machine
The system is an LLM reasoning experiment. It is not guaranteed to be profitable, and it can and will lose money. It has lost money on paper during development (the changelog documents a brain-learning reset after a losing streak, and the development history discusses it openly). Real-money execution is not enabled: the pipeline trades simulated capital by default, and the separate executor service runs against an exchange testnet (sandbox) — no real funds are at stake anywhere in this project. Live trading stays disabled until the system proves itself over a sustained period.

Paper Results ≠ Live Results
Results shown on the dashboard are simulated (paper) results. Paper trading does not involve real order execution: no slippage, no partial fills, no liquidity constraints, no exchange outages. Historical or simulated performance is not a reliable indicator of future results.

Trading Risk
Trading cryptocurrencies carries substantial risk, including the loss of your entire capital. Markets are volatile and can move against you faster than any automated system can react. Never trade money you cannot afford to lose, and never rely on an automated system without understanding its logic.

No Fiduciary Relationship
Use of this site or the software creates no advisory, fiduciary, or professional relationship with the developer. You are solely responsible for your own trading decisions.


==============================================================================
## Privacy policy
URL: https://qrak.org/privacy-policy/
==============================================================================

Privacy Policy · Last updated: September 19, 2026
Privacy Policy
This policy applies to qrak.org and all pages under this domain.
1. Who Operates This Site
This site is operated by Piotr Kurnicki (@qrak), Wrocław, Poland. Contact: contact@qrak.org.

2. Data We Collect
This site is a static, read-only website. It has no user accounts, no forms, and no newsletter. We do not directly collect, store, or process any personal data from visitors.
Third-party services used by this site may process technical data automatically:
- Cloudflare (CDN, DNS, security) — processes IP addresses and request metadata as part of standard web delivery.
- Google Fonts — loads fonts from Google servers; Google's privacy policy applies to that request.
- Google AdSense — if/when ads are displayed, Google and its partners may use cookies or device identifiers to serve and measure ads. See section 4.

3. Cookies
This site does not set first-party tracking cookies. A small cookie-consent preference is stored in your browser's local storage when you accept or decline the cookie notice.
Third-party services (Cloudflare, Google AdSense) may set their own cookies as described in their privacy policies. You can control or delete cookies through your browser settings at any time.

4. Advertising (Google AdSense)
This site may display ads served by Google AdSense. When ads are displayed:
- Google, as a third-party vendor, uses cookies (including the DoubleClick DART cookie) to serve ads based on your visits to this and other websites.
- Google's use of advertising cookies enables it and its partners to serve ads based on your prior visits to this site and/or other sites on the internet.
- You can opt out of personalized advertising by visiting Google Ads Settings. You can also opt out of third-party vendors' cookies via www.aboutads.info.
Current state: no advertising script is loaded on this site today. This section exists because AdSense is planned; if ads ever go live they will be gated behind the cookie-consent banner, and this page will say so.

5. Your GDPR Rights
If you are located in the European Economic Area (EEA) or the UK, you have the right to:
- Access, rectify, or erase personal data concerning you;
- Restrict or object to processing;
- Data portability;
- Withdraw consent at any time;
- Lodge a complaint with your local supervisory authority (in Poland: UODO).
Because this site collects no personal data directly, most of these rights are already satisfied by design. For any privacy question, contact contact@qrak.org.

6. Changes to This Policy
This policy may be updated as the site evolves. The "Last updated" date at the top of this page reflects the current version.