Release notes

NoahAI Labs service structure and operating policy change log

v3.9.0.7 Source Candidate 1 — per-user venue entitlement, AI Custom validation, and public KPI (2026-08-05)

Affiliate venues require operator-verified per-user UID attribution.
AI Custom connects knowledge structure, validation, approval, optional execution, and review as one core technology inside the wider NoahAI financial OS.
The company site explains vision, philosophy, technology, and operating evidence; enrollment and plan conversion belong to DALTrading.
The public snapshot is limited to technology operating events, processing reliability, AI inference, and learning-data records; user, transaction, venue, and revenue analytics remain internal BI.

1,336 passed, 6 skipped, 0 failed. The public Windows installer remains v3.9.0.5 Fix Patch 1; v3.9.0.7 awaits Windows, daltrading, affiliate UID, and user-environment E2E.

v3.9.0.5 Fix Patch 5 working source — refresh resilience and confirmed-fill ledger (2026-08-01)

Position and balance refresh recovers independently of tab changes.
Confirmed Binance, CCXT, and Bithumb LIVE fills feed the shared ledger, statistics, and AI reports.
PAPER positions, balances, and PnL are visible and explicitly separated from LIVE.
Additive database migration preserves open rows and venue identifiers; database preparation failure blocks trading initialization.
LEARNING/PAPER/LIVE and global/per-broker permissions use one AND authorization boundary.

The public Windows installer is v3.9.0.5 Fix Patch 1. Fix Patch 5 working source has 1,298 passed, 6 skipped, and 0 failed, but remains undistributed until a new Windows build, install/update recovery, and user-environment E2E pass.

v3.9.0.4 release candidate — AI Custom roles and shared execution contract (2026-07-30)

General mode: user-pinned and NoahAI-selected symbols are analyzed, then AI Custom confirms each base-AI candidate exactly once.
Advanced mode: pinned symbols and StrategyUniversePolicy form the universe; the original strategy independently determines direction, TP/SL, and exits without base-AI agreement.
Strategy integrity: NoahAI does not silently narrow a strategy stop. Risk conflicts reduce quantity or block the order with requested, allowed, and reason fields.
Universe and regime: each venue uses its own supported market and data; regime scope is explicitly market, symbol, both, or none.
Multi-venue execution: users choose parallel, total-risk split, or priority-one. Valid same-symbol executions share one opportunity-level exposure and result record.
Execution modes: LEARNING runs the complete decision and evidence pipeline but blocks external state changes and new orders. PAPER and LIVE share the same candidate and risk contract.
Explainability: base-AI result, AI Custom role and version, candidate source, risk budget, dynamic exit, venue protection order, and final reason remain distinct.

Full source regression: 1,219 passed, 6 skipped, 0 failed. At that time, Windows v3.9.0.2 was the user distribution. v3.9.0.4 was not separately distributed and was later incorporated into v3.9.0.5. See the v3.9.0.4 public execution and risk contract.

v3.9.0.3 release candidate — AI Custom advanced mode, multi-AI, and update safety (2026-07-28)

AI Custom advanced mode: configurable EMA, SMA, RSI, and ATR periods from 2–500; 1-minute to daily timeframes; AND/OR entry and full-exit rules; requested-versus-calculated value comparison.
Task-specific multi-AI: assign OpenAI, DeepSeek, Claude, and Gemini by {provider, model} while migrating legacy OpenAI settings automatically.
Independent transcription: strategy analysis and OpenAI transcription use separate profiles; real API checks cover text, JSON, usage, errors, and optional audio.
Model lifecycle: recommended, account-confirmed, preview, deprecated, and retired states are separated. Kimi K3 and K2.6 remain assistant trials until real-key E2E.
Stability and order boundaries: hidden-tab polling is paused, Binance UTC handling is normalized, and visible/learning sources are separated from explicit live-order targets.
Safer updates: open positions, open orders, and in-flight submissions defer updates; hash, Windows signature, DB flush, restart health, and previous-EXE recovery are checked.

Source regression: 1,135 passed, 6 skipped, 0 failed. At that time, Windows v3.9.0.2 was the user distribution. This v3.9.0.3 candidate was not separately distributed and was superseded by later versions. AlphaArena multi-engine live connectivity, TradingView webhooks, partial take-profit, trailing stop, re-entry, and a user-indicator sandbox remain follow-up work.

