The Next Stock Trading Platform

GOPS is a personalized AI stock trading platform that connects market exploration, stock analysis, order placement, portfolio management, and post-trade review.
It structures market, company, news, and chart data through Logic, while an LLM connects different sources of evidence within the user’s context. The LLM handles interpretations that are difficult to express through rules alone, while numerical analysis, chart geometry, and conditions are calculated through reproducible Logic. Because evidence is as important as the result in stock analysis, GOPS presents each interpretation together with the information and analytical process behind it.

Supported by KRAFTON Jungle, GOPS was developed with four teammates over approximately one month as a PBL project. It operated through stargops.com for two weeks and is currently offline due to market data subscription fees and AWS operating costs.

I independently designed and implemented the chart analysis and rendering engines and co-designed the real-time data processing and storage architecture with the team.

Translating Investor Intent into Logic

Investment strategies are difficult to express as exact numbers. Investors describe their interests and priorities through statements such as, “I want to find rising stocks supported by strong trading turnover,” or “I care more about growth potential than stability.”

GOPS translates this natural language into weights for recommendation factors such as trading turnover, trend, volatility, and company valuation. Users can also adjust these values directly, and GOPS was designed so that the Agent and the user work through the same interface.

After receiving recommendations, users can freely ask questions about the market and individual stocks. Chart, news, and financial Agents gather evidence from their respective perspectives, while the GraphDB at the center of the analysis connects companies, industries, and market events. The image on the right shows an investor referencing relevant information and asking the Agent a question.

Reading Price as Geometry

OHLCV Geometric Analysis and Overlay Generation

Just as spatial order can be read through relationships among points, lines, and planes, I treated a stock chart’s OHLCV data as points in a space of time, price, and volume. I designed a deterministic analysis engine that finds the same structures in the same data and reproduces how support, resistance, trend, and pattern candidates are selected or excluded.

During development, I managed the engine’s handling of normalized OHLCV and its candidate-evaluation rules. I built test loops and used Codex to iteratively implement the candidate-generation logic.

In the following sections, a selected overlay is a structure chosen within the selection cap. A qualified candidate is a structure that passed the runtime conditions but was excluded from final selection. During chart rendering, selected overlays appear as support, resistance, trend, and pattern overlays, while qualified candidates are shown as supporting evidence. Solid lines in the diagrams represent runtime processing, and dotted lines represent development-stage test loops.

1. End-to-End Analysis and Overlay Pipeline

Input	Closed, normalized OHLCV bars
Output	Selected overlays, qualified candidates, and evaluation records stored in PostgreSQL
Process	Extract shared Pivots using ATR and volume, evaluate horizontal, diagonal, and pattern candidates, and assemble overlay data from the full candidate set

The engine identifies Pivots—local highs and lows—from normalized OHLCV using ATR (Average True Range), then shares those point coordinates across every analysis branch. Horizontal analysis finds price zones that have repeatedly produced market reactions. Diagonal analysis finds directions and channels maintained over time. Pattern composition interprets the relationship between those results as a single shape. Each branch completes candidate generation and type-specific runtime evaluation before outputting its overlay candidates.

Overlay data assembly combines candidates from all three branches, manages duplication and confidence, and separates them into selected overlays and qualified candidates. The selection results and evaluation records are stored in PostgreSQL, where they become source material for the Chart Analysis Agent or are projected onto the interface by the rendering engine.

I managed the full process through an end-to-end test loop, with a separate test loop for each branch. I used Codex sub-agents to implement the branches and documented the results and decisions from the full test suite before passing them to the agent responsible for each branch. Each branch therefore retained its own test loop while incorporating results from the end-to-end tests.

Runtime Evaluation

• Coordinate consistency: Verify that all three analysis branches use the shared Pivot and ATR coordinates
• Candidate quality control: Verify type-specific required conditions and maximum selection counts
• Reproducible selection: Verify candidate ordering by score, recency, and coordinates
• Storage contract: Verify identifier links among selected overlays, qualified candidates, and evaluation records

Test Loop

• Determinism: Run the same chart three times and adjust sorting and tie-breaking rules until all results match
• Overlay completeness: Require horizontal, diagonal, and pattern overlays to be generated for all five reference stocks, repeatedly adjusting ATR ranges, touch and reaction conditions, and search windows
• Regression prevention: Fix all final decisions as expected outcomes in the branch-level tests

