AI financial decision structure verified through operating evidence
NoahAI connects supported judgments, guardrails, PAPER/LIVE execution boundaries, and outcomes through operating logs, ledgers, and reports.
Partner and diligence view: judgment traces and reproducibility
What external reviews often ask for is not a single headline return but whether the context of each judgment (inputs, policy, risk, outcomes) is recorded and can be replayed and reviewed under the same conditions. NoahAI embeds this logging and linkage in supported PAPER and LIVE paths, while keeping venue readiness separate—aligned with an infrastructure stance that prioritizes operability and auditability over headline performance alone.
Why technical proof matters
Many financial AIs exist only as concepts. They show backtest results, simulation performance, or PoC demos, but a structure where every judgment is recorded and reproducible in production is rare.
NoahAI Client has completed core product validation and now operates as free and paid services. Supported judgment, block, execution-request, and outcome records are separated by account, venue, PAPER/LIVE mode, and strategy version.
Financial AI that exists only as concept
- • Only backtest results published
- • Selective performance disclosure
- • No real production logs
- • Not reproducible
NoahAI proven in production
- • Public release and venue readiness are assessed separately
- • Supported judgments, blocks, and outcomes are recorded
- • PAPER/LIVE and strategy-version attribution stay separate
- • Reproducible and verifiable structure
Production pipeline
Below is the pipeline that runs in production. Each step is logged, connected to the next, and ultimately fed back into learning data.
Market Data
Real-time market data (price, volume, volatility, order book)
Log category: [analysis] — collection time, source, indicator values
Analyzer
Technical indicators (RSI, MACD, Bollinger, etc.) and market regime analysis
Log category: [analysis] — indicator values, analysis result, signal strength
Decision
AI combines market data and personal financial context into judgment
Log category: [analysis] — reasoning, confidence, strategy, alternatives
Risk
Guardrail application and risk assessment (limits, stop conditions, conservative control)
Log category: [monitor] — guardrail applied, risk result, safety actions
Execution
Optional execution support within user settings and safety limits
Log category: [trade], [order] — order creation, execution result, slippage, fill status
Exit
Position exit (TP/SL hit, dynamic threshold, external change detection)
Log category: [exit] — exit reason, result, P&L, learning data
XAI
Full process recorded in explainable form (reasoning, execution result, risk assessment)
Log categories: [analysis], [trade], [order], [monitor], [exit] — explainable logs at every step
Learning
Recorded logs converted to learning data and reflected in policy improvement
Data: DecisionLog, ExecutionResult, XAITrace → review evidence for pattern analysis and versioned improvement candidates
Key: Each step of this pipeline does not run in isolation. Every step is logged and these logs connect to the next judgment and to learning.
Operating-log structure example
This synthetic example explains fields and linkage. It is not real user, account, order, price, or performance data.
YYYY-MM-DD HH:MM:SS | [context] venue=example_venue mode=PAPER strategy=example:v1 YYYY-MM-DD HH:MM:SS | [analysis] market_snapshot=market_snapshot_id regime=example_regime YYYY-MM-DD HH:MM:SS | [decision] action=HOLD_OR_ENTRY_CANDIDATE evidence=evidence_ref YYYY-MM-DD HH:MM:SS | [guardrail] result=ALLOW_OR_BLOCK reason=policy_reason YYYY-MM-DD HH:MM:SS | [execution] status=NOT_SENT_OR_SIMULATED_OR_CONFIRMED result=execution_result_id YYYY-MM-DD HH:MM:SS | [xai] trace=xai_trace_id decision=decision_id YYYY-MM-DD HH:MM:SS | [review] outcome=review_record_id next_change=NONE_OR_DRAFT
Log structure
- • Time-ordered: Every step recorded sequentially with timestamp
- • Categories: [analysis], [trade], [order], [monitor], [exit] for easy trace
- • Linkable: decision_id, execution_id etc. connect logs for full flow trace
- • Reproducible: Same market data and settings can reproduce the run
Log and learning data connection
Production logs are not just stored; they are converted into a standardized learning data structure and used to improve the next judgment.
Log → learning data conversion
1. DecisionLog
From [analysis], [decision]:
- decision_id, timestamp, reasoning, confidence, model_version
2. ExecutionResult
From [trade], [order]:
- execution_id, decision_id, executed_price, slippage, status
3. Result and feedback
From [exit]:
- result (P&L, TP/SL hit), feedback, pattern (success/failure)
Connection structure:
DecisionLog {
decision_id: "decision_id",
reasoning: { pattern: "example_pattern", signal_strength: "example_score" },
confidence: "example_score"
}
↓ (link)
ExecutionResult {
execution_id: "execution_id",
decision_id: "decision_id", ← link
executed_price: "example_price",
status: "SIMULATED_OR_CONFIRMED"
}
↓ (link)
ExitResult {
execution_id: "execution_id", ← link
result: "example_outcome",
feedback: { pattern: "example_class", return_rate: "example_rate" }
}
↓ (to learning data)
LearningData {
decision_history: [DecisionLog + ExecutionResult + ExitResult],
pattern: "example_class",
market_conditions: "example_regime"
}Full data structure: Data structure.
Analyst AI role
Analyst AI does not execute trades. It is an analysis layer that summarizes, compares, and explains operational results so users and operators can understand.
❌ What Analyst AI is not
- • AI that executes trades directly
- • AI that makes investment decisions for you
- • AI that guarantees returns
✔ What Analyst AI does
- • Summarize and organize operational results
- • Compare and explain patterns
- • Present reasoning in understandable form
How Analyst AI works
1. Market analysis (analyzer)
Technical indicators, regime analysis, signal generation. All analysis is logged under [analysis].
2. Pattern recognition (ai_manager)
Similarity to past patterns, regime analysis, dynamic thresholds. Pattern results feed into judgment reasoning.
3. Report generation (ai_manager)
Daily/weekly/monthly reports, reasoning summary, option comparison. Presented so users and operators can understand.
Key: Analyst AI provides input to the Decision Layer and analyzes and explains execution results—it is an analysis layer. Execution itself is in the Execution Layer; Analyst AI makes that process understandable.
Account review and the collective-learning roadmap
In the current public release, recorded logs support account-level review and safety controls. Cross-user pattern learning is not yet an operating shared-policy feature.
Decision-quality improvement review
Outcome- and risk-based improvement candidates
Outcomes, blocks, and risk-control records are evaluated to create improvement candidates. Existing policy is not changed automatically; a new version requires user approval, automated checks, and PAPER validation.
Reward design: AI optimization loop.
Failure logs included
Failed as well as successful outcomes are retained as review evidence. Findings remain separate from existing policy until a new version is approved and validated.
Pattern-level learning
Learning is by success/failure patterns, not raw P&L. Different patterns by regime (up/down/sideways) enable situation-appropriate judgment.
Collective-learning target design
Privacy
A future collective-learning layer must exclude individual trade size, account information, and exact timing.
Only anonymized patterns are used:
- Market regime (volatility, trend, volume)
- Success/failure (TP hit, SL hit, dynamic threshold)
- Risk management (guardrail, stop conditions)
Effect of collective learning
The long-term target is for validated patterns to improve shared safety policy. This layer remains disabled until consent, anonymization, revocation, authorization, and operational validation are complete.
More data → improvement:
More records can broaden review evidence and expose more failure modes. They support versioned improvement candidates and validation; they do not automatically change policy or guarantee better accuracy. The aim is a more careful and verifiable decision structure over time.
NoahAI technical differentiation
Many financial AIs have execution, explanation, and learning separated or only partly implemented. NoahAI connects all three in one pipeline that actually runs.
Execution
Optional execution support within user settings and safety limits
Every execution is logged and execution results feed into learning data.
Explain
Every judgment's reasoning recorded in explainable form
Under XAI policy, every decision process is transparent and reproducible.
Learn
Recorded logs converted to learning data and reflected in policy improvement
Execution, explanation, and learning run in one pipeline.
Key differentiators
- • Linked execution, explanation, and review evidence: Versioned IDs connect each stage.
- • Supported paths are traceable: Inputs, policy, blocks, and outcomes can be reviewed together.
- • Logs support improvement candidates: Changes remain separate drafts until approval and validation.
- • Failure and block records are included: Evidence is not limited to selected successful outcomes.
- • Collective learning with privacy as a target: account-level records support review now; future cross-user use is limited to patterns that pass consent, anonymization, revocation, and operational validation.
NoahAI is not concept—it is a structure that actually runs.
The public release records supported judgment, guardrail, PAPER/LIVE execution boundaries, and outcomes. Evidence supports account-level review and user-approved improvements; public KPIs remain dated, scoped aggregates.
Related technical docs
This page focuses on production proof. Details of each component are in the documents below.