v3.9.0.2 — AI Custom XAI, market-regime guidance, and safer assistant changes (2026-07-26)

Source-grounded guidance: extracts explicitly stated uptrend, downtrend, range, high-volatility, and low-volatility applicability while keeping exclusion language separate.
Explainability: shows source evidence, strategy role, scope, regime, priority, runtime values, and pre-approval inactive status.
Mandatory confirmation: legacy auto-apply values are migrated to user confirmation; chat apply and final confirmation are both required.
Context gates: risk-increasing changes are blocked when market, recent performance, or position context is missing, when performance is negative, or when positions are open.
Fresh-state validation: context is checked when a proposal is shown, when Apply is clicked, and immediately before saving.

Source regression: 1043 passed, 6 skipped, 0 failed. Windows v3.9.0.2 was the user distribution at that point; the changes above were cumulatively included in later versions.

v3.9.0.1 — Position KPI, AI Custom, and Financial Intelligence (2026-07-24)

What changed

Position KPI: order execution is separated from entry, partial close, and final close; only validated time differences feed holding-time metrics.
Actual-execution metrics: mock, demo, paper, and test modes are excluded; holding time remains collecting until valid close events arrive.
AI Custom: leverage is calculated from loss budget, stop distance, margin cap, and user leverage cap; users choose regime-exit behavior.
Financial Intelligence: market, sector, event, news, fundamentals, valuation, screening, indicators, performance, and backtesting are connected in one analysis flow.
Usability: cross-platform icons, tab hierarchy, scrolling content, and in-app update guidance were aligned.

Full regression: 1030 passed, 6 skipped, 0 failed. The public snapshot is limited to technology operating events, processing reliability, AI inference, and learning-data records; user, trading, and performance BI remains internal.

v3.8.9.29 — Multi-exchange and AI custom strategy hardening with approval-gated operations (2026-07-19)

Why the structure changed

While v3.8.9.28 focused on policy/consent/deployment consistency, v3.8.9.29 locks the runtime layer: strategy safety, exchange-context consistency, and approval-gated custom strategy operations.

Structural changes

Operational AI custom flow: text/Pine/PDF/OCR/video/YouTube/TradingView inputs are converted into executable rules, with pre-approval live execution blocked.
State-machine safety: create → review → approve → execution verification → activate → rollback path fixed to prevent bypass routes.
Exchange consistency: exchange-scoped context and per-exchange PnL thresholds reduce cross-path ambiguity.
Cold-start protection: minimum-unit position and leverage limits applied for new users by default.
Operator UX hardening: clearer exchange stats/status, start-stop sync, and safer shutdown path.

Verification and operating principle

Regression baseline recorded 967 passed, 6 skipped, 0 failed. The principle is not feature inflation but zero unapproved execution, zero guardrail bypass, and auditable replay.

v3.8.9.27 — Update path/progress integrity and exchange diagnosis UX hardening (2026-07-06)

Why the structure changed

Field operations repeatedly exposed three friction points: ambiguous update file locations, weak progress visibility, and high user effort when exchange verification failed. The release aligns these into one user-facing flow: path policy + progress events + cause-specific guidance.

Structural changes

Update path policy: install-location-first cache path with LocalAppData/TEMP fallback.
Progress visibility: start/progress(%)/received-size(MB)/completed-failed states exposed in settings update tab.
Completion traceability: downloaded file path, install target EXE, and cache path shown immediately.
Cache accumulation control: stale auto_updater folders/scripts pruned automatically (keep latest two).
Exchange verification UX: Bitget/Bybit/OKX failures mapped to cause-specific actions (IP/permission/passphrase/account-mode).

Verification & operating principle

Auto-update regression was confirmed at 5 passed. The principle is to optimize not for feature count, but for user-actionable operational clarity.

Purpose of these notes

These release notes are not a list of feature additions or improvements. Their purpose is to record service structure changes and operating policy changes.

For each version, we focus less on what changed in isolation and more on why the structure was changed and which operating principles were applied.

v3.8.9.20 — AI Analyst UX consolidation and top-screen enhancement (2026-06-05)

Why the structure changed