Five reference stocks: CSCO, CRH, CF, TSLA, and SNDK (stocks for which multiple investors had drawn the same technical indicators during development)

2. Horizontal Analysis: Support and Resistance Overlay Candidates

Input	Shared Pivots, ATR, and volume by price
Output	Horizontal overlay candidates with touch and reaction records
Process	Group nearby Pivots into ATR-based price zones, then classify their support or resistance role using repeated reactions and the current price

This analysis generates horizontal lines at price zones where the market has repeatedly reacted. ATR-based zones make it possible to compare different volatility scales across stocks and timeframes using a common reference. Consecutive bars touching a zone within a short period are grouped into a single touch event, and the reaction is measured by how far price moves away from the zone afterward. The engine first identifies a price zone from Pivot reactions, then places the horizontal line at a weighted average price. Volume concentration by price is included as an evaluation factor.

Each line candidate is assigned a support or resistance role based on its relationship to the current price. Candidates that pass the required runtime conditions for their role are output as horizontal overlay candidates together with their evaluation records.

Runtime Evaluation (Overlay Confidence)

• Repeated price-zone detection: Require at least three temporally separated touches and two reactions
• Current role classification: Evaluate support or resistance based on the current price position, breakout, reclaim, and retest behavior
• Candidate relevance: Evaluate the time since the most recent touch and the distance from the current price
• Price-zone confidence: Evaluate volume concentration by price

Test Loop

• Prevent touch overcounting: Adjust the interval for merging consecutive-bar touches and the minimum touch and reaction counts
• Adapt to volatility: Adjust the ATR-based cluster width and minimum post-touch reaction distance
• Calibrate recency: Adjust weights for the most recent touch and the distance from the current price
• Stabilize classification: Adjust thresholds for breakout invalidation, reclaim, and retest detection

3. Diagonal Analysis: Trendline and Channel Overlay Candidates

Input	Shared Pivots, ATR, and relative volume
Output	Diagonal overlay candidates with touch and residual records
Process	Generate line candidates from Pivot pairs, then classify them as trends or channels using touches and residuals from other Pivots and the parallelism of the opposite boundary

This analysis generates diagonal lines representing directions repeatedly confirmed by the market over time. It creates straight-line candidates in the form y = mx + b from Pivot pairs, then measures their fit by normalizing the price difference between each remaining Pivot and the line as | Pivot price - price on line | / ATR. Relative volume is included as an evaluation factor for touch reactions and boundary breakouts.

When a similar slope is found among Pivots on the opposite side, the engine calculates the parallelism and width of the two boundaries and expands the result into a channel candidate. Candidates that pass the required runtime conditions are output as diagonal overlay candidates together with their evaluation records.

Runtime Evaluation (Overlay Confidence)

• Prevent two-point overfitting: Require at least three touches, including a touch beyond the anchors, and two reactions
• Ensure linear fit: Evaluate ATR-normalized residuals between Pivots and the line
• Determine channel stability: Evaluate the slope difference, width, and price containment ratio of both boundaries
• Determine current validity: Evaluate boundary breaches in recent closed bars and relative volume at reaction points

Test Loop

• Prevent line overfitting: Adjust the minimum number of touches and reactions beyond the anchor points
• Standardize error across stocks: Convert price residuals into ATR units and adjust the permitted range
• Reduce channel misclassification: Adjust slope differences, channel width, and duplicate-touch conditions caused by wide bars touching both boundaries
• Stabilize validity: Adjust the recent-breach window and structural invalidation priority

4. Pattern Composition: Classification and Overlay Candidates

Input	Shared Pivots, horizontal and diagonal overlay candidates, OHLCV, ATR, and relative volume
Output	Pattern candidates with boundary and breakout-confirmation records
Process	Pair horizontal and diagonal overlay candidates as upper and lower boundaries, then interpret their slope relationships and preceding price movement across multiple recent windows

This analysis interprets relationships between horizontal and diagonal boundaries as a single shape. To detect both short-duration and long-running patterns, I used search windows of 20, 40, 60, 90, and 120 bars, then selected qualified patterns by comparing touch counts, geometric fit, and overlap across windows. Boundary relationships are classified as triangles, wedges, flags, pennants, rectangles, or channel breakouts.

