From Market Noise to a Decision Dashboard
zhulinsen/daily_stock_analysis is an open-source AI stock-analysis system, but calling it a “stock predictor” misses the more important engineering problem it addresses. This series examines how the project turns changing, incomplete market information into a decision dashboard that a person can inspect. The immediate goal is not to promise a better forecast; it is to give the reader a reliable mental model for what enters the system, what can go wrong, and what a finished recommendation actually means.
The project is designed for a watchlist spread across A-shares, Hong Kong, US, Japanese, Korean, and Taiwan markets, as well as ETFs. It can collect quotes, daily bars, technical indicators, news, announcements, fundamentals, and market context, then produce a structured report and deliver it through a Web or desktop workspace, an API, scheduled automation, or notification channels. That breadth is useful, but it creates a problem that a single score cannot solve: the same-looking number may be built from very different evidence depending on the market, the time of day, the source that answered, and the fields that were unavailable.
The central question, then, is not “Did the AI say buy?” It is “What chain of evidence allowed the system to say it, and what limits remain attached to that chain?” Once that question is clear, the project becomes easier to understand. Its dashboard is the visible end of a workflow that manages uncertainty before, during, and after model generation.
The subject is a workflow, not a ticker picker
A raw quote answers a narrow question: what value did a provider return for a symbol? An unstructured chat answer can add interpretation, but it may leave the reader unsure which facts were used, which were missing, and whether a recommendation is meant for someone who already holds the security. The dashboard in this project is deliberately broader. It puts a core conclusion beside a score, trend interpretation, price position, risk alerts, positive catalysts, a suggested plan, and a checklist. It can distinguish advice for a person with no position from advice for someone already holding the stock.
That structure changes the unit of analysis. The project is not merely asking a model to attach a label to a price series. It is assembling a decision object whose parts answer different questions:
- What is the current directional interpretation?
- Which technical, fundamental, or intelligence signals support it?
- Where are the relevant support, resistance, stop, or target levels?
- What could invalidate the view?
- What should be watched before taking the next step?
The repository connects these questions through several kinds of state. A watchlist or user request identifies the subject. Market-data and search services supply observations. The analysis pipeline combines them into context. A traditional analyzer or an optional Agent path generates a structured synthesis. Post-generation checks can stabilize the action, lower confidence, or rewrite unsafe wording. The report may then be saved, exposed through the API and Web interface, indexed as a decision signal, and sent to one or more channels.
This relationship is more important than any individual provider or model. If a model changes, the project can still preserve the same dashboard contract. If one data source fails, the report can still be produced while carrying a limitation. If a notification fails, the saved report need not disappear. The system's identity therefore lies in how it holds the pieces together and keeps their boundaries visible.
That does not make the dashboard objective or infallible. The model still interprets evidence, and the project does not provide an independent benchmark proving that its scores predict returns. The dashboard is better understood as a structured aid for judgment: it makes a recommendation easier to inspect and compare with one's own constraints, rather than turning uncertainty into certainty.
Why “data available” is not enough
The first trap in automated analysis is treating any returned value as equally usable. The project explicitly works against that assumption in three ways: it tracks provider fallback, it distinguishes market capability, and it treats time as part of the evidence.
Consider provider fallback. The system can try different sources for daily data and realtime quotes, choosing an eligible source according to the route for that market and dataset. When a preferred source fails, a later source may keep the workflow moving. The resulting quote is not supposed to look identical to a primary-source quote, however. The unified quote structure can retain the actual source, the source that failed first, acquisition time, provider timestamp, stale markers, and a fallback marker. In other words, “a number arrived” and “the preferred number arrived freshly” are separate statements.
This is a sensible trade-off. A scheduled watchlist should not become useless because one free endpoint is rate-limited for a few minutes. At the same time, continuity can conceal a change in evidence quality unless the change is recorded. A fallback may be older, less complete, or based on a different field definition. The project’s quality language is meant to keep that difference attached to the result instead of silently discarding it.
Capability is another boundary. The richest path is not available for every market. A-share analysis has native routes for features such as capital flow, board relationships, and other mainland-specific context. Japanese and Korean suffix-form symbols rely on a lighter Yahoo Finance path for daily and basic quote data; A-share-specific features are marked unsupported. Taiwan symbols have their own route and can add three-institution flow data, but the repository still does not claim a complete Taiwan market-breadth or portfolio-valuation surface. A missing block in such a report is not evidence that the company has no fundamentals or risk. It is evidence that this installation and market path do not supply that particular block.
Time adds a third distinction. A price observed during a session is not automatically a completed daily fact. The project maps markets to their own calendars and local time zones, tracks an effective reusable daily-bar date, and distinguishes premarket, intraday, lunch break, near-close, postmarket, non-trading, and unknown states. A realtime price may be overlaid on technical context as a partial or estimated bar. That can be useful for a current observation, but it should not be described as a finished session.
The practical consequence is that quality metadata should change how a result is read, not simply decorate the interface. A report that continues after a source fallback or with an incomplete bar can still be useful. It should not receive the same interpretation as a report built from fresh, complete, market-appropriate evidence. Conversely, an unsupported feature should not be converted into a bearish conclusion merely because the field is empty.
The dashboard as a chain of trust
The project can be understood through the following high-level transformation:
The first link identifies what is being analyzed and which market rules apply. The second and third links gather several kinds of evidence rather than relying on a single feed. Technical history can be combined with a realtime quote, chip or volume information, fundamentals, news, social sentiment where available, and previously stored intelligence. Some enrichments are optional, so their absence should remain a visible condition rather than being filled with invented content.
The fourth link is the key conceptual hinge. The project’s AnalysisContextPack gathers already-fetched artifacts into named blocks such as quote, daily bars, technical data, fundamentals, news, and chip information. Each block can carry a state such as available, missing, unsupported, fallback, stale, estimated, partial, or fetch failed. This allows the later synthesis step to know not only values, but the conditions under which those values exist. The model-facing summary is intentionally low sensitivity; it communicates status, source, warnings, and limitations without dumping every raw payload or secret into the prompt.
The model or Agent is therefore inside the chain, not above it. It is responsible for combining signals into readable conclusions, price plans, risks, and watch conditions. The surrounding pipeline still validates the expected structure, normalizes action fields, and applies phase and data-quality guardrails. If core quote, daily-bar, or technical evidence is degraded, high confidence can be capped. If the current phase does not support an immediate intraday action, overly direct wording can be softened. These controls do not prove that the final action is correct; they prevent the system from claiming more than its own inputs justify.
The final link separates analysis from delivery. A saved history record supports later inspection. An API task can be synchronous or asynchronous, with status and progress surfaces for longer runs. Notifications can send the report to several channels, but delivery is its own outcome: a failed webhook is not a failed market observation, and a successful message is not proof that the recommendation was sound. Structured decision signals can support lifecycle tracking and later outcome evaluation, but they do not place orders or rebalance a portfolio.
This gives the reader a compact way to judge any result from the project. First, confirm the subject and market: is the system analyzing the intended asset under the right market rules? Second, inspect evidence condition: which core inputs are fresh and complete, and which are fallback, partial, stale, or unsupported? Third, ask whether the proposed action matches the claim the evidence can support, including its time horizon and invalidation conditions.
Those questions keep the project in view while resisting two opposite mistakes. One mistake is to dismiss it as “just another prompt” and overlook the value of explicit data, timing, and failure contracts. The other is to mistake a polished dashboard for a guaranteed forecast. The useful middle ground is an evidence-aware workflow: one that helps a reader see not only the conclusion, but also the conditions that make the conclusion more or less defensible.
The next step is to follow one stock request through that workflow in order, from the first market decision to the point where a report is saved.