In production usage, the Quick Actions "AI Analysis Panel" and the top "AI Analyst" menu were functionally overlapping. User feedback indicated low perceived value from opening/closing a separate drawer panel. The structure was simplified to one primary entry point via the top AI Analyst menu.

Structural changes

Removed duplicate path: Quick Actions AI panel button and right drawer open/close/resize flow removed.
Single entry principle: AI analysis flow is now centered on the top AI Analyst service screen.
Top-screen upgrade: Added snapshot cards (closed trades, win rate, cumulative PnL, risk guard).
Faster navigation: Added direct actions to summary report tab, scenario check tab, and AI assistant.
Inline previews: Added summary/scenario previews with refresh action.

Verification & operating principle

Regression validation recorded 99 passed. The operating principle for this release is not "more UI", but less overlap and clearer user flow.

Operating runbook release — Kiwoom OpenAPI+ Windows diagnostic procedure (2026-05-11)

Why the structure changed

During conditional beta validation for ETF/stock live connectivity, failure causes in Kiwoom OpenAPI+ varied by environment. To reduce response variance and improve reproducibility, a standardized Windows diagnostic runbook was formalized.

Structural changes

Standard execution flow: Fixed sequence in PowerShell: activate venv → run verification script.
Root-cause separation keys: Use control_ok, has_OnReceiveTrData, python_bits, os to separate ActiveX/event/account issues.
Required evidence package: Full console output, JSON Step 0 block, and API-connect FAIL detail are mandatory.

Verification support metrics

As a script regression baseline in the Mac development environment, test status was 13 passed, 4 skipped, 60 deselected.

Operating principle

In broker live-connect validation, success/failure alone is not enough. Reproducible root-cause separation is treated as the primary control objective.

v3.8.9.19 — Dashboard tab visualization upgrade & Korean market integration (2026-05-06)

Why the structure changed

The asset integration, life finance, and AI analyst service tabs were providing only text-list level information, making it difficult for users to gain meaningful judgment insights. Visualization engines were directly implemented per tab, and the stock service market trend data was converted to Korean market standards.

Structural changes

1. Asset Allocation Diagnosis Tab

Weighted bar chart: Color-coded bars for crypto/stock/other asset classes (tkinter Canvas)
HHI concentration meter: 0–100 gauge bar with 3-zone coloring (green/orange/red)
Correlation heatmap: 2×2 asset class correlation — low correlation=green, high=red
Rebalancing suggestion cards: AssetCorrelationService-based high-correlation warnings

2. Scenario Check Tab — DB Backtest Engine

Real trade simulation: Latest 200 records from DB trade_log for 3-strategy comparison
Strategies: Conservative (×0.7) / Current policy / Aggressive (×1.3)
Metrics: Win rate, cumulative PnL, max drawdown, per-trade average

3. Risk Briefing Tab — Loss Simulation

Loss estimation table: Per-asset-class loss calculation for -5%/-10%/-20%/-30%/-50% market drops
Risk cards: Concentration / correlation / cumulative PnL risk level cards

4. Security Alert Tab (NEW) — Life Finance

Auto anomaly detection: DB trade_log → fraud_detection_service → pattern detection
Risk score: low/medium/high/critical 4-level rating
Self-diagnosis checklist: 5-item voice phishing / smishing checklist

5. Tax Calculation Tab (NEW) — Life Finance

Year-end tax: Salary/card/medical/education/donation inputs → tax payable / effective rate
Financial investment tax: Stock gain-based calculation (KRW 2.5M deduction)
Tax-saving account comparison: ISA / pension savings / IRP benefit comparison
Optimization tips: 5 personalized tax-saving tips auto-generated

6. Korean stock market trend localization

Naver Finance public API: No API key required, real-time KOSPI/KOSDAQ index
Stocks: Samsung Electronics / SK Hynix / NAVER / Kakao / Hyundai Motor / LG Energy Solution
Sectors: IT/semiconductor / Internet/platform / Auto / Secondary battery

Operating principle

A judgment infrastructure does not end at showing numbers.Users must be able to immediately verify "how diversified is my portfolio", "what if the market drops 20%", and "are there anomaly patterns in my trades". This release marks the transition from text guidance to visualization and calculation engines.

Deployment verification

