TRADING-TOOL is a FinTech platform designed by Softech as one environment for market data, trading scenarios, explicit risk parameters, AI-assisted scoring and a trading journal. The system combines a real-time data stream with a persistent scenario model covering entry, take-profit, stop-loss, Risk:Reward and risk, then makes structured context available to the AI layer. The model is intended to support scenario review rather than replace the user or predict prices. Selected assumptions and later observations can be stored in the journal for historical process analysis. This case study describes product architecture and capabilities, not investment performance; earlier percentage-based KPIs were removed because the repository does not contain a methodology linking them reliably to the platform.
Business context and the situation before implementation
Trading products work with two very different classes of information: fast-changing market state and persistent user assumptions. When charts, feeds, notes, risk calculations and journaling are fragmented, it becomes difficult to preserve one version of a scenario and later assess whether a decision followed the user's own plan.
- Market data changes faster than persistent scenario assumptions.
- Entry, TP, SL, R:R and risk need to remain explicit so scenarios can be compared.
- AI can increase the amount of information, but without clear boundaries its output can create false certainty.
- A journal is useful only when it preserves scenario context rather than only a final result.
- Multiple asset classes need a common product model while remaining dependent on external data feeds.
- The interface must handle dense information without splitting the workflow across many tools and screens.
Before state
The starting point was a fragmented workflow: current market context in one tool, notes and scenarios in another, risk calculations elsewhere, and historical review in a journal or spreadsheet. This made it difficult to preserve consistent context from analysis through later review and provided no natural place for bounded AI decision support.
- Switching between feeds, charts, notes and calculators.
- Scenarios stored in inconsistent formats.
- No single place connecting risk parameters with decision context.
- Difficulty comparing the original plan with what was later reviewed or acted upon.
- AI without structured input would be exposed to inconsistent context.
- No shared real-time layer across product surfaces.
Goals, success criteria and constraints
Discovery focused on separating the trading workflow into real-time data, persistent scenario data and elements that require interpretation. A key decision was to treat AI as a separate layer above a structured model rather than let the model define the core scenario parameters.
Product goals
- Combine market context, scenario planning, risk review, AI and journaling in one workflow.
- Keep entry, TP, SL, R:R and risk as explicit fields in the domain model.
- Separate fast-changing live state from persistent scenario data.
- Use AI to support scenario assessment without making price-prediction claims.
- Keep the final decision and responsibility with the user.
- Store history in a form that supports later review of the user's own process.
- Prepare the architecture for additional feeds, asset classes and team workflows.
Success criteria
- A user can move from market context to a complete scenario without leaving the product.
- The scenario preserves entry, TP, SL, R:R and risk parameters as data rather than free-form text.
- The AI layer receives structured context and is presented as support rather than an oracle.
- Real-time updates do not replace persistent storage of scenarios and journal entries.
- The journal preserves context needed for later review.
- The architecture can accept additional data sources without rebuilding the entire product.
Data freshness
Market-data freshness and coverage depend on the upstream feed. The product needs to distinguish missing data, delay and valid live state.
AI uncertainty
A model can produce incorrect or overconfident interpretation, so its role is bounded to decision support rather than prediction or execution.
Financially sensitive context
Interface and case-study language must not imply guaranteed outcomes, certainty of profit or automatic investment advice.
Data-dense UX
High information density must remain readable without hiding key scenario and risk parameters.
Multiple asset classes
Forex, indices, commodities and cryptocurrencies differ in feeds and market structure while the product still needs a shared scenario model.
Live-versus-history separation
Current market state is transient while scenarios and journal entries need persistent, reproducible storage.
Analysis and product decisions
- Mapping the points where a user moves from observation to hypothesis and scenario.
- Separating deterministic parameters from AI commentary and scoring.
- Defining a shared entry / TP / SL / R:R / risk model.
- Separating live state from persistent journal data.
- Designing a data-dense dashboard that keeps context together without multiplying screens.
- Defining responsibility boundaries between feeds, backend, AI and the user.
- Preparing a modular path for additional feeds and team workflows.
Solution architecture
The architecture separates data sources, real-time distribution, scenario logic, the AI layer and the persistent journal. This prevents a changing tick or news item from overwriting historical assumptions and lets AI work with structured context rather than an uncontrolled text stream.
- 01L1 · Sources
Market data and context
External feeds provide current data for supported asset classes and context presented in the dashboard.
External feedsMarket context - 02L2 · Real-time
Ingestion and distribution
Node.js, Redis and WebSockets support fast application-state updates and distribute changes to the interface.
Node.jsRedisWebSockets - 03L3 · Domain
Scenario and risk engine
A structured model keeps entry, TP, SL, R:R and risk parameters independent from AI commentary.
TypeScriptNode.js - 04L4 · AI
Decision-support layer
AI/LLM analyses prepared context and returns scoring or commentary for user review.
AI / LLMStructured context - 05L5 · Persistence
Journal and scenario history
PostgreSQL stores persistent scenario, note and history data needed for later review.
PostgreSQL - 06L6 · Experience
Analytics dashboard
Next.js and TypeScript combine live market state, scenario, scoring and journal into one data-dense interface.
Next.jsTypeScript
Problems, decisions and implemented capabilities
Analysis was fragmented across multiple tools.
Build one decision workspace rather than another isolated widget.
The dashboard combines market context, scenario planning, risk review, AI and journaling.
The process has one context and fewer points where a scenario loses its original version.
Risk parameters could remain in notes or in the user's memory.
Keep key parameters as explicit model data.
Entry, TP, SL, R:R and risk are part of the structured scenario.
Scenario assumptions remain visible and can be preserved for later review.
Unbounded AI can appear to be a source of certain predictions.
Place AI above a structured scenario and keep the decision with the human.
The model returns decision-support scoring and commentary rather than executing an order.
The role of AI is clear: it supports review but does not guarantee market direction or outcomes.
Live market state and scenario history have different lifecycles.
Separate the real-time stream from persistent data.
WebSockets and Redis handle live updates while PostgreSQL stores journal and scenario data.
Current state can change without losing historical assumptions stored by the user.
A separate journal makes it difficult to connect observations with the original plan.
Include the journal in the same product model.
Scenarios, context and later observations can form one review history.
A user can analyse their own process without attributing guaranteed financial results to the platform.
New feeds and team workflows should not require rebuilding the entire system.
Separate data, domain, AI and experience layers.
The modular architecture prepares the product for additional integrations and surfaces.
Extensions can be designed around a stable scenario and journal model.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Next.js | Dashboard and analytics interface layer | Supports complex data-dense React surfaces while keeping product features modular. | A live dashboard still requires controlled hydration and client-side handling for streaming data. |
| TypeScript | Scenario and application-data contracts | Explicit types reduce ambiguity around entry, TP, SL, R:R, risk and UI states. | Strict contracts require maintained mappings when an upstream feed changes its data shape. |
| Node.js | Backend, integrations and real-time logic | A shared JavaScript/TypeScript layer simplifies contracts between backend and frontend. | CPU-heavy operations need isolation so they do not block paths serving live updates. |
| PostgreSQL | Persistent scenarios, journal and history | A relational model suits data that needs consistent links between scenario, context and review. | It is not a tick-by-tick store for the entire market; the live stream needs a separate retention strategy. |
| Redis | Low-latency state and real-time workload layer | Helps separate fast-changing state from persistent data stored in the relational database. | Data in this layer must not be treated as the only source of persistent user history. |
| WebSockets | Distribution of real-time updates to the dashboard | A persistent bidirectional connection suits an interface that reacts to changing context without constant polling. | Connections require reconnect logic, stale-state handling and explicit behaviour when a feed is lost. |
| AI / LLM | Scoring and interpretation of structured context | A model can synthesize multiple context elements and provide an additional perspective for user review. | Output is non-deterministic and can be wrong; it must not be presented as a guarantee, automatic advice or independent execution. |
Integrations and data flows
Market data feeds
InboundProvide current pricing and market context for supported asset classes.
Freshness, coverage and availability depend on the provider; the application should explicitly handle feed interruption or delay.
Market context / news feed
InboundAdds current context to numerical market data in the analytics layer.
External content needs timestamps and should not be treated as a standalone basis for a decision.
AI / LLM inference
Request → responseAnalyses a structured scenario and context, returning decision-support scoring or commentary.
The model can fail, return no response or produce overconfident interpretation; output requires visible limitations and user review.
WebSocket application channel
Backend ↔ clientDistributes live-state updates to the dashboard without manual interface refreshes.
Reconnect and stale-state handling matter because a dropped connection must not appear to be current market state.
AI, security and reliability
The AI layer in TRADING-TOOL is a decision-support component. It receives structured market and scenario context and can return scoring and commentary, but it does not define the user's core risk parameters, execute orders or act as a reliable predictor of future prices.
AI workflow
- Retrieve current context from the data layer.
- Collect explicit scenario parameters: entry, TP, SL, R:R and risk.
- Build structured context for the model.
- Run AI analysis or scoring.
- Present output together with context and interpretation boundaries.
- Leave the final decision with the user.
- Store the selected scenario and later observations in the journal.
Controls
- AI does not execute orders within the scope described by this case study.
- Entry, TP, SL and risk remain explicit outside free-form model text.
- Scoring is presented as a model signal rather than a guaranteed probability of profit.
- Input context is structured instead of relying only on free-form prompting.
- The user retains the final decision and can reject model output.
- The journal supports later comparison between assumptions and the user's own process.
Limitations
- AI can be wrong, hallucinate relationships or sound overconfident.
- A score is not automatically a calibrated probability that a trade will succeed.
- Market changes after analysis can immediately make part of the context stale.
- Output quality depends on the quality and freshness of input data.
- The system does not guarantee financial outcomes and does not replace the user's independent judgement.
Explicit stale state
The live layer needs to distinguish current feed data from a dropped connection or delayed updates so a stale snapshot does not look current.
Scenario persistence
Scenarios and journal entries are treated as persistent history separate from the ephemeral market stream.
AI responsibility boundary
The model is not given the role of automatic decision executor; its output remains one input to review.
Integration resilience
Data sources and inference are external dependencies, so the product layer needs to handle timeout, missing responses and retry without hiding state from the user.
Data separation
Live state, structured scenarios and historical journal data have different lifecycles and are separated in the architecture.
Implementation, testing and release
- 101 · Discovery
Define the decision model and product boundaries
- Workflow map from market context to review
- Entry / TP / SL / R:R / risk scenario model
- Boundary between deterministic logic and AI
Result: A shared product model was established so additional modules can be built without mixing live data with persistent assumptions.
- 202 · Core product
Build scenarios, risk model and journal
- Structured scenario engine
- Entry / TP / SL / R:R / risk views
- Persistent journal and scenario history
Result: The core workflow was moved from fragmented tools into one application model.
- 303 · Real-time
Connect changing market context
- Data-feed integration
- Redis / WebSocket layer
- Live state in the dashboard
Result: The interface can react to market updates without treating the stream as the user's persistent history.
- 404 · AI decision support
Add scoring without handing the decision to the model
- Structured AI context
- Model scoring and commentary
- Visible limitations and human review
Result: AI became a separate review layer above the scenario rather than a replacement for its core parameters.
- 505 · Stabilization
Prepare the product for additional data and workflows
- Data-dense UX optimization
- Handling of connection states and external dependencies
- Modular path for team / B2B workflows and additional feeds
Result: Product layers can evolve independently around a stable scenario and journal model.
Scenario validation
Acceptance criteria cover correct representation of entry, TP, SL, R:R and risk and preservation of those values when a scenario is stored.
Real-time states
Behaviour is checked for current feed, connection loss and reconnect so stale state is not confused with live market state.
AI boundary cases
The decision-support layer is assessed for missing context, inference failure and presentation of output without implying certainty.
Journal consistency
Review covers storing and restoring a scenario together with context needed for later process analysis.
Data-dense UX
The dashboard is reviewed for information hierarchy, visibility of risk parameters and clear distinction between live and historical elements.
What confirms the project description
P1-G does not publish the earlier percentage-based KPIs because the repository contains no baseline, sample definition or analytics export that would support a reliable interpretation. The case study describes a verified product screen, data model, architecture and system capabilities. Financial outcomes, strategy performance or investment edge are not attributed to the platform without a separate methodology.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The product has a dashboard combining market overview, scenario, risk sentiment, contextual feed and AI analysis. | Real product screen | TT-01 · TRADING-TOOL dashboard | Confirmed | Displayed prices, indicators and scores are interface presentation and do not prove historical trading performance or the freshness of a specific feed. |
| The architecture separates market feeds, real-time delivery, scenario engine, AI and the persistent journal. | Logical diagram based on project scope | TT-02 · Platform architecture | Confirmed in the product | The diagram describes logical responsibility boundaries and is not an export of confidential production infrastructure. |
| The product workflow moves from market context through an explicit scenario and risk review to the user decision and journal. | Process diagram based on the domain model | TT-03 · Decision workflow | Confirmed in the product | The material confirms the designed workflow, not how every individual user makes decisions. |
| AI is used as a decision-support layer above a structured scenario without automatic order execution. | Diagram of AI role and limitations | TT-04 · AI decision support | Confirmed in the product | The diagram does not mean that scoring is a statistically calibrated probability of profit. |
| The real-time layer uses Node.js, Redis and WebSockets while persistent scenarios and journal data are separated from live state. | Data-flow diagram based on the project stack | TT-05 · Real-time data flow | Confirmed in the product | The material does not disclose the feed provider, SLA or complete infrastructure topology. |
| The trading journal is part of the same product model as scenarios and supports later process review. | Journal-to-review loop diagram | TT-06 · Journal and feedback loop | Confirmed in the product | The journal enables historical analysis but does not itself prove improvement in a user's financial performance. |
How to read this information
- Values visible in the dashboard are interface presentation, not an audit of investment results.
- An AI score is not treated as a calibrated probability of profit without a separate calibration study.
- Data freshness depends on the external feed and its conditions.
- The case study does not document automatic broker order execution.
- We do not publish P&L improvement, win rate or other trading-performance metrics without an approved source.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Working environment | Charts, feed, notes, risk calculator and journal in different places. | One dashboard combines context, scenario, AI review and history. | Fewer gaps between analysis and stored assumptions; qualitative effect without a time-reduction claim. |
| Scenario | Assumptions could remain in notes or inconsistent formats. | Entry, TP, SL, R:R and risk are explicit in the product model. | Scenarios can be stored and later compared using a shared structure. |
| AI | No bounded place for model-based interpretation of context. | AI operates as a separate scoring and commentary layer above the scenario. | The model's role is explicit and separated from the user's final decision. |
| Real-time data | Current market context depended on separate sources and tools. | The feed is distributed to the dashboard through a dedicated real-time layer. | Current context is available in the same place as the scenario while retaining dependency on the data provider. |
| History | Review was disconnected from the original scenario context. | The journal stores the scenario and later observations in one model. | The user can analyse repeatability of their own process without automatically attributing financial results to the system. |
| Extensibility | New capabilities would require connecting more separate tools. | Data, domain, AI and experience are separated into layers. | Additional feeds and workflows can be designed around a shared core. |
One workspace instead of a user-assembled toolset
- Alternative
- Keep charts, notes, journal and calculators as independent tools.
- Trade-off
- More product responsibility for data consistency and UX.
- Rationale
- TRADING-TOOL derives value from preserving the same context from analysis to review.
WebSockets instead of polling only
- Alternative
- Poll the backend periodically for every update type.
- Trade-off
- More complexity around reconnect and stale-state handling.
- Rationale
- A real-time dashboard needs updates without repeatedly refreshing the full state.
AI as a layer above the scenario
- Alternative
- Let the model generate the entire scenario and decision without an explicit field model.
- Trade-off
- Less spectacular automation, but clearer responsibility and better controllability.
- Rationale
- In a financial context, explicit parameters and human review are more important than apparent model autonomy.
Separate live state from persistent history
- Alternative
- Store every market-stream element directly as the primary application model.
- Trade-off
- Requires two data strategies and explicit boundaries between them.
- Rationale
- Scenarios and journal entries need to remain reproducible after current market state has changed.
Key lessons learned
- In a financial product, information architecture matters as much as the number of indicators.
- AI should work on structured context and have an explicitly defined responsibility boundary.
- A model-derived score without calibration should not be described as a guaranteed probability of success.
- Real-time UX needs clear distinction between fresh, delayed and stale state.
- A journal is more useful when connected to the original scenario rather than only a final result.
- Separating live data from the persistent domain simplifies further product development.
- Marketing a trading product should describe system capabilities without implying guaranteed investment outcomes.
Which organisations this model is relevant for
FinTech product teams
Teams building analytics applications, market dashboards and products based on fast-changing data.
Trading analytics SaaS
Products that need to combine scenarios, risk models, journaling and historical review in one system.
Research and market intelligence
Teams needing real-time context, structured hypotheses and an AI layer supporting analysis.
B2B decision-support products
Platforms where AI supports an expert while the decision must explicitly remain with the human.
Data-intensive SaaS
Systems that need to combine data streams, a persistent domain, dashboards and historical analytics.
Related expertise and services
AI automation systems
Designing AI workflows with controls, human review and business-data integration.
Web application development
Building complex dashboards, SaaS products and systems working with real-time data.
Next.js
Frontend layer for high-performance analytics applications and React interfaces.
Node.js
Backend and real-time data services for event-driven products.
TypeScript
Explicit contracts for complex data models, scenarios and application states.
KILOGRAM — marketplace + AI
Another example of production AI, queues and controlled workflows in a complex digital product.
Why AI implementations fail
Article about architecture, data quality and controls required in practical AI implementations.
Building an analytics platform on real-time data?
We can design the domain model, data pipeline, dashboard, AI layer and control mechanisms so the product supports decisions without hiding data-source and model limitations.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and developed TRADING-TOOL as a FinTech market-analytics and decision-support platform.
- 2
TRADING-TOOL combines real-time market data with a structured scenario model.
- 3
The scenario model covers entry, take-profit, stop-loss, Risk:Reward and risk parameters.
- 4
The AI layer in TRADING-TOOL is used for scoring and commentary that supports user review.
- 5
TRADING-TOOL is not presented in this case study as a system that predicts future prices.
- 6
The scope documented in the case study does not include AI automatically executing broker orders.
- 7
The user retains the final decision after receiving model output.
- 8
The platform uses Next.js, TypeScript, Node.js, PostgreSQL, Redis and WebSockets.
- 9
WebSockets and Redis support real-time updates while PostgreSQL stores persistent scenario and journal data.
- 10
The trading journal is part of the same product model as scenarios and historical review.
- 11
The product model covers forex, indices, commodities and cryptocurrencies.
- 12
Earlier percentage-based KPIs are not published in P1-G without a baseline and approved analytics source.
- 13
Values visible in the dashboard screen are treated as interface presentation rather than evidence of investment performance.
- 14
The architecture was designed modularly for additional feeds and team workflows.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Does AI in TRADING-TOOL predict prices?
No. The AI layer supports analysis of structured scenarios and context. Model output is not a promise of future price movement or a guarantee that a trade will succeed.
Does the AI score represent a probability of profit?
It should not be interpreted that way without a separate calibration methodology. In this case study, scoring is described as a model-derived decision-support signal rather than a statistically guaranteed probability of profit.
Does TRADING-TOOL execute trades automatically?
The documented scope covers analytics, scenario planning, risk parameters, AI decision support and journaling. We do not present the system as an automatic broker order-execution mechanism.
What does a trading scenario contain?
The product model includes entry, take-profit, stop-loss, Risk:Reward and risk parameters so that scenario assumptions remain explicit before later review.
How is real-time market data used?
A market feed provides current context for the interface and analysis. Freshness and coverage depend on the upstream provider, so the system separates live state from persistent scenario history.
Why include a trading journal in the same platform?
The journal preserves scenarios, context and later observations in one data model instead of separating analysis from historical review.
Can the platform support multiple asset classes?
The project model includes forex, indices, commodities and cryptocurrencies. The architecture is modular, while the scope of each additional feed depends on the selected data provider and its contract.
Is the platform investment advice?
No. TRADING-TOOL is described as an analytics and decision-support product. Final decisions remain with the user and market outcomes are not guaranteed.