Candidates that pass the required runtime conditions are output as pattern overlay candidates together with their evaluation records. Each candidate contains its upper and lower lines as one overlay bundle and records whether a breakout has been confirmed. When no pattern exists, the engine outputs no candidate.

Runtime Evaluation (Overlay Confidence)

• Boundary-structure validity: Evaluate repeated touches, ATR-normalized residuals, and price containment for the upper and lower boundaries
• Shape-classification consistency: Evaluate boundary convergence, parallelism, and width stability
• Breakout confirmation: Require at least 0.25 ATR of boundary penetration, followed by either a hold at the next close or relative volume of at least 1.5×

Test Loop

• Prioritize recent shapes: Separate search windows into 20, 40, 60, 90, and 120 bars and adjust recency weights
• Reduce shape distortion: Adjust the analysis Pivot range and criteria for excluding outlier Pivots
• Distinguish similar shapes: Adjust convergence, residual, containment, and wedge-versus-triangle thresholds
• Ensure reproducibility: Sort by score, recency, and coordinates, then adjust tie-breaking rules

5. Results and Limitations

• Normalized OHLCV and shared Pivots provide consistent time and price coordinates for every overlay.
• Touch, reaction, residual, and recency conditions are stored as evaluation records, making candidate selection and exclusion reproducible.
• Repeated execution on identical inputs and regression cases confirmed deterministic overlay coordinates, candidate ordering, and output formats.
• Missing and excessive overlays were adjusted using five reference stocks. The engine’s geometric consistency and reproducibility were verified, while its utility for users and its investment performance were not evaluated.
• Historical walk-forward evaluation was not performed, so post-overlay price reaction rates, breakout continuation rates, and invalidation rates were not quantitatively verified. Runtime confidence therefore represents the geometric fit of a structure, not the probability of future price movement.

An Agent That Responds Through the Interface

GOPS treats the interface itself as part of the Agent’s output. The Layout Agent interprets the user’s question and current task, then selects the necessary panels and adjusts their position, size, and priority.

When reviewing assets, the interface emphasizes returns and holdings. When responding to the market, it prioritizes charts and alerts. After a trade, it shifts to a review screen that connects the original price movement and investment rationale with the outcome.

The three images present the same portfolio data from three different perspectives: asset overview, real-time response, and post-trade review. Depending on the question, the Agent responds through text, charts, data panels, and interactions.

Deduplicating Identical Analysis Requests

Immediately after the market opens or during sudden price movements, user attention often converges on the same stocks. Many users may request the same chart interval and time range at nearly the same moment. Although the requests come from different users, the server retrieves the same candles and calculates the same indicators and patterns.

Processing every request independently repeats the same data access and analysis. As traffic increases, database and CPU load rise, making the service slower precisely when market information is most time-sensitive.

The symbol, interval, time range, and analysis conditions are combined into a hash key that identifies identical work. The system first checks whether a completed result exists in the cache. If a new calculation is required, a Redis lock grants one server ownership of the task, while the remaining requests join the same calculation and share its result.

In a test of 100 simultaneous identical requests, the underlying analysis ran only once. Eliminating duplicate work instead of scaling servers in proportion to request volume reduced both CPU usage and p95 response time.

Kafka-Based Market Data Processing Architecture

A single real-time price update can be used to generate and store candles, calculate technical indicators, analyze charts, and trigger alerts. GOPS converts external market data into events with a shared schema, records them in Kafka, and allows each feature to consume the events it needs independently.

I co-designed the real-time data processing and storage architecture with the team and proposed the Kafka-based Event-Driven Architecture adopted in the final system. Another teammate implemented the data-processing service, and we resolved the integration issues together.

Kafka stores incoming events in order as a distributed queue and event log. It decouples data producers from consumers and absorbs temporary spikes by retaining unprocessed events. If one feature falls behind, market data collection and the remaining features continue to operate.

During development, technical-indicator calculations and chart-analysis Logic were added without changing the existing market-data ingestion flow. Each capability was introduced as a Consumer subscribing to the same events, and each Consumer could be scaled independently according to its workload. A stopped Consumer resumes from its last committed Offset, allowing feature expansion and failure recovery to remain within the same data stream.

The entire system was deployed and operated in a Kubernetes environment, where the Kafka Consumers and storage layer were also managed.