Menu regression: 51 passed (0 failed) · Syntax errors: 0 · Files changed: 5 · New functions: 12

v3.8.9.11 — TP/SL -2021 root fix and multi-asset platform expansion (2026-01-25)

Why the structure changed

On low-priced altcoins such as GALA and JASMY, TP (Take Profit) orders could fail. The error was -2021: Order would immediately trigger—not a simple bug but a structural issue with price precision handling and TP direction validation.

At the same time, work progressed to extend the financial AI operating engine—validated in live crypto—to ETFs and stocks. This is an important step toward an asset-neutral financial AI platform that is not tied to a single asset class.

Operational structure changes

1. Root fix for TP/SL -2021

Key name compatibility: Support both price_precision and pricePrecision. Previously, key mismatch caused price precision to stay fixed at 2, so low-priced coins could not be priced correctly.
Low-price coin detection and precision: Automatically detect coins in roughly the 0.001–0.02 price range and apply appropriate precision so TP/SL orders execute correctly.
TP direction validation: For LONG, TP must be above the current price; for SHORT, TP must be below. Previously this check was missing, so TP orders could be created in the wrong direction.

2. Financial AI platform expansion (multi-asset)

StockExchange interface: Added trading/exchanges/interfaces/stock_exchange.py so securities and crypto exchanges can be handled behind the same interface—a core design principle for an asset-neutral engine.
Domestic broker adapter skeleton: Added trading/exchanges/adapters/kiwoom_stock_adapter.py as the base structure to integrate broker APIs into the financial AI system.
Dashboard: Stock/securities tabs and per-broker sub-tabs so users can manage crypto and stocks in one interface.

Operating principles

The same safeguards must work for every asset class. Whether low-priced alts or high-priced coins, crypto or stocks, safeguards such as TP/SL must behave consistently—not differently by precision or asset type.

Through asset-neutral design, adding a new asset class should reuse existing safeguards and operating structure. The ETF/stock expansion is the first live application of this principle.

v3.8.9.9 — Full Binance Algo Order API implementation (2025-12-27)

Why the structure changed

After Binance policy changes (2025-12-09), conditional orders (TP/SL) were required to go through the Algo Service. This is not a simple feature add—it is a redesign of operating structure in response to exchange API policy.

Operational structure changes

Unified signing rules: Query-string-based signing so all parameters are handled consistently.
Standardized price precision: Prefer tickSize, reduce floating-point error for stability.
Simpler conditional-order branching: Removed complex logic (roughly 160 lines → 55) for maintainability.
Unified response shape: Normalize Algo Order responses to match ordinary orders for backward compatibility.

Operating principles

When exchange policy changes, we evolve the structure to meet new requirements while keeping compatibility with existing code. Design so all modules pick up changes automatically and minimize follow-up edits.

v3.8.9.7 — Binance API compliance and configuration structure (2025-01-26)

Why the structure changed

Align fully with official Binance API rules and move hard-coded settings to structures users can control.

Operational structure changes

API compliance: When closePosition=True, omit quantity; do not use reduceOnly and closePosition together.
Structured config: Backup TP/SL settings moved to settings.json so the AI can adjust automatically to market conditions.
Path auto-detection: Remove hard-coded paths; detect correct paths even in packaged environments.
Clear TP/SL roles: Separate real-time monitoring (primary) from backup TP/SL (insurance).

Operating principles

Exchange API rules are non-negotiable. User-controllable settings live in files so the AI can adjust them dynamically.

v3.8.9.5 — Stronger TP/SL validation and atomicity (2025-01-26)

Why the structure changed

Trades could proceed even when TP/SL validation failed. We strengthened safety with atomicity guarantees.

Operational structure changes

Mandatory TP/SL: On validation failure, close the position immediately and treat the trade as failed.
Atomicity: If either TP or SL fails, roll back both; keep atomicity on reset as well.
Unified validation: Use the same order-type filtering everywhere.
Modularization prep: Concentrate TP/SL responsibility in TpSlManager for reuse.

Operating principles

Safeguards (TP/SL) are mandatory. If they cannot be set, the trade does not run. Atomicity prevents partial failure states.

v3.8.9.3 — Unified balances and trade statistics (2025-11-29)

Why the structure changed

When running multiple exchanges, we improved balance and trade statistics so everything can be managed in a unified way.

