A modular research platform for transforming heterogeneous market data into structured, explainable equity intelligence.
The Investment Intelligence System is an active research and engineering project exploring how multiple forms of market evidence can be combined without hiding uncertainty or forcing every signal into a single black-box prediction.
The system is designed around six analytical domains:
- Trend and regime detection
- Fundamental and sector analysis
- Institutional-flow inference
- Technical signals
- Tape and market-microstructure analysis
- News and sentiment modeling
Each engine is intended to operate independently and return a standardized, auditable result containing its direction, strength, evidence, time horizon, data quality, and invalidation conditions. A higher-level orchestration layer will compare those results, identify conflicts, and generate scenario-based market intelligence reports.
This repository currently contains working research prototypes for technical analysis, tape analysis, and sector/fundamental analysis. The unified engine interface, Python orchestration layer, historical validation framework, and agent-based synthesis layer are under development.
This is not an automated trading system, execution platform, or proven alpha-generating strategy. It is a research platform for signal engineering, data analysis, system design, and explainable decision support.
Most market-analysis tools have one of two weaknesses:
- They depend on a narrow category of evidence, such as technical indicators alone.
- They combine many features into an opaque score without showing where the evidence agrees, conflicts, or becomes stale.
Markets produce heterogeneous signals across different time horizons. A stock can have strong long-term fundamentals, weakening intermediate momentum, positive news sentiment, and bearish intraday order flow at the same time. Averaging those observations into one number destroys useful context.
This project instead treats disagreement as a first-class output.
The core engineering objective is to build a system that can answer:
- What evidence supports the current market view?
- Which signals are independent, and which are correlated?
- Which conclusions depend on stale or incomplete data?
- What would invalidate the current interpretation?
- How should conflicting signals across different time horizons be represented?
- Can every generated statement be traced back to a deterministic calculation or source?
| Component | Status | Current implementation |
|---|---|---|
| Technical Signals Engine | Functional prototype | Browser-based HTML/JavaScript engine using market-data APIs |
| Tape Analysis Engine | Functional research prototype | React/JSX engine processing time-and-sales CSV data |
| Fundamental / Sector Alpha Engine | Exploratory prototype | React/JSX workflow with structured AI-assisted research output |
| Trend / Regime Engine | Partially represented | Trend features currently exist inside the technical and tape engines; standalone engine planned |
| Institutional Flow Engine | Partially represented | Heuristic flow features currently exist inside the tape engine; standalone engine planned |
| Sentiment Engine | Planned | News ingestion, entity linking, source weighting, and event classification |
| Standardized Engine Interface | In design | Shared schema for direction, evidence, horizon, quality, and risk |
| Conflict-Resolution Layer | In design | Correlation-aware aggregation and disagreement handling |
| AI Agent Orchestrator | In design | Constrained synthesis over structured engine outputs |
| Historical Validation Framework | Planned | Walk-forward tests, calibration, ablation studies, and regime analysis |
The project is intentionally being developed as independent research prototypes before the components are consolidated behind a shared interface.
flowchart TD
A[Market Data Sources] --> B[Ingestion and Validation]
B --> C[Normalized Market Data Layer]
C --> D1[Trend and Regime Engine]
C --> D2[Fundamental Engine]
C --> D3[Institutional Flow Engine]
C --> D4[Technical Signals Engine]
C --> D5[Tape Analysis Engine]
C --> D6[Sentiment Engine]
D1 --> E[Standardized Engine Results]
D2 --> E
D3 --> E
D4 --> E
D5 --> E
D6 --> E
E --> F[Data Quality and Freshness Checks]
F --> G[Correlation-Aware Conflict Resolution]
G --> H[Scenario and Confidence Layer]
H --> I[Constrained AI Synthesis]
I --> J[Explainable Market Intelligence Report]
Deterministic calculations should produce the evidence. AI should explain and organize that evidence, not invent it.
raw data
↓
validated features
↓
deterministic engine outputs
↓
conflict and uncertainty handling
↓
constrained natural-language synthesis
The long-term architecture uses a common result contract so engines can be developed, tested, replaced, or disabled independently.
{
"engine": "tape_analysis",
"symbol": "AAPL",
"generated_at": "2026-07-30T18:00:00Z",
"data_as_of": "2026-07-30T16:00:00Z",
"horizon": "next_session",
"direction": "bearish",
"strength": 0.68,
"score_type": "heuristic",
"evidence": [
{
"feature": "close_location",
"value": 0.18,
"contribution": -3,
"interpretation": "Price closed near the session low"
},
{
"feature": "vwap_position",
"value": "below",
"contribution": -2,
"interpretation": "Price closed below session VWAP"
}
],
"risk_flags": [
"elevated_flow_imbalance",
"conflicting_tick_and_delta_signals"
],
"invalidation_conditions": [
"reclaim_and_hold_above_vwap"
],
"data_quality": {
"status": "complete",
"missing_fields": [],
"freshness_seconds": 7200
}
}The exact schema is still evolving, but the contract is designed to preserve:
- Direction
- Signal strength
- Time horizon
- Supporting evidence
- Negative evidence
- Data freshness
- Risk flags
- Invalidation conditions
- Scoring methodology
- Traceability to source calculations
Located in quant_ta/.
The Technical Signals Engine retrieves market data and calculates a multi-factor technical report containing:
- Daily, weekly, and monthly trend analysis
- 50-, 100-, and 200-day simple moving averages
- Golden-cross and death-cross conditions
- Relative Strength Index
- MACD and histogram direction
- Bollinger Bands and volatility compression
- Relative volume
- Support and resistance
- Fibonacci retracement levels
- Basic chart-pattern detection
- Conditional entry, stop, and target levels
- Weighted technical rating
- Future bullish and bearish triggers
The engine is intentionally deterministic. Market data is retrieved through the configured data API, and calculations are performed locally in the browser.
Browser
↓
Market-data API
↓
Local feature computation
↓
Weighted technical score
↓
Structured technical report
The technical rating is a heuristic weighted score. It is not a statistically calibrated probability and has not yet been shown to predict future returns out of sample.
Located in stock-tape-analysis-engine.jsx.
The Tape Analysis Engine processes time-and-sales CSV data and extracts market-microstructure-inspired features, including:
- Session open, high, low, and close
- Volume-weighted average price
- Volume profile and point of control
- Trade-size distributions
- Large-print concentration
- Intraday phase behavior
- Volume above and below VWAP
- Tick direction and tick-volume ratios
- Cumulative directional volume
- Trade velocity
- Inter-trade timing
- Sweep-like print sequences
- Repeated-size activity
- Iceberg-like repetition heuristics
- Price impact per unit of volume
- Realized-volatility estimates
- VPIN-inspired flow imbalance
- Hurst-style trend-persistence estimates
- Support and resistance derived from session structure
The engine generates:
- A composite directional score
- Bullish, bearish, reversal, and range-bound scenario weights
- Supporting and conflicting signals
- Risk flags
- Key levels
- A next-session conditional playbook
- A human-readable executive summary
Several order-flow features are derived from related underlying observations. Adding every feature independently would double-count evidence and inflate conviction.
The engine therefore includes conflict handling for overlapping signals. For example, tick-volume direction and cumulative directional volume are compared before their contributions are combined. When related signals disagree, confidence is reduced rather than silently averaged into a stronger score.
The engine infers patterns that may be consistent with accumulation, distribution, large-participant activity, or hidden liquidity. It does not identify the actual participant behind a trade, and heuristic labels such as “institutional,” “dark pool,” “sweep,” or “iceberg” should not be interpreted as confirmed exchange classifications without venue and condition-code data.
Scenario percentages are normalized heuristic weights, not calibrated probabilities.
Located in sector-alpha-engine.jsx.
This prototype explores structured company and sector research across dimensions such as:
- Sector and industry selection
- Geography
- Market capitalization
- Investment style
- Risk profile
- Investment horizon
- Business quality
- Financial quality
- Management
- Innovation
- Competitive moat
- Catalysts
- Ownership rationale
- SWOT analysis
The component experiments with AI-assisted generation of structured research objects and comparative company views.
This prototype currently focuses on research orchestration and interface design. AI-generated company analysis must be grounded in verified financial statements, filings, market data, and source citations before it can be treated as reliable investment research.
The planned synthesis layer will not simply average engine scores.
A useful aggregation system must account for:
A bearish intraday tape signal and a bullish twelve-month fundamental thesis are not necessarily contradictory. They may describe different horizons.
RSI, moving averages, MACD, and price trend are not independent observations. Treating each as independent evidence can create false confidence.
A live tape signal should not be weighted the same way as a financial metric derived from an older filing without explicitly recording each data timestamp.
An unavailable engine should reduce the completeness of the report, not silently produce a neutral score.
The usefulness of momentum, mean-reversion, volatility, volume, and sentiment signals changes across market regimes.
When reliable engines disagree, the output should expose the disagreement, lower conviction, and define scenarios that would resolve it.
The planned AI layer is a constrained reporting and orchestration component.
It is intended to:
- Read standardized engine outputs
- Compare signals by horizon and data freshness
- Identify corroborating and conflicting evidence
- Surface missing inputs and weak assumptions
- Produce conditional scenarios
- Generate concise, traceable explanations
- Refuse unsupported conclusions
It is not intended to:
- Invent prices, indicators, or financial metrics
- Replace deterministic calculations
- Convert heuristic scores into fake probabilities
- Hide missing data
- Produce an unconditional buy or sell recommendation
- Execute trades
A generated statement should be traceable to an engine result. If the system cannot identify supporting evidence, the statement should not appear in the report.
Many market indicators are transformations of the same price and volume history. The system needs correlation-aware aggregation rather than a naïve sum of bullish and bearish labels.
Market datasets can include missing intervals, inconsistent timestamps, duplicate records, partial sessions, stale snapshots, and malformed CSV rows. Validation and deterministic fallback behavior are necessary before scoring.
A precise-looking output can be more misleading than a qualitative one. The project distinguishes among:
- Raw feature values
- Heuristic scores
- Normalized scenario weights
- Statistically calibrated probabilities
Only the final category should be called a probability.
A research result should be reproducible from the same input data and configuration. Future consolidation will include versioned engine configurations, immutable input snapshots, and deterministic replay.
Every directional conclusion should expose the features that increased or decreased conviction, rather than returning an unexplained label.
The current prototypes favor clarity and iteration speed. A production trading environment would require separate latency budgets, incremental rolling calculations, streaming ingestion, backpressure handling, monitoring, and strict fault isolation.
The system has not yet demonstrated predictive edge. The following validation work is required before any performance claims are justified.
- Unit-test calculations against known examples
- Test malformed and incomplete data
- Test zero-volume and flat-price sessions
- Test timestamp ordering and duplicate handling
- Test deterministic output for identical inputs
- Use walk-forward rather than random train-test splits
- Prevent look-ahead and survivorship bias
- Separate development, validation, and final holdout periods
- Compare against simple baselines
- Measure performance by market regime and time horizon
- Compare scenario weights with observed outcome frequencies
- Use reliability diagrams and calibration error
- Apply calibration only on held-out data
- Avoid calling heuristic weights probabilities before validation
- Remove one feature or engine at a time
- Measure whether added complexity improves results
- Identify correlated or redundant features
- Reject components that do not improve out-of-sample performance
Any strategy-level evaluation must include:
- Transaction costs
- Bid-ask spread
- Slippage
- Market impact assumptions
- Signal-to-execution delay
- Liquidity constraints
- Corporate actions
- Delisted securities
InvestmentIntelligenceSystem/
├── README.md
├── quant_ta/
│ ├── README.MD
│ └── quant-ta-engine-direct.html
├── stock-tape-analysis-engine.jsx
├── tape-engine.jsx
├── sector-alpha-engine.jsx
└── sma-engine-v2/
The repository currently contains independent prototypes rather than one packaged application. Consolidating these components behind a shared data model and build system is part of the roadmap.
- Python 3 or another local static-file server
- A supported market-data API key
- A modern browser
git clone https://github.com/EcSky19/InvestmentIntelligenceSystem.git
cd InvestmentIntelligenceSystem/quant_ta
python3 -m http.server 8080Open:
http://localhost:8080/quant-ta-engine-direct.html
Enter the API key through the application settings and run an analysis for a supported ticker.
Do not commit API keys to the repository. The current browser prototype should be treated as a local research tool.
The root-level JSX files are research components and are not yet packaged with a shared package.json or production build configuration.
To experiment with them today, mount the desired component inside a local React environment such as Vite. Repository-level installation and startup scripts will be added during consolidation.
- Create a shared frontend build system
- Separate analysis logic from presentation components
- Add linting, formatting, type checking, and automated tests
- Add example datasets with sanitized inputs
- Add versioned engine configurations
- Implement typed engine interfaces
- Build reusable data-ingestion adapters
- Normalize timestamps, symbols, corporate actions, and missing data
- Move scoring logic into independently testable modules
- Add structured logging and deterministic replay
- Create a historical event and feature store
- Add walk-forward evaluation
- Add calibration reports
- Add baseline comparisons
- Add ablation and sensitivity analysis
- Track performance by market regime
- Standardize
EngineResult - Add horizon-aware aggregation
- Add correlation and conflict rules
- Add data-quality scoring
- Add missing-engine behavior
- Generate scenario trees and invalidation conditions
- Use structured engine outputs as the only analytical context
- Require evidence references for generated claims
- Add hallucination and consistency checks
- Add report-level confidence and completeness indicators
- Add human review and feedback capture
- Stream market events into stateful processors
- Update rolling features incrementally
- Define per-component latency budgets
- Add replayable event logs
- Add monitoring for stale feeds and anomalous inputs
- Separate research workloads from latency-sensitive services
- JavaScript
- React / JSX
- HTML and browser-based computation
- Financial market-data APIs
- CSV time-and-sales ingestion
- Local research dashboards
- Python for analytical engines, validation, orchestration, and backtesting
- Typed schemas for engine contracts
- Event-driven data processing
- Persistent feature and result storage
- Testable model and signal pipelines
- Constrained LLM orchestration
- Reproducible historical evaluation
The final technology choices will be driven by measurement, reliability, and maintainability rather than by forcing every component into the same language.
This project does not currently attempt to provide:
- Low-latency trade execution
- Exchange connectivity
- Order management
- Portfolio optimization
- Production risk controls
- Guaranteed market predictions
- Personalized financial advice
- A replacement for audited market data or regulatory filings
This repository is for software-engineering, quantitative-research, and educational purposes only. It does not provide financial advice, investment recommendations, or guarantees of future performance.
Market-analysis outputs can be incomplete, delayed, incorrect, or based on unvalidated heuristics. Do not use the system as the sole basis for an investment or trading decision.
Ethan Coskay
Computer Science, Cornell University
GitHub: @EcSky19
This project is available under the MIT License.