Operational structure changes

Unified balance totals: Sum USDT/KRW balances across exchanges and display.
Unified trade stats: Prefer exchange_trade_stats, fall back to trade_log for accuracy.
TP/SL close logging: Update trade_log on TP/SL closes for better stats.
Fee-aware closes: Minimum profit threshold after fees to ensure fees are covered.

Operating principles

Multi-exchange operation requires a unified view—not only per-exchange detail but whole-portfolio performance at a glance.

v3.8.9.2 — Smart progressive learning (2025-11-29)

Why the structure changed

To apply appropriate conditions for both new and existing users, we introduced a progressive learning system.

Operational structure changes

History-based thresholds: From first-ever trade (0) through normal trading (11+), thresholds relax in stages.
First trade per coin: Relaxed thresholds when trading a coin for the first time.
Trust AI judgment: Even weaker signals can proceed when market conditions are favorable.
Signal-strength adjustment: Auto-adjust AI confidence by signal strength.

Operating principles

Learning is progressive. Start with relaxed conditions; move to normal thresholds as history grows. We trust holistic AI judgment, not signal strength alone.

v3.8.9 — Stronger position synchronization (2025-11-21)

Why the structure changed

Keep accurate state after app restarts and strengthen synchronization between the exchange and in-memory state.

Operational structure changes

Exchange vs memory: Fetch real positions at the start of each trading cycle.
Remove closed positions: Clean memory so position counts stay accurate.
Recover real positions: Survive app restarts with consistent state.
Stable cycles: Correct position counts normalize the trading loop.

Operating principles

In-memory state must always match the exchange. Synchronization keeps state correct after restarts or network errors.

v3.8.8.8 — Trading blocked loop and stronger settings preservation (2025-11-14)

Why the structure changed

Fix the “chicken and egg” loop where the first trade never runs, and improve structure so user settings persist reliably.

Operational structure changes

First-trade allowance: When total trade count is zero, apply relaxed conditions.
Insufficient data: Dynamic relaxation via user_signal_threshold.
Settings preservation: Recursive merge for nested dicts—two or more levels deep.
Protected keys: Explicit protection so template merges never overwrite user values.

Operating principles

Circular dependency must be solved in structure: allow the first trade so data can accumulate, and always preserve user-edited settings.

v3.8.8.6 — Alpha Arena mode (2025-11-07)

Why the structure changed

Add an LLM-based autonomous trading mode to support multiple trading strategies.

Operational structure changes

Independent mode: Alpha Arena is fully separate from the main auto-trading pipeline.
LLM autonomous trading: The AI decides and executes trades directly.
Benchmarked strategies: Apply winning algorithms validated in Alpha Arena benchmarks.
Built-in guardrails: Leverage limits, mandatory TP/SL, cooldowns, and more.

Operating principles

New modes run independently from the existing system, with appropriate guardrails per mode. Strategy depends on the mode the user selects.

v0.1 — Website service structure published (2025-12)

Service page structure

We organized NoahAI Labs’ web presence as follows:

Services (/product): Focus on currently available personal financial AI services.
Autonomous financial assistant (/product/assistant): The umbrella concept for integrated wealth tech / financial AI / autonomous assistant and the expansion vision.
Technology (/technology): Financial AI engine and operations stack.
Enterprise (/enterprise): B2B and institutional operations stack.

Why we changed the structure

Previously the site emphasized coin-centric services. NoahAI Labs aims at integrated financial judgment AI, not a single asset class.

Crypto is positioned only as the “first live-validated asset,” and we added a dedicated autonomous assistant page to make the expandable financial-AI architecture explicit.

Operating principles

We do not emphasize individual coin strategies, return figures, or short-term performance.
We center the story on judge → execute (optional) → log → review → explain (XAI).
We prohibit investment advice and guaranteed-return language.
Without technical hype, we use terms like “platform,” “engine,” and “operating structure.”

What we will record next

Future release notes will cover structural changes such as:

Asset scope expansion (crypto → securities/ETF/real estate)
Deeper risk interpretation
Broader explainability of judgments
Expanded execution scope
Operating policy changes
Responses to exchange API policy changes
Safeguard structure improvements

We do not log feature additions or performance numbers—only changes to structure and operating principles.